netdev - Re: please revert. Was: [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:   Thu, 25 May 2017 21:40:59 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, linux-rdma@...r.kernel.org
Subject: Re: please revert. Was: [for-next 4/6] net/mlx5: FPGA, Add basic
 support for Innova

On Fri, May 26, 2017 at 12:13:27AM -0400, David Miller wrote:
> From: Alexei Starovoitov <alexei.starovoitov@...il.com>
> Date: Thu, 25 May 2017 20:58:32 -0700
> 
> > Dave, please revert this Innova fpga stuff.
> > I think you pushed it by accident, since it was mixed with
> > other valid changes.
> > The discussion didn't conclude.
> > Myself and Jes are clearly against such changes.
> > It definitely needs more discussion and wider consensus.
> 
> Why don't you finish your discussion, then I can revert or leave it in
> there?

Not really. What you're saying is 'shut up. mellanox can do
whatever they like as long as it's hidden behind pcie id'.

> If someone puts an FPGA inside of a device, and it's still behind the
> PCI ID of the ethernet card, how they expose that thing is largely at
> the discression of the driver author.

So you're saying it's ok to program fpga through nic whereas larger
kernel community is trying to come up with a solution to represent
fpga as a proper device for the kernel.
I suspect there will be popcorn threads during the next merge window.

> So feel free to discuss things with them, but in the end unless I am
> convinced otherwise (and I'm currently not), what they are doing now
> is fine by me.

If you didn't merge it already it would be fair course of action,
but it's clearly not the case.

> I will also state that it can't be that every time Mellanox tries to
> add something significant to their driver everyone screams "oh my,
> this thing is so hard to maintain as it is, you can't add this feature
> _too_."

Maintaining is only small part of it. The key argument against it
that all these things fpga, eswitch, etc are _hidden_ behind the nic.
It already causes headaches in production, because kernel cannot see
them.

> Sorry, it's an important driver, it's big, it has a lot of features,
> and all those problems people talk about simply come with the
> territory.

It's not a driver feature. It's not a nic.
It's a different physical device that mlx choose to program via nic.
There is also 'bluefield' nic on the horizon.
>From host point of view it looks like the same cx5/6 nic,
but it has arm cpus on board. Are you going to allow programming
it via nic as part of mlx5 driver as well?
It's no different than fpga hiding behind the nic...

> Use a less featurefull device, which uses a driver with slower
> development and less changes, if these things truly bother you.

like google did. food for thought.