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@xxxxxxxxx>
> > cc: Eric Van Hensbergen <ericvh@xxxxxxxxxx>
> > cc: v9fs@xxxxxxxxxxxxxxx
> > cc: netdev@xxxxxxxxxxxxxxx
> > cc: linux-fsdevel@xxxxxxxxxxxxxxx
> >
> > --- 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@xxxxxxxxxxxxx/
Patches 8..11 have already been merged. Patches 1..7 are still to be merged.
/Christian
