[openib-general][PATCH][RFC]: CMA IB implementation

[Yaron Haviv]

> -----Original Message-----
> From: openib-general-bounces at openib.org [mailto:openib-general-
> bounces at openib.org] On Behalf Of Sean Hefty
> Sent: Thursday, September 22, 2005 12:28 PM
> To: Guy German
> Cc: Openib
> Subject: Re: [openib-general][PATCH][RFC]: CMA IB implementation
> 
> Guy German wrote:
> > I don't think this layer should replace ib_at. If you think there
are
> > things to be fixed in the ib_at, I suggest we fix them. I do believe
> > that the original purpose of this generic cm was to serve ulps that
> > don't want to be transport oriented (e.g. iSER).
> 
> Based on discussions from last month, the general agreement was to use
CM
> private data in place of ATS.  Once that's done, I don't see a need
for
> ib_at.
> (Also, put simply, I don't believe that ATS can work.)  I think that a
> combination of what Roland, including his original API design, and
Yaron
> proposed is the right direction to go.
> 

Sean, my response is somewhat behind

Any way ib_at doesn't depend or directly connect to ATS
ATS was just one way to translate IP to GID

IB_AT provides a way to eventually translate src/dst IP + QoS attributes
to a set of layer 2 attributes and QP parameters in one place for few
ULPs 
And with potential enhancements to implement central address cache and
central QoS & Partitioning configuration mechanism. Basically it's the
IB equivalent of TCP/IPs IP & Eth resolution and routing layers. 

Having said that it doesn't really matter if its part of the CM or
external if we keep the functionality and implementation

To address partitioning IB_AT suggest using the P_Key value derived from
the IPoIB interface, also allowing a consumer/ULP to override those
values with its own. This forming the exact behavior as you would expect
from an Ethernet or iWarp mapping the RDMA sessions to the VLAN used by
that Interface.

To address QoS IB_AT model suggest taking by default the SL value from
the IPoIB interface of that subnet which took it from the SA MCRecord
(can override that with ULP). 
This allows a user to create two subnets over the fabric each mapped to
a different SL/VL with its BW/Priority reservation, and on the ULP side
he just needs to config ULP with different BW requirements to work over
a different subnet (which is what people already do today in many cases
since they use separate fabrics for e.g. one for NFS and one for MPI)

The API was also designed to let users override the default values
derived from IPoIB, so a sophisticated user/ulp can always get the best
granularity.

Yaron 

> - Sean
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-
> general