On Sun, 10 Jun 2018 22:42:03 -0600 Jason Gunthorpe <jgg@xxxxxxxxxxxx> wrote: > Er, the spec has nothing to do with this. In Linux the TID is made > unique because the core code provides 32 bits that are unique and the > user provides another 32 bits that are unique. The driver cannot > change any of those bits without risking non-uniquenes, which is > exactly the bug mlx4 created when it stepped outside its bounds and > improperly overrode bits in the TID for its own internal use. Actually, the opposite is true here. When SRIOV is active, each VM generates its *own* TIDs -- with 32 bits of agent number and 32 bits of counter. There is a chance that two different VMs can generate the same TID! Encoding the slave (VM) number in the packet actually guarantees uniqueness here. There is nothing wrong with modifying the TID in a reversible way in order to: a. guarantee uniqueness b. identify the VM which should receive the response packet The problem was created when the agent-id numbers started to use the most-significant byte (thus making the MSB slave-id addition impossible). -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
