[openib-general] Re: [PATCH] ib_mad: prevent duplicateoutstanding MADtransactions with same TID
Michael S. Tsirkin
mst at mellanox.co.il
Tue Feb 28 10:20:38 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:
> >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
More information about the general
mailing list