netdev - Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

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:   Tue, 6 Jun 2017 10:42:35 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:     Ilan Tayari <ilant@...lanox.com>,
        Saeed Mahameed <saeedm@....mellanox.co.il>,
        "David S. Miller" <davem@...emloft.net>,
        Doug Ledford <dledford@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "jsorensen@...com" <jsorensen@...com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        Alan Tull <atull@...nsource.altera.com>,
        "yi1.li@...ux.intel.com" <yi1.li@...ux.intel.com>,
        Boris Pismenny <borisp@...lanox.com>
Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

On Tue, Jun 06, 2017 at 10:17:09AM -0600, Jason Gunthorpe wrote:
> On Tue, Jun 06, 2017 at 06:52:15AM +0000, Ilan Tayari wrote:
> 
> > So neither the host stack nor the network are aware of them.
> > They exist momentarily only on the internal traces on the board and not
> > anywhere else.
> 
> Is that really true? If you are creating rocee QPs' then the RDMA
> stack sees this stuff and now we have buried a RDMA ULP inside an
> ethernet driver which seems really wonky..
> 
> > I don't mind explaining further, but I think you will just see it in the
> > patchset when we submit.
> 
> You described exactly what I thought.. I just disagree with you that
> an ethernet connected and controlled IP accelerator is 'part of the
> NIC', even if it happens to be colocated on the same circuit board.

+1

what Ilan described is a kernel bypass done by hw.
This is non starter in production. Same as eswitch this fpga is not
represented as a kernel object, there is no way to debug it.
NIC crafts roce packets back and forth?!
so it's like rdma, but without using kernel rdma stack?
When hw ipsec or tls will mysteriously drop or mangle the packets
how this can be debugged? Does fpga have attached ddr to
store/forward the packets? How memory issues will be reported?
No MCE errors ever? Buffer overflow? How many receive queues inside fpga?
How health check of fgpa itself will be done? Through roce packets?
I would buy the lack of kernel visibility if this fpga+nic combo
was a prototype, but it's being presented as a production device
with subsequent changes to core networking stack and that's where
I have a problem with its sw architecture.