Re: [PATCH RFC] Documentation/infiniband: Add docs for rdma-helpers

[Michael Wang]

On 05/15/2015 04:27 PM, Doug Ledford wrote:
[snip]
>>
>> Me too used to think it's 'connection', while I found some docs explain
>> this as 'communication'... but anyway, 'connection' sounds
>> more close to what it did in kernel :-)
> 
> That's kind of what I thought.  Anyway, it's communication management
> (which to me is a gross abuse of the english language for which the IBTA
> should be appropriately chastised), but that doesn't mean that lower
> down in the more descriptive area of text that we can't call out that
> this is really for establishing a connection and that once your
> connection is established and you *truly* want to communicate, this does
> nothing.

I see :-) we can reserve the communication management as the definition of CM,
to obey the standard, meanwhile give some description related to connection
below in the long description.

> 
[snip]
>> Shall we put this long description into USAGE? Here maybe list
>> all the helpers to give some quick overview with a brief
>> description, what's your opinion?
> 
> Given how we have a more complete description of this below, it need not
> have such a lengthy description here.

Got it :-)

Regards,
Michael Wang

>>
>>>> +
>>>> +USAGE
>>>> +
>>>> +  if (rdma_cap_XX(device, i)) {
>>>> +	/* The port i of device support XX */
>>>> +	...
>>>> +  } else {
>>>> +	/* The port i of device don't support XX */
>>>> +	...
>>>> +  }
>>>> +
>>>> +  rdma_cap_ib_mad
>>>> +  ---------------
>>>> +    Management Datagrams (MAD) is the prototype of management packet
>>>> +    to be used by all the kinds of infiniband managers, use the helper
>>>> +    to verify the port before utilize related features.
>>> Management Datagrams (MAD) are a required part of the InfiniBand
>>> specification and are supported on all InfiniBand devices.  A slightly
>>> extended version are also supported on OPA interfaces.
>>>
>>> I would drop all instances of "use the helper to verify..." as that's
>>> redundant.  This whole doc is about using the helpers to verify things.
>>
>> Agree, will be dropped in next version.
>>
>> And all the comments below make sense, will be merged ;-)
>>
>> Regards,
>> Michael Wang
>>
>>>
>>>> +
>>>> +  rdma_cap_ib_smi
>>>> +  ---------------
>>>> +    Subnet Management Interface (SMI) will handle SMP packet from SM
>>>> +    in an infiniband fabric, use the helper to verify the port before
>>>> +    utilize related features.
>>>> +
>>>> +  rdma_cap_ib_cm
>>>> +  ---------------
>>>> +    Communication Manager (CM) will handle the connections between
>>>        ^Connection Manager (CM) service, used to ease the process of
>>> connecting to a remote host.  The IB CM can be used to connect to remote
>>> hosts using either InfiniBand or RoCE connections.  iWARP has its own
>>> connection manager, see below.
>>>> +    adaptors, currently there are two different implementation,
>>>> +    IB or IWARP, use the helper to verify whether the port using
>>>> +    IB-CM or not
>>>> +
>>>> +  rdma_cap_iw_cm
>>>> +  ---------------
>>>> +    IWARP has it's own implemented CM which is different from infiniband,
>>>       iWARP connection manager.  Similar to the IB Connection Manager,
>>> but only used on iWARP devices.
>>>> +    use the helper to check whether the port using IWARP-CM or not.
>>>> +
>>>> +  rdma_cap_ib_sa
>>>> +  ---------------
>>>> +    Subnet Administration (SA) is the database built by SM in an
>>>> +    infiniband fabric, use the helper to verify the port before
>>>> +    utilize related features.
>>>> +
>>>> +  rdma_cap_ib_mcast
>>>> +  ---------------
>>>> +    Multicast is the feature for one QP to send messages to multiple
>>>> +    QP in an infiniband fabric, use the helper to verify the port before
>>>> +    utilize related features.
>>>
>>> InfiniBand (and OPA) use a different multicast mechanism than
>>> traditional IP multicast found on Ethernet devices.  If this capability
>>> is true, then traditional IPv4/IPv6 multicast is handled by the IPoIB
>>> layer and direct multicast joins and leaves are handled per the
>>> InfiniBand specifications.
>>>
>>>> +
>>>> +  rdma_cap_read_multi_sge
>>>> +  ---------------
>>>> +    RDMA read operation could support multiple scatter-gather entries,
>>>> +    use the helper to verify wthether the port support this feature
>>>> +    or not.
>>>
>>> Certain devices (iWARP in particular) have restrictions on the number of
>>> scatter gather elements that can be present in an RDMA READ work
>>> request.  This is true if the device does not have that restriction.
>>>
>>>> +  rdma_cap_af_ib
>>>> +  ---------------
>>>> +    RDMA address format could be ethernet or infiniband, use the helper
>>>> +    to verify whether the port support infiniband format or not.
>>>
>>> Many code paths for traditional InfiniBand and RoCE links are the same,
>>> but need minor differences to accommodate the different addresses on the
>>> two types of connections.  This helper is true when the address of the
>>> specific connection is of the InfiniBand native variety.
>>>
>>>> +
>>>> +  rdma_cap_eth_ah
>>>> +  ---------------
>>>> +    Infiniband address handler format is special in ethernet fabric, use
>>>> +    the helper to verify whether the port is using ethernet format or not.
>>>
>>> This helper is true when the address of the specific connection is of
>>> the Ethernet (RoCE) variety.
>>>
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/