Re: [PATCH rdma-next 00/13] RDMA/core: Ultra Ethernet transport verbs

[Doug Ledford <doug.ledford@hpe.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3296 bytes --]

On 10/14/26 5:08 PM, Jason Gunthorpe wrote:
> On Wed, Oct 14, 2026 at 04:57:16PM -0700, Doug Ledford wrote:
>> On 10/14/26 3:21 PM, Eric Davis via B4 Relay wrote:
>>> Ultra Ethernet defines a reliable unconnected transport. A queue pair
>>> sends to any peer in its job without a connection, incoming traffic is
>>> demultiplexed on a JobID rather than on a connection, and what a device
>>> orders is far weaker than IB or RoCE and varies between devices. None of
>>> that has a home in the current uverbs ABI.
>>>
>>> This series adds the generic half. The objects, methods, and attributes
>>> any UET device implements. No driver is part of it, though two already
>>> exist against this ABI. A reference device model that implements all of
>>> it, and HPE's Slingshot driver implementing a large subset. That is the
>>> argument for ib_core carrying this. What is device specific should come
>>> from private interfaces per vendor.
>>
>> I'm doing some cleanups and then will be sending our Slingshot driver
>> for initial review as a dependent item on this patchset.  Look for that
>> by the end of this week.
> 
> You each will give reviewd-by's for each others?

Absolutely.  We've been working with each other's patch series behind
the scenes already.

> You are running sashiko locally and fixing the bugs it finds?

Yes, but with one caveat here at HPE anyway: We have very limited AI
resources we are allowed to use for data exfiltration reasons (yeah, I
know, this is open source and we're intentionally exfiltrating it, but
company policy guides who we have contracts with).  We can currently
only use Github CoPilot.  We can select models, but those aren't the
same as going elsewhere.  I noticed for example that Eric used Gemini
for his, and I think he honestly got better responses than we did.

However, also keep in mind that this is adding a new QP type with
semantics much closer to Portals 4 API than verbs, and that does create
some friction not just with the rest of the stack, but with the AI
reviews judging by what I've already seen from the Sashiko reviews to
this series.

> There are several other new drivers right now, do we need to do
> another full driver review trading scheme?

Probably wouldn't hurt.  But, our driver is many more lines over in the
drivers/net/ethernet space than it is in the RDMA space.  Unless netdev
community makes me move a bunch of stuff over, we don't plan to move
what we don't have to.  There are reasons for it to be there in the
first place (namely that the device can run as a simple Ethernet
controller if someone so chooses, but it actually needs a lot of that
infrastructure the RDMA portion of the driver calls into just to get
simple Ethernet up and running).

>> Note: I dropped linux-kernel.  Unless things have changed, they usually
>> don't care too much about the rdma stuff until it's time for the merge
>> window and that list is already way overloaded as it stands.
> 
> Nobody reads that list I'm sure?

I dunno...does LWN still do a summary with each report?  Maybe only
automated tools deal with it...

-- 
Doug Ledford <doug.ledford@hpe.com>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]