Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] ib_mad: prevent duplicateoutstanding MADtransactions 
> with same TID
> 
> Michael S. Tsirkin wrote:
> >Sorry for being dense, I'm not sure I understand.  Do you mean response 
> >when you
> >say receive? We never have both a request and a response outstanding to the
> >same remove GID with the same TID, do we?
> 
> I was meaning:
> 
> Request - response bit is 0
> Response - response bit is 1
> Send - outgoing MAD (may be request or response)
> Receive - incoming MAD (may be request or response)
> 
> In your example, you had host A sending a request to B (I'll call 
> transaction 1), and host B sending a request to A (transaction 2).  Host A 
> has one request being sent, and another being received.  An ACK from B to A 
> must match with transaction 1.  A NACK from B to A can match with either 
> transaction.
 
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().

I interpreset this as:

A NACK from B to A will have a response bit if its a NACK for MAD that A
is sending (NACK for Receive MAD) and it will have a response bit cleared
if its a NACK for MAD that B is sending (NACK for send MAD).

> To match NACKs using the response bit implies that requests can only flow 
> one direction, and responses the other.  This adds a policy that I don't 
> think should be part of the general MAD layer code.

But I think the spec implies that ACK/NACK response bit is calculated by looking
at whether you are Sender or Receiver, not by whether you are requester or
responder.

Am I wrong?

-- 
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

Reply via email to