On Sat, 28 Jan 2023 14:06:49 +0000 Chuck Lever III wrote:

quoted

On Jan 28, 2023, at 3:32 AM, Jakub Kicinski [off-list ref] wrote:
On Thu, 26 Jan 2023 11:02:22 -0500 Chuck Lever wrote:  

quoted

I've designed a way to pass a connected kernel socket endpoint to
user space using the traditional listen/accept mechanism. accept(2)
gives us a well-worn building block that can materialize a connected
socket endpoint as a file descriptor in a specific user space
process. Like any open socket descriptor, the accepted FD can then
be passed to a library such as GnuTLS to perform a TLS handshake.  

I can't bring myself to like the new socket family layer.  

poll/listen/accept is the simplest and most natural way of
materializing a socket endpoint in a process that I can think
of. It's a well-understood building block. What specifically
is troubling you about it?

poll/listen/accept yes, but that's not the entire socket interface. 
Our overall experience with the TCP ULPs is rather painful, proxying
all the other callbacks here may add another dimension.

Also I have a fear (perhaps unjustified) of reusing constructs which are
cornerstones of the networking stack and treating them as abstractions.

quoted

I'd like a second opinion on that, if anyone within netdev
is willing to share..  

Hopefully that opinion comes with an alternative way of getting
a connected kernel socket endpoint up to user space without
race issues.

If the user application decides the fd, wouldn't that solve the problem
in netlink?

  kernel                          user space

   notification     ---------->
 (new connection awaits)

                    <----------
                                  request (target fd=100)

                    ---------->
   reply
 (fd 100 is installed;
  extra params)

We need to make some progress on this. If you don't have a
technical objection, I think we should go with this with the
idea that eventually something more palatable will come along
to replace it.