But that require changes to CM APIs vs a module on top of it to parse and populate private data field.
Arkady Kanevsky email: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] > Sent: Thursday, October 20, 2005 5:23 PM > To: 'Fab Tillier'; 'Sean Hefty' > Cc: [EMAIL PROTECTED]; [email protected] > 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 > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
