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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250312112921.GA1322339@unreal>
Date: Wed, 12 Mar 2025 13:29:21 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Nikolay Aleksandrov <nikolay@...abrica.net>
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 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:
> >> Hi all,
> > 
> > <...>
> > 
> >> Ultra Ethernet is a new RDMA transport.
> > > Awesome, and now please explain why new subsystem is needed when
> > drivers/infiniband already supports at least 5 different RDMA
> > transports (OmniPath, iWARP, Infiniband, RoCE v1 and RoCE v2).
> > 
> 
> As Bernard commented, we're not trying to add a new subsystem, 

So why did you create new drivers/ultraeth/ folder?

> but start a discussion on where UEC should live because it has multiple
> objects and semantics that don't map well to the  current
> infrastructure. For example from this set - managing contexts, jobs and
> fabric endpoints. 

It is just different names which libfabric used to do not use
traditional verbs naming. There is nothing in the stack which prevents
from QP to have same properties as "fabric endpoints" have.

> 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