Am 07.08.25 um 08:24 schrieb David Howells:
Stefan Metzmacher <metze@xxxxxxxxx> wrote:
So the current situation is that we memcpy (at least) in sendmsg()
and with your patches we do a memcpy higher in the stack, but then
use MSG_SPLICE_PAGES in order to do it twice. Is that correct?
Not twice, no. MSG_SPLICE_PAGES allows sendmsg() to splice the supplied pages
into the sk_buffs directly, thereby avoiding a copy in the TCP layer and
cutting out the feeder loop in cifs.
Yes, and we must be careful to not touch the pages after
calling sendmsg(MSG_SPLICE_PAGES).
And unlike MSG_ZEROCOPY tcp_sendmsg_locked() has no
no struct ubuf_info *uarg when MSG_SPLICE_PAGES is used
and there's no way to know when the pages are no longer
used by the tcp stack.
Can you explain how/where we allocate the memory and where
we unreference it in the caller of sendmsg(MSG_SPLICE_PAGES).
However, this is meant to be an intermediate step. I actually want to
assemble the fragment list in a bvecq in the smb_create_request() as called by
the PDU encoders, with everything aligned for crypto so that the crypto layer
doesn't copy it also. But cleaning up the transport first should hopefully
reduce the size of the later patches.
Sounds good :-)
metze
