[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