> The purpose of this patch is to cause the ib_mad driver to discard > busy responses from the SA, effectively causing busy responses to > become time outs.
I don't have a strong opinion on this but it seems a bit odd. If we're just going to drop the response anyway, why did the SA send it in the first place? On the other hand, if the SA told us it's busy, it does seem we could do something more sensible than retrying immediately. Any opinions from anyone who worked on fabric scalability? > + printk(KERN_NOTICE PFX "Response returned with > MAD_STATUS_BUSY\n"); Do we want to spam kernel logs with this? Seems it could generate a lot of messages. > +#define IB_MGMT_MAD_STATUS_SUCCESS > 0x0000 > +#define IB_MGMT_MAD_STATUS_BUSY > 0x0001 > +#define IB_MGMT_MAD_STATUS_REDIRECT_REQD 0x0002 > +#define IB_MGMT_MAD_STATUS_BAD_VERERSION 0x0004 > +#define IB_MGMT_MAD_STATUS_UNSUPPORTED_METHOD 0x0008 > +#define IB_MGMT_MAD_STATUS_UNSUPPORTED_METHOD_ATTRIB 0x000c > +#define IB_MGMT_MAD_STATUS_INVALID_ATTRIB_VALUE 0x001c The indentation of values seems pretty crazy here. Also I'm not sure what most of these defines are for? They seem unused in this patch. -- Roland Dreier <rola...@cisco.com> || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
