From: Stanislav Fomichev <stfomichev@gmail.com>
To: Mina Almasry <almasrymina@google.com>
Cc: Bobby Eshleman <bobbyeshleman@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Kuniyuki Iwashima <kuniyu@google.com>,
Willem de Bruijn <willemb@google.com>,
Neal Cardwell <ncardwell@google.com>,
David Ahern <dsahern@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Jonathan Corbet <corbet@lwn.net>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Shuah Khan <shuah@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kselftest@vger.kernel.org,
Stanislav Fomichev <sdf@fomichev.me>,
Bobby Eshleman <bobbyeshleman@meta.com>
Subject: Re: [PATCH net-next v6 5/6] net: devmem: document SO_DEVMEM_AUTORELEASE socket option
Date: Wed, 5 Nov 2025 15:17:06 -0800 [thread overview]
Message-ID: <aQva8v22RVQEgPi_@mini-arch> (raw)
In-Reply-To: <aQumHEL6GgxsPQEM@mini-arch>
On 11/05, Stanislav Fomichev wrote:
> On 11/05, Mina Almasry wrote:
> > On Wed, Nov 5, 2025 at 9:34 AM Stanislav Fomichev <stfomichev@gmail.com> wrote:
> > >
> > > On 11/04, Bobby Eshleman wrote:
> > > > From: Bobby Eshleman <bobbyeshleman@meta.com>
> > > >
> > >
> > > [..]
> > >
> > > > +Autorelease Control
> > > > +~~~~~~~~~~~~~~~~~~~
> > >
> > > Have you considered an option to have this flag on the dmabuf binding
> > > itself? This will let us keep everything in ynl and not add a new socket
> > > option. I think also semantically, this is a property of the binding
> > > and not the socket? (not sure what's gonna happen if we have
> > > autorelease=on and autorelease=off sockets receiving to the same
> > > dmabuf)
> >
> > I think this thread (and maybe other comments on that patch) is the
> > context that missed your inbox:
> >
> > https://lore.kernel.org/netdev/aQIoxVO3oICd8U8Q@devvm11784.nha0.facebook.com/
> >
> > Let us know if you disagree.
>
> Thanks, I did miss that whole v5 because I was OOO, let me take a look!
Thank you for the context!
I think that the current approach is ok, we can go with that, but I
wonder whether we can simplify things a bit? What if we prohibit the
co-existence of autorelease=on and autorelease=off sockets on the
system? The first binding basically locks the kernel path into one way or
the other (presumably by using static-branch) and prohibits new bindings
that use a different mode. It will let us still keep the mode on the binding
and will help us not think about the co-existance (we can also still keep
things like one-dmabuf-per-socket restrictions in the new mode, etc).
I think for you, Mina, this should still work? You have a knob to go back
to the old mode if needed. At the same time, we keep the UAPI surface
smaller and keep the path more simple. Ideally, we can also deprecate
the old mode at some point (if you manage to successfully migrate of
course). WDYT?
next prev parent reply other threads:[~2025-11-05 23:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 1:23 [PATCH net-next v6 0/6] net: devmem: improve cpu cost of RX token management Bobby Eshleman
2025-11-05 1:23 ` [PATCH net-next v6 1/6] net: devmem: rename tx_vec to vec in dmabuf binding Bobby Eshleman
2025-11-05 1:23 ` [PATCH net-next v6 2/6] net: devmem: refactor sock_devmem_dontneed for autorelease split Bobby Eshleman
2025-11-05 1:23 ` [PATCH net-next v6 3/6] net: devmem: prepare for autorelease rx token management Bobby Eshleman
2025-11-05 16:02 ` kernel test robot
2025-11-05 20:55 ` kernel test robot
2025-11-06 15:11 ` Dan Carpenter
2025-11-06 15:14 ` Dan Carpenter
2025-11-05 1:23 ` [PATCH net-next v6 4/6] net: devmem: add SO_DEVMEM_AUTORELEASE for autorelease control Bobby Eshleman
2025-11-05 17:16 ` kernel test robot
2025-11-05 1:23 ` [PATCH net-next v6 5/6] net: devmem: document SO_DEVMEM_AUTORELEASE socket option Bobby Eshleman
2025-11-05 17:34 ` Stanislav Fomichev
2025-11-05 17:44 ` Mina Almasry
2025-11-05 19:31 ` Stanislav Fomichev
2025-11-05 23:17 ` Stanislav Fomichev [this message]
2025-11-07 2:22 ` Bobby Eshleman
2025-11-05 17:59 ` Bobby Eshleman
2025-11-05 1:23 ` [PATCH net-next v6 6/6] net: devmem: add tests for " Bobby Eshleman
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=aQva8v22RVQEgPi_@mini-arch \
--to=stfomichev@gmail.com \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=arnd@arndb.de \
--cc=bobbyeshleman@gmail.com \
--cc=bobbyeshleman@meta.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--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).