On Tue, Jun 12, 2018 at 07:59:42AM +0300, jackm wrote: > On Mon, 11 Jun 2018 10:19:18 -0600 > Jason Gunthorpe <jgg@xxxxxxxxxxxx> wrote: > > > On Mon, Jun 11, 2018 at 09:19:14AM +0300, jackm wrote: > > > 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. > > > > And it does it while re-using the LRH of the host, so all VMs and the > > host are now forced to share a TID space, yes I know. > > > > > 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. > > > > Virtualizing the TID in the driver would be fine, but it must > > virtualize all the TIDs (even those generated by the HOST). > > It DOES do so. The host slave id is 0. Slave numbers start with 1. > If the MS byte contains a zero after paravirtualization, the MAD > was sent by the host. > In fact, ALL mads are paravirtualized -- including those to/from the host. Just assuming the byte is 0 and replacing it with something else is *NOT* virtualization. Jason -- 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
