netdev - Re: [pull request][net-next V10 00/14] Add mlx5 subfunction support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210125132210.GJ4147@nvidia.com>
Date:   Mon, 25 Jan 2021 09:22:10 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Parav Pandit <parav@...dia.com>
CC:     Edwin Peer <edwin.peer@...adcom.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 10:57:14AM +0000, Parav Pandit wrote:
> Hi Edwin,
> 
> > From: Edwin Peer <edwin.peer@...adcom.com>
> > Sent: Monday, January 25, 2021 2:17 AM
> > 
> > On Fri, Jan 22, 2021 at 11:37 AM Saeed Mahameed <saeed@...nel.org>
> > wrote:
> > 
> > > For more detailed information about subfunctions please see detailed tag
> > > log below.
> > 
> > Apologies for the tardy question out of left field, but I've been
> > thinking about this some more. If I recall, the primary motivation for
> > this was a means to effectively address more VFs? But, why can't the
> > device simply expose more bus numbers?
> 
> Several weeks back, Jason already answered this VF scaling question
> from you at discussion [1].

To add a little more colour, the PCI spec design requires a CAM (ie
search) to figure out which function an incoming address is connected
to because there are no restrictions on how BAR's of each function
have to be layed out.

SRIOV and SF's require a simple linear lookup to learn the "function"
because the BAR space is required to be linear.

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.

Jason