[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55e7058b-07d0-3619-3481-2d70e95875ea@grimberg.me>
Date: Mon, 19 Jun 2023 11:25:34 +0300
From: Sagi Grimberg <sagi@...mberg.me>
To: David Howells <dhowells@...hat.com>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: netdev@...r.kernel.org,
Alexander Duyck <alexander.duyck@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
David Ahern <dsahern@...nel.org>,
Matthew Wilcox <willy@...radead.org>,
Jens Axboe <axboe@...nel.dk>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Keith Busch <kbusch@...nel.org>,
Jens Axboe <axboe@...com>, Christoph Hellwig <hch@....de>,
Chaitanya Kulkarni <kch@...dia.com>,
linux-nvme@...ts.infradead.org
Subject: Re: [PATCH net-next v2 10/17] nvme: Use sendmsg(MSG_SPLICE_PAGES)
rather then sendpage
>> struct bio_vec bvec;
>> struct msghdr msg = { .msg_flags = MSG_SPLICE_PAGES | ... };
>>
>> ..
>>
>> bvec_set_virt
>> iov_iter_bvec
>> sock_sendmsg
>>
>> is a frequent pattern. Does it make sense to define a wrapper? Same for bvec_set_page.
>
> I dunno. I'm trying to move towards aggregating multiple pages in a bvec
> before calling sendmsg if possible rather than doing it one page at a time,
> but it's easier and more obvious in some places than others.
That would be great to do, but nvme needs to calculate a data digest
and doing that in a separate scan of the payload is not very cache
friendly...
There is also the fact that the payload may be sent in portions
asynchronously driven by how the controller wants to accept them,
so there is some complexity there.
But worth looking at for sure.
The patch looks good to me, taking it to run some tests
(from sendpage-3-frag branch in your kernel.org tree correct?)
For now, you can add:
Reviewed-by: Sagi Grimberg <sagi@...mberg.me>
Powered by blists - more mailing lists