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@xxxxxxxxxxxx/ > Sure, I know how uverbs work, but thanks for the pointer! > Thanks> Cheers, Nik >> >> Cheers, >> Nik >> >>
