netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Mina Almasry <almasrymina@google.com>
Cc: netdev@vger.kernel.org, Pavel Begunkov <asml.silence@gmail.com>,
	Kaiyuan Zhang <kaiyuanz@google.com>,
	Willem de Bruijn <willemb@google.com>,
	Samiullah Khawaja <skhawaja@google.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>
Subject: Re: [PATCH net-next v3 5/5] net: Document memory provider driver support
Date: Tue, 10 Dec 2024 19:55:13 -0800	[thread overview]
Message-ID: <20241210195513.116337b9@kernel.org> (raw)
In-Reply-To: <20241209172308.1212819-6-almasrymina@google.com>

On Mon,  9 Dec 2024 17:23:08 +0000 Mina Almasry wrote:
> +================
> +Memory providers
> +================
> +
> +
> +Intro
> +=====
> +
> +Device memory TCP, and likely more upcoming features, are reliant in memory
> +provider support in the driver.

Are "memory providers" something driver authors care about?
I'd go with netmem naming in all driver facing APIs.
Or perhaps say placing data into unreable buffers?

> +Driver support
> +==============
> +
> +1. The driver must support page_pool. The driver must not do its own recycling
> +   on top of page_pool.

I like the rule, but is there a specific reason driver can't do its own
recycling?

> +2. The driver must support tcp-data-split ethtool option.
> +
> +3. The driver must use the page_pool netmem APIs. The netmem APIs are
> +   currently 1-to-1 mapped with page APIs. Conversion to netmem should be

mapped => correspond ?

> +   achievable by switching the page APIs to netmem APIs and tracking memory via
> +   netmem_refs in the driver rather than struct page * :
> +
> +   - page_pool_alloc -> page_pool_alloc_netmem
> +   - page_pool_get_dma_addr -> page_pool_get_dma_addr_netmem
> +   - page_pool_put_page -> page_pool_put_netmem
> +
> +   Not all page APIs have netmem equivalents at the moment. If your driver
> +   relies on a missing netmem API, feel free to add and propose to netdev@ or
> +   reach out to almasrymina@google.com for help adding the netmem API.
> +
> +4. The driver must use the following PP_FLAGS:
> +
> +   - PP_FLAG_DMA_MAP: netmem is not dma mappable by the driver. The driver
> +     must delegate the dma mapping to the page_pool.
> +   - PP_FLAG_DMA_SYNC_DEV: netmem dma addr is not necessarily dma-syncable
> +     by the driver. The driver must delegate the dma syncing to the page_pool.
> +   - PP_FLAG_ALLOW_UNREADABLE_NETMEM. The driver must specify this flag iff
> +     tcp-data-split is enabled. In this case the netmem allocated by the
> +     page_pool may be unreadable, and netmem_address() will return NULL to
> +     indicate that. The driver must not assume that the netmem is readable.

Should we turn the netmem_address() explanation into a point of its own,
calling out restrictions on use of CPU addresses, netmem_to_page() etc?

> +5. The driver must use page_pool_dma_sync_netmem_for_cpu() in lieu of
> +   dma_sync_single_range_for_cpu(). For some memory providers, dma_syncing for
> +   CPU will be done by the page_pool, for others (particularly dmabuf memory
> +   provider), dma syncing for CPU is the responsibility of the userspace using
> +   dmabuf APIs. The driver must delegate the entire dma-syncing operation to
> +   the page_pool which will do it correctly.

  parent reply	other threads:[~2024-12-11  3:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-09 17:23 [PATCH net-next v3 0/5] devmem TCP fixes Mina Almasry
2024-12-09 17:23 ` [PATCH net-next v3 1/5] net: page_pool: rename page_pool_alloc_netmem to *_netmems Mina Almasry
2024-12-09 17:23 ` [PATCH net-next v3 2/5] net: page_pool: create page_pool_alloc_netmem Mina Almasry
2024-12-09 17:23 ` [PATCH net-next v3 3/5] page_pool: Set `dma_sync` to false for devmem memory provider Mina Almasry
2024-12-11  3:44   ` Jakub Kicinski
2024-12-09 17:23 ` [PATCH net-next v3 4/5] page_pool: disable sync for cpu for dmabuf " Mina Almasry
2024-12-11  3:47   ` Jakub Kicinski
2024-12-11 19:40     ` Mina Almasry
2024-12-09 17:23 ` [PATCH net-next v3 5/5] net: Document memory provider driver support Mina Almasry
2024-12-09 17:43   ` Randy Dunlap
2024-12-11  3:55   ` Jakub Kicinski [this message]
2024-12-11 17:53     ` Mina Almasry
2024-12-12  2:28       ` Jakub Kicinski
2024-12-13 17:50         ` Mina Almasry
2024-12-14  1:55           ` Jakub Kicinski

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=20241210195513.116337b9@kernel.org \
    --to=kuba@kernel.org \
    --cc=almasrymina@google.com \
    --cc=asml.silence@gmail.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=horms@kernel.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=kaiyuanz@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=skhawaja@google.com \
    --cc=willemb@google.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;
as well as URLs for NNTP newsgroup(s).