Christian, this is more up your alley, letting you comment as well as you weren't even sent a copy in Ccs Guan, overall, please check Documentation/process/submitting-patches.rst - this is missing [PATCH] in the mail header, missing some recipients that you'd have gotten from get_maintiner.pl, and the commit title is a mess. Have a look at other recent patches on https://lore.kernel.org/v9fs/ Guan Xin wrote on Sat, Oct 26, 2024 at 12:18:42AM +0800: > For HPC applications the hard-coded VIRTQUEUE_NUM of 128 seems to > limit the throughput of guest systems accessing cluster filesystems > mounted on the host. > > Just increase VIRTQUEUE_NUM for kernels with a > larger stack. You're replacing an hardcoded value with another, this could be made dynamic e.g. as a module_param so someone could tune this based on their actual needs (and test more easily); I'd more readily accept such a patch. > Author: GUAN Xin <guanx.bac@xxxxxxxxx> Author: tag doesn't exist and would be useless here as it's the mail you sent the patch from. > 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) > /* a single mutex to manage channel initialization and attachment */ > static DEFINE_MUTEX(virtio_9p_lock); > -- Dominique Martinet | Asmadeus
