linux-kernel - Re: [PATCH net-next v3 5/5] net: Document memory provider driver support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <da1583ed-21cb-4606-8aaf-cc55390cc3a8@infradead.org>
Date: Mon, 9 Dec 2024 09:43:43 -0800
From: Randy Dunlap <rdunlap@...radead.org>
To: Mina Almasry <almasrymina@...gle.com>, netdev@...r.kernel.org,
 Jakub Kicinski <kuba@...nel.org>, Pavel Begunkov <asml.silence@...il.com>,
 Kaiyuan Zhang <kaiyuanz@...gle.com>, Willem de Bruijn <willemb@...gle.com>,
 Samiullah Khawaja <skhawaja@...gle.com>, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Simon Horman <horms@...nel.org>, Jonathan Corbet <corbet@....net>,
 Jesper Dangaard Brouer <hawk@...nel.org>,
 Ilias Apalodimas <ilias.apalodimas@...aro.org>
Subject: Re: [PATCH net-next v3 5/5] net: Document memory provider driver
 support

Hi--

On 12/9/24 9:23 AM, Mina Almasry wrote:
> Document expectations from drivers looking to add support for device
> memory tcp or other memory provider based features.
> 
> Signed-off-by: Mina Almasry <almasrymina@...gle.com>
> 
> ---
>  Documentation/networking/index.rst           |  1 +
>  Documentation/networking/memory-provider.rst | 52 ++++++++++++++++++++
>  2 files changed, 53 insertions(+)
>  create mode 100644 Documentation/networking/memory-provider.rst
> 

> diff --git a/Documentation/networking/memory-provider.rst b/Documentation/networking/memory-provider.rst
> new file mode 100644
> index 000000000000..4eee3b01eb18
> --- /dev/null
> +++ b/Documentation/networking/memory-provider.rst
> @@ -0,0 +1,52 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +================
> +Memory providers
> +================
> +
> +
> +Intro

Full word, please.

> +=====
> +
> +Device memory TCP, and likely more upcoming features, are reliant in memory
> +provider support in the driver.

I can't quite parse after "features." Maybe "are reliant on"?
Maybe "in-memory"?
Should it be "reliable" instead of "reliant"? Internet tells me that
reliant means dependent on.

> +
> +
> +Driver support
> +==============
> +
> +1. The driver must support page_pool. The driver must not do its own recycling
> +   on top of page_pool.
> +
> +2. The driver must support tcp-data-split ethtool option.

                  must support the

> +
> +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
> +   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@...gle.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

                                       dma-mappable

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

thanks.
-- 
~Randy