Re: [PATCH 00/11] Subject: [PATCH for-next 00/11] RDMA/cxi: add the HPE Cassini verbs driver

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

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

On 11/3/26 6:30 AM, Jason Gunthorpe wrote:
> On Tue, Nov 03, 2026 at 04:28:26PM +0200, Leon Romanovsky wrote:
>> On Fri, Oct 30, 2026 at 09:35:28PM -0700, Doug Ledford wrote:
>>> This series adds cxiverbs, an RDMA driver for the HPE Slingshot Cassini
>>> NIC. It exposes the NIC through the verbs API using the UET reliable
>>> unconnected (RU) queue pair type from the UET RDMA core series.
>>>
>>> cxiverbs does not drive the hardware itself. It is an auxiliary bus
>>> client of the cxi-ss1 Cassini core driver and does everything through
>>> that driver's exported CXI interface.
>>
>> <...>
>>
>>> Before posting, the series was reviewed with the Sashiko AI code
>>> review tool and checkpatch. All valid findings are fixed, except the
>>> open items listed above.
>>
>> <...>
>>
>>> ---
>>> base-commit: 306a2f8432f516069b2e673de7a07043132c034f
>>
>> Sashiko failed to apply this series as this base-commit doesn't exist.
>> ➜  kernel git:(wip/leon-for-rc) git show 306a2f8432f516069b2e673de7a07043132c034f
>> fatal: bad object 306a2f8432f516069b2e673de7a07043132c034f
>>
>> https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20261030-cxi-for-next-v1-0-bc6e49e07037@hpe.com__;Iw!!NpxR!jVGLxpaqGEPJ5fZJ3ZoNkSuC5-NuVK2GbaWiVfqG__a0SYh3NAgK9UqQPHsk4FEdYNCqDyPzXwao$ 
>>
>> Please make sure that upstream sashiko runs on it too.
> 
> I don't think he can, it relies on the core code series. I Don't know
> how to instruct sashiko how to find another series to stich it
> together
> 
> Jason

I wouldn't bother running sashiko yet.  I purposefully submitted our
driver in full to the netdev community, knowing that they'd never take
it that way.  But I wanted them to see the full driver and how it works
(most notably that it is not a generic Ethernet NIC with RX/TX
descriptor rings, but it's a Portals 4.0 API device with Portal Table
Entries that filter incoming packets to specific destinations) and what
size and complexity it involves.  It's not clear to me that the driver
should be in the netdev community, but maybe rather in the RDMA
community.  The only catch is that it passes native Ethernet packets via
hardware, it's just how they are mapped to send commands and filter recv
queues that's different.  So, I'm requesting they make a judgement call,
looking at the entire driver and what it would likely become even if I
spoon fed them small chunks at a time, and decide if it should be a
netdev device with an RDMA aux device, or an RDMA device with an
Ethernet aux device.

-- 
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 --]