> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:openib-general- > [EMAIL PROTECTED] 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 > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib- > general _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
