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: <CAHS8izOHfWPGaAF0Ri6sN5SVbvD9k_u2-_WmHJHcwu4HDEXj-Q@mail.gmail.com>
Date: Wed, 11 Dec 2024 09:53:36 -0800
From: Mina Almasry <almasrymina@...gle.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.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, "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

On Tue, Dec 10, 2024 at 7:55 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> 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?
>

Sure, I can center the docs around netmem rather than 'memory providers'.

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

Drivers doing their own recycling is not currently supported, AFAICT.
Adding support for it in the future and maintaining it is doable, but
a headache. I also noticed with IDPF you're nacking drivers doing
their own recycling anyway, so I thought why not just declare all such
use cases as not supported to make the whole thing much simpler.
Drivers can deprecate their recycling while adding support for netmem
which brings them in line with what you're enforcing for new drivers
anyway.

The specific reason: currently drivers will get_page pp pages to hold
on to them to do their own recycling, right? We don't even have a
get_netmem equivalent. We could add one (and for the TX path, which is
coming along, I do add one), but even then, the pp needs to detect
elevated references on net_iovs to exclude them from pp recycling. The
mp also needs to understand/keep track of elevated refcounts and make
sure the page is returned to it when the elevated refcounts from the
driver are dropped.

-- 
Thanks,
Mina