mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Stefan Metzmacher <metze@samba.org>
Cc: dhowells@redhat.com, Steve French <sfrench@samba.org>,
	Paulo Alcantara <pc@manguebit.org>,
	Shyam Prasad N <sprasad@microsoft.com>,
	Tom Talpey <tom@talpey.com>,
	Wang Zhaolong <wangzhaolong@huaweicloud.com>,
	Mina Almasry <almasrymina@google.com>,
	linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 00/31] netfs: [WIP] Allow the use of MSG_SPLICE_PAGES and use netmem allocator
Date: Thu, 07 Aug 2025 08:12:58 +0100	[thread overview]
Message-ID: <2573495.1754550778@warthog.procyon.org.uk> (raw)
In-Reply-To: <40d1f78c-d437-4ab4-8e5e-8708af6486ab@samba.org>

Stefan Metzmacher <metze@samba.org> 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).

Until we get a response from the server, yes, but for the protocol info that
shouldn't be an issue.  And if we're going to encrypt, we'll have to do a copy
anyway for something like Write, but we can get the encryption algo to do that
for us by giving it a separate destination buffer.

> 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.

Correct (and this is something we'll need to address), but for the moment we
can rely on page refcounts.  MSG_SPLICE_PAGES takes a ref on each page - which
is why you can't use it with slab memory.  However, if we pass in
netmem-allocated memory, that works by refcounting, so that should work.

> Can you explain how/where we allocate the memory and where
> we unreference it in the caller of sendmsg(MSG_SPLICE_PAGES).

Currently, we allocate the buffer in fs/netfs/buffer.c in
netfs_alloc_bvecq_buffer().  That just bulk allocates a bunch of pages and
adds them into a bvecq.  As they're untyped pages, we can use the refcount.  I
want to allocate netmem instead, but I haven't done that yet.

We then call sendmsg(MSG_SPLICE_PAGES) and then drop our ref on the pages.
TCP will have taken its own ref which it will drop in due course when the
skbuffs are cleaned up.

David


  parent reply	other threads:[~2025-08-07  7:13 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-06 20:36 David Howells
2025-08-06 20:36 ` [RFC PATCH 01/31] iov_iter: Move ITER_DISCARD and ITER_XARRAY iteration out-of-line David Howells
2025-08-06 20:36 ` [RFC PATCH 02/31] iov_iter: Add a segmented queue of bio_vec[] David Howells
2025-08-06 20:36 ` [RFC PATCH 03/31] netfs: Provide facility to alloc buffer in a bvecq David Howells
2025-08-06 20:36 ` [RFC PATCH 04/31] cifs, nls: Provide unicode size determination func David Howells
2025-08-06 20:36 ` [RFC PATCH 05/31] cifs: Introduce an ALIGN8() macro David Howells
2025-08-06 20:36 ` [RFC PATCH 06/31] cifs: Move the SMB1 transport code out of transport.c David Howells
2025-08-06 20:36 ` [RFC PATCH 07/31] cifs: Rename mid_q_entry to smb_message David Howells
2025-08-06 20:36 ` [RFC PATCH 08/31] cifs: Keep the CPU-endian command ID around David Howells
2025-08-06 20:36 ` [RFC PATCH 09/31] cifs: Rename SMB2_xxxx_HE to SMB2_xxxx David Howells
2025-08-06 20:36 ` [RFC PATCH 10/31] cifs: Make smb1's SendReceive() wrap cifs_send_recv() David Howells
2025-08-06 20:36 ` [RFC PATCH 11/31] cifs: Fix SMB1 to not require separate kvec for the rfc1002 header David Howells
2025-08-06 20:36 ` [RFC PATCH 12/31] cifs: Replace SendReceiveBlockingLock() with SendReceive() plus flags David Howells
2025-08-06 20:36 ` [RFC PATCH 13/31] cifs: Institute message managing struct David Howells
2025-08-06 20:36 ` [RFC PATCH 14/31] cifs: Split crypt_message() into encrypt and decrypt variants David Howells
2025-08-06 20:36 ` [RFC PATCH 15/31] cifs: Use netfs_alloc/free_folioq_buffer() David Howells
2025-08-06 20:36 ` [RFC PATCH 16/31] cifs: Rewrite base TCP transmission David Howells
2025-08-07  5:40   ` Stefan Metzmacher
2025-08-07 10:12   ` David Howells
2025-08-07 10:14   ` David Howells
2025-08-06 20:36 ` [RFC PATCH 17/31] cifs: Rework smb2 decryption David Howells
2025-08-06 20:36 ` [RFC PATCH 18/31] cifs: Pass smb_message structs down into the transport layer David Howells
2025-08-08 14:21   ` Enzo Matsumiya
2025-08-06 20:36 ` [RFC PATCH 19/31] cifs: Clean up mid->callback_data and kill off mid->creator David Howells
2025-08-06 20:36 ` [RFC PATCH 20/31] cifs: Don't need state locking in smb2_get_mid_entry() David Howells
2025-08-06 20:36 ` [RFC PATCH 21/31] cifs: [DEBUG] smb_message refcounting David Howells
2025-08-06 20:36 ` [RFC PATCH 22/31] cifs: Add netmem allocation functions David Howells
2025-08-06 20:36 ` [RFC PATCH 23/31] cifs: Add more pieces to smb_message David Howells
2025-08-06 20:36 ` [RFC PATCH 24/31] cifs: Convert SMB2 Negotiate Protocol request David Howells
2025-08-08 14:44   ` Enzo Matsumiya
2025-08-08 15:10   ` David Howells
2025-08-06 20:36 ` [RFC PATCH 25/31] cifs: Convert SMB2 Session Setup request David Howells
2025-08-06 20:36 ` [RFC PATCH 26/31] cifs: Convert SMB2 Logoff request David Howells
2025-08-06 20:36 ` [RFC PATCH 27/31] cifs: Convert SMB2 Tree Connect request David Howells
2025-08-06 20:36 ` [RFC PATCH 28/31] cifs: Convert SMB2 Tree Disconnect request David Howells
2025-08-06 20:36 ` [RFC PATCH 29/31] cifs: Rearrange Create request subfuncs David Howells
2025-08-06 20:36 ` [RFC PATCH 30/31] cifs: Convert SMB2 Posix Mkdir request David Howells
2025-08-06 20:36 ` [RFC PATCH 31/31] cifs: Convert SMB2 Open request David Howells
2025-08-07  5:23 ` [RFC PATCH 00/31] netfs: [WIP] Allow the use of MSG_SPLICE_PAGES and use netmem allocator Stefan Metzmacher
2025-08-07  6:24 ` David Howells
2025-08-07  6:54   ` Stefan Metzmacher
2025-08-07  7:12   ` David Howells [this message]
2025-08-08 14:15 ` Enzo Matsumiya
2025-08-08 17:25 ` David Howells
2025-08-08 19:58   ` Enzo Matsumiya
2025-08-08 20:33   ` David Howells
2025-08-10 23:29   ` David Howells
2025-08-11 12:25     ` Enzo Matsumiya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2573495.1754550778@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=almasrymina@google.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=metze@samba.org \
    --cc=pc@manguebit.org \
    --cc=sfrench@samba.org \
    --cc=sprasad@microsoft.com \
    --cc=tom@talpey.com \
    --cc=wangzhaolong@huaweicloud.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®