[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