[swg] RE: [openib-general] Re: [swg] Re: private data...
Kanevsky, Arkady
Arkady.Kanevsky at netapp.com
Thu Oct 20 14:26:03 PDT 2005
But that require changes to CM APIs vs a module on top of it
to parse and populate private data field.
Arkady Kanevsky email: arkady at netapp.com
Network Appliance phone: 781-768-5395
375 Totten Pond Rd. Fax: 781-895-1195
Waltham, MA 02451-2010 central phone: 781-768-5300
> -----Original Message-----
> From: Sean Hefty [mailto:sean.hefty at intel.com]
> Sent: Thursday, October 20, 2005 5:23 PM
> To: 'Fab Tillier'; 'Sean Hefty'
> Cc: swg at infinibandta.org; openib-general at openib.org
> Subject: [swg] RE: [openib-general] Re: [swg] Re: private data...
>
>
> >The same can be said of the starting local QPN, responder resource,
> >initiator depth, starting PSN, MTU, and so forth. The CM
> doesn't care
> >about these - the application does, as these settings affect how it
> >configures its QP and what features of its protocol it can use.
>
> Not exactly the same. The "connection" cares about these,
> and must be included as part of the connection protocol.
>
> >There are a number of fields that are not used by the CM
> state machine
> >that are included in these MADs already. These fields are
> defined in
> >the CM protocol not because they impact MAD processing in
> the CM, but
> >because they represent minimum information needed to
> configure a QP and
> >client.
>
> Exactly. The IP address does not configure the QP.
>
> What you're advocating is that a service ID can support two
> private data formats depending on if a bit in the CM REQ is
> set or not. (If only a single format is supported, then the
> bit is not needed.) This is the wrong place to store this
> information. The format of the data beyond the addressing
> information is not conveyed by this bit, so additional
> information about the private data format is still needed.
>
> You can grab several reserved bits from the REQ and define it
> as a "private data version", but then apps that care about
> this could just as easily record the version in the private
> data itself.
>
> - Sean
>
More information about the general
mailing list