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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 25 Jan 2021 12:22:13 -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 11:59 AM Jason Gunthorpe <jgg@...dia.com> wrote:

> Every writable data mandated by the PCI spec requires very expensive
> on-die SRAM to store it.

That's an implementation decision. Nothing mandates that the state has
to physically exist in the same structure, only that reads and writes
are appropriately responded to. Parts that are read only could be
generated on the fly and writes can be stored more efficiently.

> We've seen Intel drivers that show their SIOV ADIs don't even have a
> register file and the only PCI presence is just a write-only doorbell
> page in the BAR.

Right, but presumably it still needs to be at least a page. And,
nothing says your device's VF BAR protocol can't be equally simple.

> It is hard to argue a write-only register in a BAR page vs all the
> SRIOV trappings when it comes to HW cost.

Say it's double the cost? I don't know that it is, but does that
warrant the additional complexity of SFs? We should try to quantify.

Regards,
Edwin Peer

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4160 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ