> -----Original Message----- > From: netdev-owner@xxxxxxxxxxxxxxx [mailto:netdev-owner@xxxxxxxxxxxxxxx] > > > -----Original Message----- > > From: Jason Gunthorpe [mailto:jgunthorpe@xxxxxxxxxxxxxxxxxxxx] > > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova > > > > On Mon, May 29, 2017 at 03:58:33PM +0000, Ilan Tayari wrote: > > > > From: Jason Gunthorpe [mailto:jgunthorpe@xxxxxxxxxxxxxxxxxxxx] > > > > Subject: Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for > > Innova > > > > > > > > On Sun, May 28, 2017 at 07:22:27AM +0000, Ilan Tayari wrote: > > > > > > > > > This is neither PCI-bar mapped, nor mailbox command. > > > > > The FPGA is indeed a bump-on-the-wire. > > > > > (It has I2C to the CX4 chip, but that is for debug purposes, and > too > > > > slow > > > > > to perform real programming) > > > > > > > > Wait.. So if it truely has nothing to do with the existing mellanox > > > > driver, then nothing more than the fpga loader should be in the mlx5 > > > > directory? > > > > > > True, except in specific cases when the FPGA may mangle the packets in > > > a way that the netdevice configures, and the driver needs to adapt the > > > data path. > > > > > Such is the case of IPSec and TLS offloads. > > > Those are tied to the mlx5 Ethernet driver (isolated with a kconfig). > > > > But there is nothing stopping this sort of FPGA mangling logic being > > downstream of any NIC, Mellanox is just the first to do this. > > > > I think you'd be better to add something to the net stack to model > > this post-nic mangling hardware, than trying to hide it in a driver. > > Of course. > > For IPSec, this is already in the kernel. > See this patchset: > http://www.mail-archive.com/netdev@xxxxxxxxxxxxxxx/msg162876.html Sorry, I pointed at the RFC by mistake. This is the relevant pull request: https://patchwork.ozlabs.org/patch/752707/ > > For TLS, Dave Watson is working with our guys to add it. > > > > > Jason ��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
