netdev - Re: [RFC PATCH 00/13] Ultra Ethernet driver introduction

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z9sXEXeE1iM5tMcy@mini-arch>
Date: Wed, 19 Mar 2025 12:12:17 -0700
From: Stanislav Fomichev <stfomichev@...il.com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Nikolay Aleksandrov <nikolay@...abrica.net>, netdev@...r.kernel.org,
	shrijeet@...abrica.net, alex.badea@...sight.com,
	eric.davis@...adcom.com, rip.sohan@....com, dsahern@...nel.org,
	bmt@...ich.ibm.com, roland@...abrica.net, winston.liu@...sight.com,
	dan.mihailescu@...sight.com, kheib@...hat.com,
	parth.v.parikh@...sight.com, davem@...hat.com, ian.ziemba@....com,
	andrew.tauferner@...nelisnetworks.com, welch@....com,
	rakhahari.bhunia@...sight.com, kingshuk.mandal@...sight.com,
	linux-rdma@...r.kernel.org, kuba@...nel.org, pabeni@...hat.com,
	Jason Gunthorpe <jgg@...dia.com>
Subject: Re: [RFC PATCH 00/13] Ultra Ethernet driver introduction

On 03/17, Leon Romanovsky wrote:
> On Fri, Mar 14, 2025 at 01:51:33PM -0700, Stanislav Fomichev wrote:
> > On 03/12, Leon Romanovsky wrote:
> > > On Wed, Mar 12, 2025 at 04:20:08PM +0200, Nikolay Aleksandrov wrote:
> > > > On 3/12/25 1:29 PM, Leon Romanovsky wrote:
> > > > > On Wed, Mar 12, 2025 at 11:40:05AM +0200, Nikolay Aleksandrov wrote:
> > > > >> On 3/8/25 8:46 PM, Leon Romanovsky wrote:
> > > > >>> On Fri, Mar 07, 2025 at 01:01:50AM +0200, Nikolay Aleksandrov wrote:
> > > > [snip]
> > > > >> Also we have the ephemeral PDC connections>> that come and go as
> > > > needed. There more such objects coming with more
> > > > >> state, configuration and lifecycle management. That is why we added a
> > > > >> separate netlink family to cleanly manage them without trying to fit
> > > > >> a square peg in a round hole so to speak.
> > > > > 
> > > > > Yeah, I saw that you are planning to use netlink to manage objects,
> > > > > which is very questionable. It is slow, unreliable, requires sockets,
> > > > > needs more parsing logic e.t.c
> > > > > 
> > > > > To avoid all this overhead, RDMA uses netlink-like ioctl calls, which
> > > > > fits better for object configurations.
> > > > > 
> > > > > Thanks
> > > > 
> > > > We'd definitely like to keep using netlink for control path object
> > > > management. Also please note we're talking about genetlink family. It is
> > > > fast and reliable enough for us, very easily extensible,
> > > > has a nice precise object definition with policies to enforce various
> > > > limitations, has extensive tooling (e.g. ynl), communication can be
> > > > monitored in realtime for debugging (e.g. nlmon), has a nice human
> > > > readable error reporting, gives the ability to easily dump large object
> > > > groups with filters applied, YAML family definitions and so on.
> > > > Having sockets or parsing are not issues.
> > > 
> > > Of course it is issue as netlink relies on Netlink sockets, which means
> > > that you constantly move your configuration data instead of doing
> > > standard to whole linux kernel pattern of allocating configuration
> > > structs in user-space and just providing pointer to that through ioctl
> > > call.
> > 
> > And you still call copy_from_user on that user-space pointer. So how
> > is it an improvement over netlink? netlink is just a flexible tlv,
> > if you don't like read/write calls, we can add netlink_ioctl with
> > a pointer to netlink message...
> 
> You need to built that netlink message, which you do by multiple copying
> in the user space.
>
> I understand your desire to see netdev patterns everywhere and agree
> with the position that netlink is a perfect choice for dynamic configurations.
> However I hold a position that it is not good fit to configure strictly dependent
> hardware objects.
> 
> You already have TLB-based API in drivers/infiniband, there is no need
> to invent new one.

Let's revisit this discussion later depending on where ultra eth stuff
lands. If it gets folded into ibv subsystem - keeping the same ibv
conventions makes sense. If not, not sure I understand your "multiple copying
in the user space" argument.