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. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
