lkml.org 
[lkml]   [2015]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v6 01/26] IB/Verbs: Implement new callback query_transport()


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).
>
>


\
 
 \ /
  Last update: 2015-04-28 17:01    [W:0.155 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site