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.
