Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > Subject: Re: [PATCH] ib_mad: prevent duplicateoutstanding MADtransactions > with same TID > > Michael S. Tsirkin wrote: > >But the spec says: > > > > . The method used for all packets sent from the Receiver to the > > Sender > > shall be SubnAdmGetTable() or SubnAdmGetTraceTable(), depending > > on which initiated the transfer. > > > > . The method used for all packets sent from the Sender to the > > Receiver > > shall be SubnAdmGetTableResp(). > > This is for SA class only. Vendor specific classes do not have this > requirement.
OK, fine, but SA is the most interesting case. So let us either 1. Drop ABORT for vendor specific if there is more than one transaction with the same TID/GID/class outstanding 2. Assume vendor specific behaves in the same way as SA class, and ask users to adhere to this rule Further if you are going to work on a spec extension, it could simply add the requirement on the resp bit for vendor specific classes. Right? > Also, I don't see that there's any restriction that two > systems can't both initiate SubnAdmGetTable requests to each other. (For > example, some sort of distributed SA.) Sure, but again, if you initiate a request and then abort it, you clear the response bit, if you are receiving a request and decide to abort it, you set the response bit. Therefore if you get an abort you can look at the resp bit: if it is set this is a transaction that you initiated, if it is clear this is a transaction that remote side initiated. I conclude that there's no ambiguity. Am I mistaken? -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
