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

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]

On Fri, 2015-05-15 at 10:31 +0200, Michael Wang wrote:
> 
> On 05/13/2015 06:42 PM, Hefty, Sean wrote:
> >>> +  rdma_cap_ib_cm
> >>> +  ---------------
> >>> +    Communication Manager (CM) will handle the connections between
> >>        ^Connection Manager (CM) service, used to ease the process of
> > 
> > In IB terms, this is communication manager.  It also handles transport level address resolution for UD QPs.
> 
> I could find both 'connection' and 'communication' in different docs,
> while 'connection' is more related to verbs, 'communication' is more
> close to specification.
> 
> IMHO 'connection' make more sense, after all, all the transport between
> adaptors could named as communication, while connection management is exactly
> what CM did in kernel.
> 
> Doug, what's your opinion?

See my previous email.  I can understand using the official name, but I
can also definitely see calling out in the more verbose section of text
that what this does is more close related to connection management (and
I would argue that transport level address resolution for a disconnected
queue pair is a form of connection management too, it's just connection
management on a packet by packet basis).

> > 
> >>> +  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.
> > 
> > This is used for connectionless communication.
> 
> Could you please give more details on this?

The test itself doesn't mean that.  It means we need a RoCE address
(it's true when transport is IB and link layer is Ethernet).  That we
*use* it during connectionless communication because we have to generate
our own address vector for the packet while during connected queue pair
use the address vector is created by the card using the queue pair
information is just the circumstance of its use.  And even though a
disconnected queue pair isn't solidly connected to a remote endpoint, it
is solidly bound to an adapter that requires either an IB or Ethernet
address family.  Maybe this to resolve your issue with the wording:

This helper is true when the address family of this queue pair is of the
Ethernet (RoCE) variety.


-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]