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  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:   Fri, 18 Dec 2020 05:20:53 +0000
From:   Parav Pandit <parav@...dia.com>
To:     Alexander Duyck <alexander.duyck@...il.com>,
        David Ahern <dsahern@...il.com>
CC:     Jason Gunthorpe <jgg@...dia.com>,
        Saeed Mahameed <saeed@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Leon Romanovsky <leonro@...dia.com>,
        Netdev <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        David Ahern <dsahern@...nel.org>,
        Jacob Keller <jacob.e.keller@...el.com>,
        "Sridhar Samudrala" <sridhar.samudrala@...el.com>,
        "Ertman, David M" <david.m.ertman@...el.com>,
        Dan Williams <dan.j.williams@...el.com>,
        "Kiran Patil" <kiran.patil@...el.com>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: RE: [net-next v4 00/15] Add mlx5 subfunction support


> From: Alexander Duyck <alexander.duyck@...il.com>
> Sent: Friday, December 18, 2020 8:41 AM
> 
> On Thu, Dec 17, 2020 at 5:30 PM David Ahern <dsahern@...il.com> wrote:
> >
> > On 12/16/20 3:53 PM, Alexander Duyck wrote:
> The problem is PCIe DMA wasn't designed to function as a network switch
> fabric and when we start talking about a 400Gb NIC trying to handle over 256
> subfunctions it will quickly reduce the receive/transmit throughput to gigabit
> or less speeds when encountering hardware multicast/broadcast replication.
> With 256 subfunctions a simple 60B ARP could consume more than 19KB of
> PCIe bandwidth due to the packet having to be duplicated so many times. In
> my mind it should be simpler to simply clone a single skb 256 times, forward
> that to the switchdev ports, and have them perform a bypass (if available) to
> deliver it to the subfunctions. That's why I was thinking it might be a good
> time to look at addressing it.
Linux tc framework is rich to address this and already used by openvswich for years now.
Today arp broadcasts are not offloaded. They go through software patch and replicated in the L2 domain.
It is a solved problem for many years now.

Powered by blists - more mailing lists