[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1742b7e9-b815-4c12-9c22-aea298afe822@enfabrica.net>
Date: Wed, 12 Mar 2025 18:00:17 +0200
From: Nikolay Aleksandrov <nikolay@...abrica.net>
To: Leon Romanovsky <leon@...nel.org>
Cc: 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 3/12/25 5:10 PM, 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.
>
I should've been more specific - it is not an issue for UEC and the way
our driver's netlink API is designed. We fully understand the pros and
cons of our approach.
> However, this discussion is premature and as an intro it is worth to
> read this cover letter for how object management is done in RDMA
> subsystem.
>
> https://lore.kernel.org/linux-rdma/1501765627-104860-1-git-send-email-matanb@mellanox.com/
>
Sure, I know how uverbs work, but thanks for the pointer!
> Thanks>
Cheers,
Nik
>>
>> Cheers,
>> Nik
>>
>>
Powered by blists - more mailing lists