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

Liran Liss
2015-05-05T19:27:58Z

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1690 bytes --]

> From: linux-rdma-owner@vger.kernel.org [mailto:linux-rdma-

> owner@vger.kernel.org] On Behalf Of Hefty, Sean
> >
> > In accordance with what we've been talking about, drop IBOE for ROCE.
> >
> > Drop the UDP off of USNIC, then define a bit for CAP_PROT_UDP_ENCAP.
> > USNIC will be just USNIC, USNIC_UDP will be USNIC | UDP_ENCAP, ROCE v1
> > will be ROCE, and ROCEv2 will be ROCE | UDP_ENCAP.
>
> USNIC_UDP is just UDP. I don't understand why we would want 'USNIC |
> UDP_ENCAP', or what UDP_ENCAP is intended to convey. Nothing is being
> encapsulated.
>

I agree that the UDP_ENCAP notion is confusing.
We should stick to ROCE_V1 and ROCE_V2.

> RoCEv2 is IB transport over UDP.
>
> I'm not sure what the protocol field is intended to imply. If we want to
> expose the link, network, transport, and RDMA protocols in use, shouldn't
> these be separate fields or bits? And even then, I'm not sure what use this
> has for the ULPs. iWarp does not require Ethernet or TCP. RoCEv2 would
> work fine over any link. And the core layer should not assume that a device is
> limited to supporting only one protocol, especially at the network and
> transport levels. I vote for deprecating the protocol goofiness.
>
> - Sean

The protocol notion might not have any value for ULPs, but it is useful for core
management code. Also, when we extend these notions to user-space, admins will
actually want to know what wire protocols a certain device can support, even
just for the sake of interoperability.

--Liran

N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±­ÙšŠ{ayº\x1dÊ‡Ú™ë,j\a­¢f£¢·hš‹»öì\x17/oSc¾™Ú³9˜uÀ¦æå‰È&jw¨®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿïêäz¹Þ–Šàþf£¢·hšˆ§~ˆmš