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: <CAHS8izO2PU-A9gQHkJpB=QkFkiKvVUNCm5Von5GFY+5qV5+Oog@mail.gmail.com>
Date: Fri, 21 Feb 2025 16:11:58 -0800
From: Mina Almasry <almasrymina@...gle.com>
To: Stanislav Fomichev <stfomichev@...il.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-doc@...r.kernel.org, virtualization@...ts.linux.dev, 
	kvm@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	Donald Hunter <donald.hunter@...il.com>, Jonathan Corbet <corbet@....net>, 
	Andrew Lunn <andrew+netdev@...n.ch>, Jeroen de Borst <jeroendb@...gle.com>, 
	Praveen Kaligineedi <pkaligineedi@...gle.com>, Shailend Chand <shailend@...gle.com>, 
	Kuniyuki Iwashima <kuniyu@...zon.com>, Willem de Bruijn <willemb@...gle.com>, David Ahern <dsahern@...nel.org>, 
	Neal Cardwell <ncardwell@...gle.com>, "Michael S. Tsirkin" <mst@...hat.com>, Jason Wang <jasowang@...hat.com>, 
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Eugenio Pérez <eperezma@...hat.com>, 
	Stefan Hajnoczi <stefanha@...hat.com>, Stefano Garzarella <sgarzare@...hat.com>, Shuah Khan <shuah@...nel.org>, 
	sdf@...ichev.me, asml.silence@...il.com, dw@...idwei.uk, 
	Jamal Hadi Salim <jhs@...atatu.com>, Victor Nogueira <victor@...atatu.com>, 
	Pedro Tammela <pctammela@...atatu.com>, Samiullah Khawaja <skhawaja@...gle.com>
Subject: Re: [PATCH net-next v4 6/9] net: enable driver support for netmem TX

On Thu, Feb 20, 2025 at 11:13 AM Stanislav Fomichev
<stfomichev@...il.com> wrote:
>
> On 02/20, Mina Almasry wrote:
> > Drivers need to make sure not to pass netmem dma-addrs to the
> > dma-mapping API in order to support netmem TX.
> >
> > Add helpers and netmem_dma_*() helpers that enables special handling of
> > netmem dma-addrs that drivers can use.
> >
> > Document in netmem.rst what drivers need to do to support netmem TX.
> >
> > Signed-off-by: Mina Almasry <almasrymina@...gle.com>
> >
> > ---
> >
> > v4:
> > - New patch
> > ---
> >  .../networking/net_cachelines/net_device.rst  |  1 +
> >  Documentation/networking/netdev-features.rst  |  5 +++++
> >  Documentation/networking/netmem.rst           | 14 +++++++++++--
> >  include/linux/netdevice.h                     |  2 ++
> >  include/net/netmem.h                          | 20 +++++++++++++++++++
> >  5 files changed, 40 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/networking/net_cachelines/net_device.rst b/Documentation/networking/net_cachelines/net_device.rst
> > index 15e31ece675f..e3043b033647 100644
> > --- a/Documentation/networking/net_cachelines/net_device.rst
> > +++ b/Documentation/networking/net_cachelines/net_device.rst
> > @@ -10,6 +10,7 @@ Type                                Name                        fastpath_tx_acce
> >  =================================== =========================== =================== =================== ===================================================================================
> >  unsigned_long:32                    priv_flags                  read_mostly                             __dev_queue_xmit(tx)
> >  unsigned_long:1                     lltx                        read_mostly                             HARD_TX_LOCK,HARD_TX_TRYLOCK,HARD_TX_UNLOCK(tx)
> > +unsigned long:1                          netmem_tx:1;                read_mostly
> >  char                                name[16]
> >  struct netdev_name_node*            name_node
> >  struct dev_ifalias*                 ifalias
> > diff --git a/Documentation/networking/netdev-features.rst b/Documentation/networking/netdev-features.rst
> > index 5014f7cc1398..02bd7536fc0c 100644
> > --- a/Documentation/networking/netdev-features.rst
> > +++ b/Documentation/networking/netdev-features.rst
> > @@ -188,3 +188,8 @@ Redundancy) frames from one port to another in hardware.
> >  This should be set for devices which duplicate outgoing HSR (High-availability
> >  Seamless Redundancy) or PRP (Parallel Redundancy Protocol) tags automatically
> >  frames in hardware.
> > +
> > +* netmem-tx
> > +
> > +This should be set for devices which support netmem TX. See
> > +Documentation/networking/netmem.rst
> > diff --git a/Documentation/networking/netmem.rst b/Documentation/networking/netmem.rst
> > index 7de21ddb5412..43054d44c407 100644
> > --- a/Documentation/networking/netmem.rst
> > +++ b/Documentation/networking/netmem.rst
> > @@ -19,8 +19,8 @@ Benefits of Netmem :
> >  * Simplified Development: Drivers interact with a consistent API,
> >    regardless of the underlying memory implementation.
> >
> > -Driver Requirements
> > -===================
> > +Driver RX Requirements
> > +======================
> >
> >  1. The driver must support page_pool.
> >
> > @@ -77,3 +77,13 @@ Driver Requirements
> >     that purpose, but be mindful that some netmem types might have longer
> >     circulation times, such as when userspace holds a reference in zerocopy
> >     scenarios.
> > +
> > +Driver TX Requirements
> > +======================
> > +
> > +1. Driver should use netmem_dma_unmap_page_attrs() in lieu of
> > +   dma_unmap_page[_attrs](), and netmem_dma_unmap_addr_set() in lieu of
> > +   dma_unmap_addr_set(). The netmem variants will handle netmems that should
> > +   not be dma-unmapped by the driver, such as dma-buf netmems.
>
> Not all drivers use dma_unmap_addr_xxx APIs (looking at mlx5). Might
> be worth mentioning that for the drivers managing the mappings
> differently, care might be taken to not unmap netmems?
>

Yes now that I take a closer look, it's poorly worded to imply the
issue is limited to dma_unmap. I will reword to say that all
dma_map*() APIs must be avoided, and we have helpers for
dma_unmap_*(), and more helpers can be added if needed (similar to
wording in the Driver RX requirements).

> > +2. Driver should declare support by setting `netdev->netmem_tx = true`
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index fccc03cd2164..d8cfd5d69ddf 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -1753,6 +1753,7 @@ enum netdev_reg_state {
> >   *   @lltx:          device supports lockless Tx. Deprecated for real HW
> >   *                   drivers. Mainly used by logical interfaces, such as
> >   *                   bonding and tunnels
> > + *   @netmem_tx:     device support netmem_tx.
> >   *
> >   *   @name:  This is the first field of the "visible" part of this structure
> >   *           (i.e. as seen by users in the "Space.c" file).  It is the name
> > @@ -2061,6 +2062,7 @@ struct net_device {
> >       struct_group(priv_flags_fast,
> >               unsigned long           priv_flags:32;
> >               unsigned long           lltx:1;
> > +             unsigned long           netmem_tx:1;
> >       );
> >       const struct net_device_ops *netdev_ops;
> >       const struct header_ops *header_ops;
> > diff --git a/include/net/netmem.h b/include/net/netmem.h
> > index a2148ffb203d..1fb39ad63290 100644
> > --- a/include/net/netmem.h
> > +++ b/include/net/netmem.h
> > @@ -8,6 +8,7 @@
> >  #ifndef _NET_NETMEM_H
> >  #define _NET_NETMEM_H
> >
> > +#include <linux/dma-mapping.h>
> >  #include <linux/mm.h>
> >  #include <net/net_debug.h>
> >
> > @@ -267,4 +268,23 @@ static inline unsigned long netmem_get_dma_addr(netmem_ref netmem)
> >  void get_netmem(netmem_ref netmem);
> >  void put_netmem(netmem_ref netmem);
> >
>
> [..]
>
> > +#define netmem_dma_unmap_addr_set(NETMEM, PTR, ADDR_NAME, VAL)   \
> > +     do {                                                     \
> > +             if (!netmem_is_net_iov(NETMEM))                  \
> > +                     dma_unmap_addr_set(PTR, ADDR_NAME, VAL); \
> > +             else                                             \
> > +                     dma_unmap_addr_set(PTR, ADDR_NAME, 0);   \
> > +     } while (0)
>
> Any reason not do to static inline instaed?

Because the args passed to dma_unmap_addr_set are quite unique,
AFAICT. PTR is a pointer to any struct that has a field (anywhere)
inside of it called ADDR_NAME, then dma_unmap_addr_set does something
like:

PTR->ADDR_NAME = VAL;

A static inline needs well defined types, and I couldn't figure out
how to do that (or if it is possible), so a macro it is I guess.

Where I could, I went with static inline.

-- 
Thanks,
Mina

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ