[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180611091914.00007858@dev.mellanox.co.il>
Date: Mon, 11 Jun 2018 09:19:14 +0300
From: jackm <jackm@....mellanox.co.il>
To: Jason Gunthorpe <jgg@...lanox.com>
Cc: Leon Romanovsky <leon@...nel.org>,
Matthew Wilcox <willy@...radead.org>,
hans.westgaard.ry@...cle.com, Doug Ledford <dledford@...hat.com>,
Matthew Wilcox <mawilcox@...rosoft.com>,
linux-rdma@...r.kernel.org,
HÃ¥kon Bugge <haakon.bugge@...cle.com>,
Parav Pandit <parav@...lanox.com>,
Pravin Shedge <pravin.shedge4linux@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Sun, 10 Jun 2018 22:42:03 -0600
Jason Gunthorpe <jgg@...lanox.com> 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).
Powered by blists - more mailing lists