[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANeMGR4E+MDKDudtfjgTD5yvc-HiC_L7tzsQm=2EbEH1RyPoYg@mail.gmail.com>
Date: Sat, 26 Oct 2024 18:14:05 +0800
From: Guan Xin <guanx.bac@...il.com>
To: Christian Schoenebeck <linux_oss@...debyte.com>
Cc: Dominique Martinet <asmadeus@...ewreck.org>, 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
Hi Christian,
On Sat, Oct 26, 2024 at 5:36 PM Christian Schoenebeck
<linux_oss@...debyte.com> wrote:
>
> 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];
> ...
> };
Yes, exactly.
> 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
That would be better! I'll take a look at your patches.
Please ignore my patch for the moment.
Guan
Powered by blists - more mailing lists