[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a793b8ae257e87fd58e6849f3529f3b886b68262.camel@redhat.com>
Date: Thu, 09 Feb 2023 17:02:12 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Chuck Lever III <chuck.lever@...cle.com>,
Jakub Kicinski <kuba@...nel.org>
Cc: Eric Dumazet <edumazet@...gle.com>,
"open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
"hare@...e.com" <hare@...e.com>,
David Howells <dhowells@...hat.com>,
Benjamin Coddington <bcodding@...hat.com>,
Olga Kornievskaia <kolga@...app.com>,
"jmeneghi@...hat.com" <jmeneghi@...hat.com>
Subject: Re: [PATCH v3 1/2] net/handshake: Create a NETLINK service for
handling handshake requests
On Thu, 2023-02-09 at 15:43 +0000, Chuck Lever III wrote:
> > On Feb 9, 2023, at 1:00 AM, Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Tue, 07 Feb 2023 16:41:13 -0500 Chuck Lever wrote:
> > > diff --git a/tools/include/uapi/linux/netlink.h
> > > b/tools/include/uapi/linux/netlink.h
> > > index 0a4d73317759..a269d356f358 100644
> > > --- a/tools/include/uapi/linux/netlink.h
> > > +++ b/tools/include/uapi/linux/netlink.h
> > > @@ -29,6 +29,7 @@
> > > #define NETLINK_RDMA 20
> > > #define NETLINK_CRYPTO 21 /* Crypto layer */
> > > #define NETLINK_SMC 22 /* SMC monitoring */
> > > +#define NETLINK_HANDSHAKE 23 /* transport layer sec
> > > handshake requests */
> >
> > The extra indirection of genetlink introduces some complications?
>
> I don't think it does, necessarily. But neither does it seem
> to add any value (for this use case). <shrug>
To me it introduces a good separation between the handshake mechanism
itself and the current subject (sock).
IIRC the previous version allowed the user-space to create a socket of
the HANDSHAKE family which in turn accept()ed tcp sockets. That kind of
construct - assuming I interpreted it correctly - did not sound right
to me.
Back to these patches, they looks sane to me, even if the whole
architecture is a bit hard to follow, given the non trivial cross
references between the patches - I can likely have missed some relevant
point.
I'm wondering if this approach scales well enough with the number of
concurrent handshakes: the single list looks like a potential bottle-
neck.
Cheers,
Paolo
Powered by blists - more mailing lists