Menu
▾
▴
RE: [Infiniband-access_layer] TID management in AL
|
From: Fab T. <fti...@in...> - 2004-02-19 19:38:18
|
Don't interpret the data. =20 I was thinking the policy would be for AL to not even look at the client = TID and generate a new TID for every distinct send. So the upper 32-bits of = the TID would still be the client index, and the lower 32-bits would be a per-mad-service counter that increments for every send request, allowing = the mad service to properly match a response to a send. One of the benefits = of this is that it eliminates the ability of mad clients to confuse their = mad services - a response will only ever match to a single send, even if the client provides the same TID for multiple sends. =20 As you mention, having a generated TID might cause some weird behavior = at the receiving end, hence my original question - is it valid for a MAD = sender to encode some meaningful value into the TID? I would expect not - the = TID should be opaque to the recipient, in which case having AL generate the = full TID independently of the client's TID would work well. =20 If a policy is needed I don't think it's worth making the change. If there's no policy needed, however, I think not exposing any limitation = on TID usage to clients is beneficial. =20 - Fab =20 -----Original Message----- From: Hefty, Sean [mailto:sea...@in...]=20 Sent: Thursday, February 19, 2004 11:07 AM To: Tillier, Fabian; inf...@li... Subject: RE: [Infiniband-access_layer] TID management in AL =20 We tried to do something like this, but AL doesn't try to interpret the data. So, it's not clear what policy AL would use when assigning TIDs. Does it always generate a new TID, or does it try to re-use TIDs? The result may not be the same at the receiver's side. And trying to guess based on the TID given by the client causes all sorts of head-aches = trying to cache information. =20 - Sean =20 =20 -----Original Message----- From: Fab Tillier [mailto:fti...@in...]=20 Sent: Thursday, February 19, 2004 10:53 AM To: Hefty, Sean; inf...@li... Subject: RE: [Infiniband-access_layer] TID management in AL =20 The TIDs on the wire would still be unique, with IBAL using the managing = the full 64-bits rather than only 32-bits. A client would be none the = wiser, though. I'm not suggesting AL shouldn't assign the TID, just expanding = how much of the TID AL assigns, but preserving the illusion at the client interface that the user has access to the full 64-bit TID. AL can = easily keep the association between its generated TID and the client's = requested TID for response processing. =20 - Fab =20 -----Original Message----- From: Hefty, Sean [mailto:sea...@in...]=20 Sent: Thursday, February 19, 2004 10:51 AM To: Tillier, Fabian; Eitan Zahavi; inf...@li... Subject: RE: [Infiniband-access_layer] TID management in AL =20 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 |