docs: netmem: document netmem and memory provider design principles

Add a Design Principles section to Documentation/networking/netmem.rst
covering the netmem_ref abstraction, the prohibition on direct
downcasting in callers, decoupling memory providers from net_iov,
decoupling net_iov from unreadability, delegating provider/type logic to
memory_provider_ops and netmem helpers, and the rule against mixing skb
fragment memory sources.

Cc: Luigi Rizzo <lrizzo@google.com>
Signed-off-by: Mina Almasry <almasrymina@google.com>
Reviewed-by: Björn Töpel <bjorn@kernel.org>
Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20261010033630.1171692-3-almasrymina@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

1 files changed, 53 insertions, 0 deletions

diff --git a/Documentation/networking/netmem.rst b/Documentation/networking/netmem.rst
index 217869d1108d..6871dcdd700c 100644
--- a/Documentation/networking/netmem.rst
+++ b/Documentation/networking/netmem.rst
@@ -19,6 +19,59 @@ Benefits of Netmem :
 * Simplified Development: Drivers interact with a consistent API,
   regardless of the underlying memory implementation.
 
+Design Principles
+=================
+
+Memory providers (or the default ``page_pool`` allocator) allocate underlying
+memory (``struct net_iov`` or ``struct page``), cast it to ``netmem_ref``, and
+supply it to ``page_pool``. The ``page_pool``, drivers, and networking stack
+operate on ``netmem_ref`` as the abstract type. Existing ``page_pool`` APIs
+that allocate or free ``struct page`` are legacy compatibility wrappers for
+drivers that do not yet support ``netmem_ref``. Code that is not yet
+``netmem``-aware should be converted to ``netmem_ref`` unless it will never
+need to support ``netmem``.
+
+1. **Operate on netmem_ref, do not downcast**: ``page_pool``, drivers, and the
+   core networking stack should deal with ``netmem_ref`` rather than
+   ``struct net_iov`` or ``struct page``. Downcasting ``netmem_ref`` to
+   ``struct net_iov`` or ``struct page`` is not allowed unless a code path
+   strictly cannot function without knowing the underlying memory type (for
+   example, ``kmap_local_page()``). In those cases, to keep call sites simple,
+   add a ``netmem`` helper that performs the operation on behalf of the caller,
+   cleanly handles all ``net_iov`` and ``page`` cases, and returns an error if
+   the ``netmem`` type cannot support the requested operation.
+
+2. **Decouple memory providers from net_iov**: Memory providers are not
+   architecturally limited to ``struct net_iov``; a memory provider that returns
+   ``struct page``-backed ``netmem_ref``\ s to upper layers is allowed. Today,
+   in-tree memory providers only supply ``struct net_iov`` and some existing
+   code still reflects that limitation, but new code must not assume that using
+   a memory provider implies ``net_iov`` memory and should, as much as possible,
+   generalize existing limitations to match the design principles.
+
+3. **Decouple net_iov from unreadability**: ``struct net_iov`` is flexible and
+   has no inherent restrictions; it may represent either CPU-readable or
+   unreadable memory. Today, in-tree ``net_iov`` implementations are unreadable
+   by the CPU (``netmem_address()`` returns ``NULL``) and some existing code
+   still reflects that limitation, but new code must not assume ``net_iov``
+   implies unreadable memory (check readability via ``netmem_address()`` or
+   ``skb_frags_readable()`` instead) and should, as much as possible, generalize
+   existing limitations to match the design principles.
+
+4. **Delegate complexity to the lowest layer**: Each layer must respect its
+   abstraction boundary. ``page_pool`` must not implement per-memory-provider
+   custom logic in its main code; instead, it delegates provider-specific
+   handling to ``struct memory_provider_ops``. Similarly, core networking code
+   should avoid per-``netmem``-type branching and instead delegate operations
+   to ``netmem`` helpers that handle the underlying memory type.
+
+5. **Do not mix skb fragment memory sources**: All ``frags[]`` in an
+   ``sk_buff`` must either be ``struct page``-backed or belong to the same
+   memory provider instance (for example, the same ``devmem`` binding or
+   ``io_uring`` area). Mixing ``struct page`` and memory-provider fragments,
+   or mixing fragments from different memory providers within a single
+   ``sk_buff``, is not allowed (including when coalescing ``sk_buff``\ s).
+
 Driver RX Requirements
 ======================