Re: [PATCH v6 01/26] IB/Verbs: Implement new callback query_transport()

[Michael Wang <yun.wang@profitbricks.com>]

On 04/28/2015 03:24 AM, Doug Ledford wrote:
[snip]
>>>> Also wondering, why add "UDP" to USNIC, is there a different USNIC?
>>>
>>> Yes, there are two transports, one a distinct ethertype and one that
>>> encapsulates USNIC in UDP.
>>
>> But this new enum isn't about transport, it's about protocol. So is
>> there one USNIC protocol, with a raw layering and a separate one with
>> UDP? Or is it one USNIC protocol with two different framings? Seems
>> there should be at least the USNIC protocol, without the _UDP
>> decoration, and I don't see it in the enum.
> 
> Keep in mind that this enum was Liran's response to Michael's original
> patch.  In the enum in Michael's patch, there was both USNIC and
> USNIC_UDP.

Yeah, I've not enum PROTOCOL_USNIC since currently there is no place
need it...

The only three cases currently are:
1. trasnport IB, link layer IB		//PROTOCOL_IB
2. transport IB, link layer ETH		//PROTOCOL_IBOE
3. transport IWARP			//PROTOCOL_IWARP

Regards,
Michael Wang

> 
>>>
>>>> Naming multiple layers together seems confusing and maybe in the end
>>>> will create more code to deal with the differences. For example, what
>>>> token will RoCEv2 take? RoCE_UDP, RoCE_v2 or ... ?
>>>
>>> Uncertain as of now.
>>
>> Ok, but it's imminent, right? What's the preference/guidance?
> 
> There is a patchset from Devesh Sharma at Emulex.  It added the RoCEv2
> capability.  As I recall, it used a new flag added to the existing port
> capabilities bitmask and notably did not modify either the node type or
> link layer that are currently used to differentiate between the
> different protocols.  That's from memory though, so I could be mistaken.
> 
> But that patchset was not written with this patchset in mind, and
> merging the two may well change that.  In any case, there is a proposed
> spec to follow, so for now that's the preference/guidance (unless this
> rework means that we need to depart from the spec on internals for
> implementation reasons).
> 
>