Re: [PATCH rdma-next 02/13] RDMA/core: add the UET GID types

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Oct 15, 2026 at 09:14:22PM +0000, Sean Hefty wrote:
> > > > > > Could this cause incoming UET packets to be incorrectly mapped
> > > > > > to a
> > > > > > RoCEv2 GID index, breaking the UET transport response?
> > > > >
> > > > > On a port that runs both RoCE and UET the MAD traffic is RoCE, so
> > > > > mapping it to RoCEv2 is correct.
> > > >
> > > > You will need seperate ROCE and UET ib_devices with the current
> > > > state of affairs, we don't support multi-protocol today.
> > >
> > > UEC intentionally considered multi-protocol devices, with a vendor deciding
> > whether it would need to provide separate SW devices.  E.g. using UET for
> > MPI, but RoCE for storage.  Protocol selection is via GID, same as RoCEv1 vs
> > v2.
> > >
> > > What blocks multi-protocol support?
> > 
> > Principally I don't think we have the APIs to discover and link the GUID to
> > protocol to QP type appropriately..
> 
> I'm missing something regarding the GUID comment.
> 
> The QP protocol comes from GID index, which is discoverable via
> ibv_gid_entry::gid_type.  (UET QPs require the GID index on create.)

Hmm, that's not the normal case, but I see what you are thinking

> E.g. a dual RoCE + UET device would report node_type = UNSPECIFIED &
> transport_type = UNSPECIFIED.  GID entries indicate supported
> protocols.

Ah, that would need some opt in scheme to get there, but I supppose it
may not be so bad.

I thought there were other issues like PDs not being entirely
compatible, MRs, and so on?

Jason