I was referring to the way TID is built only to say that TID made by the kernel should try and use some way to identify kernel A from kernel B.
If a TID is built out of PID and sequential number then using a TID with PID prefix of zero for Kernel generated transaction would cause more TID collisions.
-----Original Message-----
From: Sean Hefty [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 15, 2005 12:02 AM
To: Eitan Zahavi
Cc: 'Sean Hefty'; openib-general@openib.org
Subject: Re: [openib-general] matching an RMPP NACK to send or receive?
Eitan Zahavi wrote:
> EZ: TID should consist of a client selected part and process ID. For kernels
> I would select some part of the GUID too.
> We need to minimize cases of same TID use. But in such case - abort both of
> them.
I don't think that the receive handling code should make any assumptions
about the format of the TID. Aborting both transactions seems a little
harsh, but not sure if there's another way. For now, the code will only
abort a send, which should be the more common case. I will need to add
aborting receives later and assume that actual TID collisions would be
extremely rare.
The RMPP status does help indicate whether a send or receive is being
aborted, but not in all cases.
- Sean
_______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
