[openib-general] Re: [PATCH] ib_mad: prevent duplicateoutstanding MADtransactions with same TID

Michael S. Tsirkin mst at mellanox.co.il
Tue Feb 28 11:02:51 PST 2006


Quoting r. Sean Hefty <mshefty at ichips.intel.com>:
> 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



More information about the general mailing list