RE: [Infiniband-access_layer] TID management in AL

[Hefty, S. <sea...@in...>]

TIDs must be unique from the same source.  If clients are given full
access to the TID, then they must coordinate between each other to
ensure that none of them put the same TID on the wire as another client.
The easiest solution is to have AL assign part of the TID, which ensures
that no two clients above AL use the same TID.

=20

- Sean

=20

=20

-----Original Message-----
From: inf...@li...
[mailto:inf...@li...] On Behalf
Of Tillier, Fabian
Sent: Wednesday, February 18, 2004 10:53 PM
To: Eitan Zahavi; inf...@li...
Subject: RE: [Infiniband-access_layer] TID management in AL

=20

Ok, let's take a step back on this and look at the general question
independently from implementation:

Goal:

-       Make the full 64-bit TID available to MAD service clients.=20

Requirements:

-       Preserve IBAL's ability to route solicited responses to the
proper client.=20
-       Responses to sends must report the client TID specified in
matching send request.=20

Cost:

-       On-the-wire TID would be fully independent of client's specified
TID.  That is, no part of the TID in a MAD specified in ib_send_mad
would make it to the wire - the full 64-bits would be overridden by
IBAL.

Is the cost worth the goal?  Are there any compliance issues in having
the on-wire TID decoupled from the client's requested TID?

Note that I'm not looking for implementation details, only input on the
general design tradeoffs.

Thanks,

- Fab

-----Original Message-----
From: Eitan Zahavi [mailto:ei...@me...]
Sent: Wednesday, February 18, 2004 10:34 PM
To: Tillier, Fabian; inf...@li...
Subject: RE: [Infiniband-access_layer] TID management in AL

The TID is used to map mads back to different clients forcing a
uniqueness on the receiver side.

I think that the only other option is to add an API to get a unique TID
from the driver.

But I think the current approach is better.

Eitan Zahavi

Design Technology Director

Mellanox Technologies LTD

Tel:+972-4-9097208
Fax:+972-4-9593245

P.O. Box 586 Yokneam 20692 ISRAEL

-----Original Message-----
From: Fab Tillier [mailto:fti...@in...]
Sent: Wednesday, February 18, 2004 9:51 PM
To: inf...@li...
Subject: [Infiniband-access_layer] TID management in AL

Is there a requirement that any part of the TID specified by a MAD
service client go on the wire?

Is it legal for a client to encode a value in the TID that has meaning
to the recipient of a MAD?

If not, would we want to change TID usage to allow a client to use the
full 64-bits of the TID in sends, and have that TID restored in any
matching responses?

Currently, the mad service stores the client TID in the send tracking
structure's work request (h_send->mad_wr.client_tid).  For the send
side, the mad service already properly restores the full 64-bits of the
client TID.  For responses, only the 32-bits reserved for the client are
used to match an incoming MAD response to a send.  If the mad service
had as a member a TID counter that it incremented for every send, the
on-wire TID would be the client ID for the mad service in the upper
32-bits, and this counter in the lower 32-bits - no part of the client's
TID would actually go on the wire.   Response processing would then
match to the send using this counter value, and then be able to restore
the full 64-bit client TID for the response MADs.

Thoughts?

- Fab