[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKOOJTx9V328r+TC_Pd0LXQr6aMaiK2eB4Qu77Dw-kc00vg3Bg@mail.gmail.com>
Date: Mon, 25 Jan 2021 11:23:56 -0800
From: Edwin Peer <edwin.peer@...adcom.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Parav Pandit <parav@...dia.com>, Saeed Mahameed <saeed@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
netdev <netdev@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
Alexander Duyck <alexander.duyck@...il.com>,
Sridhar Samudrala <sridhar.samudrala@...el.com>,
David Ahern <dsahern@...nel.org>,
Kiran Patil <kiran.patil@...el.com>,
Jacob Keller <jacob.e.keller@...el.com>,
"Ertman, David M" <david.m.ertman@...el.com>,
Dan Williams <dan.j.williams@...el.com>,
Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [pull request][net-next V10 00/14] Add mlx5 subfunction support
On Mon, Jan 25, 2021 at 5:22 AM Jason Gunthorpe <jgg@...dia.com> wrote:
> SRIOV and SF's require a simple linear lookup to learn the "function"
> because the BAR space is required to be linear.
Isn't this still true even for NumVF's > 256? Wouldn't there still be
a contiguous VF BAR space? Don't the routing IDs simply carry on
incrementing by stride, with each being assigned the next slice of the
shared BAR space?
> Scaling a CAM to high sizes is physicaly infeasible, so all approaches
> to scaling PCI functions go this road of having a single large BAR
> space.
If the above is true, is there really a need to scale up CAM?
Regards,
Edwin Peer
Download attachment "smime.p7s" of type "application/pkcs7-signature" (4160 bytes)
Powered by blists - more mailing lists