I see a problem here. If a node receives an SMInfo MAD (which is SMI -- LID-Route or Direct-Route classes), it would look bizarre to indicate that an entire SMI class is not supported, when fact OpenSM is simply not answering a "get" on the SMInfo **attribute** . In this case, #3 is correct (and #1 is NOT correct -- the HCA's SMA would still support SMI mads!).
In other cases, where an entire class is not supported (e.g., dev_mgt or SNMP), we can still probably return #3, since the attributes tend not to overlap between classes (i.e., each class has a mostly unique set of attributes). Since it would be a nightmare to differentiate between returning #1 and #3 (if this is at all possible -- I believe that in real time it is impossible to tell if an entire class has just gone missing (or was never supported), or just the specific attribute, such as SM_INFO, for a given class), I suggest we return #3. -Jack -----Original Message----- From: Jason Gunthorpe [mailto:[email protected]] Sent: Wednesday, January 18, 2012 8:57 PM To: Hefty, Sean Cc: Roland Dreier; Swapna Thete; Or Gerlitz; [email protected]; Jack Morgenstein Subject: Re: [PATCH 2/2] IB/mad: Return unsupported for MADs as appropriate On Wed, Jan 18, 2012 at 05:20:13PM +0000, Hefty, Sean wrote: > > Surely we should be picking the response status based on the IB spec > > rather than on the error message that some arbitrary tool prints? > > agreed - these are the basic choices: > > Code for invalid field > 0 - no invalid fields > 1 - Bad version. Either the base version, or the class version, or the > combination of the two is not supported. > 2 - The method specified is not supported > 3 - The method/attribute combination is not supported > > none of which seem that great... IMO, unsupported class version seems > as good as any. Figure 169 specifies the validation flow. 1 is the correct reply for 'Management class is not supported on this port'. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
