Re: Calculate VIRTQUEUE_NUM in "net/9p/trans_virtio.c" from stack size

[Christian Schoenebeck <linux_oss@crudebyte.com>]

On Friday, October 25, 2024 11:52:56 PM CEST Dominique Martinet wrote:
> Christian,
> 
> this is more up your alley, letting you comment as well as you weren't
> even sent a copy in Ccs
[...]
> > Signed-off-by: GUAN Xin <guanx.bac@gmail.com>
> > cc: Eric Van Hensbergen <ericvh@kernel.org>
> > cc: v9fs@lists.linux.dev
> > cc: netdev@vger.kernel.org
> > cc: linux-fsdevel@vger.kernel.org
> > 
> > --- net/9p/trans_virtio.c.orig  2024-10-25 10:25:09.390922517 +0800
> > +++ net/9p/trans_virtio.c       2024-10-25 16:48:40.451680192 +0800
> > @@ -31,11 +31,12 @@
> > #include <net/9p/transport.h>
> > #include <linux/scatterlist.h>
> > #include <linux/swap.h>
> > +#include <linux/thread_info.h>
> > #include <linux/virtio.h>
> > #include <linux/virtio_9p.h>
> > #include "trans_common.h"
> > 
> > -#define VIRTQUEUE_NUM  128
> > +#define VIRTQUEUE_NUM  (1 << (THREAD_SIZE_ORDER + PAGE_SHIFT - 6))
> 
> (FWIW that turned out to be 256 on my system)

Guan,

it took me a bit to understand why you would change this constant depending on
maximum stack size, as it is not obvious. Looks like you made this because of
this comment (net/9p/trans_virtio.c):

struct virtio_chan {
    ...
	/* Scatterlist: can be too big for stack. */
	struct scatterlist sg[VIRTQUEUE_NUM];
    ...
};

However the stack size is not the limiting factor. It's a bit more complicated
than that:

I have also been working on increasing performance by allowing larger 9p
message size and made it user-configurable at runtime. Here is the latest
version of my patch set:

https://lore.kernel.org/all/cover.1657636554.git.linux_oss@crudebyte.com/

Patches 8..11 have already been merged. Patches 1..7 are still to be merged.

/Christian