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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Oct 15, 2026 at 06:57:31PM +0000, Sean Hefty wrote:
> > On Thu, Oct 15, 2026 at 08:57:44AM -0700, Eric Davis wrote:
> > > On Wed, Oct 14, 2026 at 3:35 PM <sashiko-bot@kernel.org> wrote:
> > > > Sashiko AI review found 3 potential issue(s) to consider:
> > >
> > > Disagree with all three and no change planned. None of these paths
> > > runs on a UET port.
> > >
> > > A UET port's core_cap_flags are RDMA_CORE_CAP_PROT_UET_[UDP|IP] plus
> > > RDMA_CORE_CAP_ETH_AH. It has no IB_MAD, IB_CM, IB_SA or IB_MCAST
> > bit.
> > >
> > > > Does this explicitly fail Address Handle initialization for UET-only ports?
> > >
> > > Yes, deliberately. ib_init_ah_attr_from_wc() is called by the MAD
> > > agent, the CM, mad_rmpp, and user_mad. These all need IB_MAD, so none
> > > of them sees a completion from a UET-only port. The check is a guard
> > > as an unconnected peer is named through an extended address handle
> > > (patch 5) or the job's address table (patch 7), never from a WC.
> > 
> > How much of this follows the work Sean did in the consortium? I thought he
> > had defined AHs?
> 
> Eric and I worked closely.  Most of the UEC work focused on the user-space interfaces, but the overall structure should be aligned.
> 
> UEC defined an extended AH.  ib_init_ah_attr_from_wc() could probably be extended to support UET, I don't think it would be used, however.
> 
> > > > 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..

Jason