Subject: Re: [net-next PATCH v3 00/12] Flow API

From: Pablo Neira Ayuso <[email-masked]>
Date: Thu, 22 Jan 2015 17:49:51 +0100

On Thu, Jan 22, 2015 at 03:37:27PM +0000, Thomas Graf wrote:
> On 01/22/15 at 10:28am, Jamal Hadi Salim wrote:
> > On 01/22/15 10:13, Thomas Graf wrote:
> > 
> > >I don't follow this. John's proposal allows to decide on a case by
> > >case basis what we want to export. Just like with ethtool or
> > >RTNETLINK. There is no direct access to hardware. A user can only
> > >configure what is being exposed by the kernel.
> > >
> > 
> > So if i am a vendor with my own driver, I can expose whatever i want.
> 
> No. We will reject any driver change attempting to do so on this
> list.

I think those vendors do not want to push those driver changes
mainstream. They will likely use these new ndo's to fully expose their
vendor-specific capabilities distributed in proprietary blobs.

I remember to have seen one ugly patch for netfilter that added
several hook functions (not netfilter hooks) at different positions of
the NAT code, the goal was to offload NAT through hardware. I was told
the code that was using those ad-hoc hooks was distributed in a binary
blob.

> This is the whole point of this: Coming up with a model that allows
> to describe capabilities and offer flow programming capabilities
> in a Vendor neutral way. A "push_vlan" or "pop_vlan" action will work
> with any driver that supports it.

Right, we need an abstraction for actions too, and the infrastructure
should not provide any means to circunvent and expose vendor specific
details.