netdev - Re: Calculate VIRTQUEUE_NUM in "net/9p/trans

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1921500.ue69UQ14vC@silver>
Date: Sat, 26 Oct 2024 11:36:13 +0200
From: Christian Schoenebeck <linux_oss@...debyte.com>
To: Guan Xin <guanx.bac@...il.com>,
 Dominique Martinet <asmadeus@...ewreck.org>
Cc: v9fs@...ts.linux.dev,
 Linux Kernel Network Developers <netdev@...r.kernel.org>,
 linux-fsdevel@...r.kernel.org, Eric Van Hensbergen <ericvh@...nel.org>
Subject:
 Re: Calculate VIRTQUEUE_NUM in "net/9p/trans_virtio.c" from stack size

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@...il.com>
> > cc: Eric Van Hensbergen <ericvh@...nel.org>
> > cc: v9fs@...ts.linux.dev
> > cc: netdev@...r.kernel.org
> > cc: linux-fsdevel@...r.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