RE: [RFC PATCH 1/5] IB/core: Add Core Capability flags to ib_device

Liran Liss
2015-05-06T14:25:09Z

> From: Hefty, Sean [mailto:sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org]
> Sent: Tuesday, May 05, 2015 11:29 PM

> > > In other words, I think that 'protocol' should uniquely distinguish
> > interoperable
> > > peers at the Verbs API level. We are *not* trying to describe a
> > > certain
> > header,
> > > but rather a stack of protocols.
> >
> > Any non-UDP "protocol" that might currently be in use over usNIC is an
> > entirely application-level protocol outside of the view of the Verbs
> > API level.
>

Fine. Then we can add a 'udp/ip' protocol for usNIC.
Similarly, 'raw Ethernet' can designate the ability to inject of all headers starting from L2.

> I agree with this for usNIC. For other technologies, the definition isn't even
> this simple. UD QPs and RC QPs cannot interoperate, yet are treated as the
> same 'protocol'. Just defining protocol as a 'stack of protocols' shows how
> broken the approach is. And we haven't even tried to incorporate other
> 'protocols' needed to make this work, such as the CM or management
> protocols.

The interoperability between different transport objects depends on the technology.
I don't think that we should even attempt to describe these dependencies in any
abstract way. RTFM...

However, users should have a way of knowing what transports and what wire
protocol stacks a certain rdma device supports.

No one using IB or RoCE would think that UD and RC interoperate.
(If someone tries it, he would be disappointed 'gracefully'...)
But people that use RoCE would like to know which devices they can use to send
RoCE packets (or select a device that supports a certain RoCE version).

--Liran