[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55560501.4050200@profitbricks.com>
Date: Fri, 15 May 2015 16:38:57 +0200
From: Michael Wang <yun.wang@...fitbricks.com>
To: Doug Ledford <dledford@...hat.com>
CC: Roland Dreier <roland@...nel.org>,
Sean Hefty <sean.hefty@...el.com>,
Hal Rosenstock <hal@....mellanox.co.il>,
linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, Or Gerlitz <ogerlitz@...lanox.com>,
Ira Weiny <ira.weiny@...el.com>,
Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Subject: Re: [PATCH RFC] Documentation/infiniband: Add docs for rdma-helpers
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists