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

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Thu, Jan 22, 2015 at 01:37:13PM +0000, Thomas Graf wrote:
> On 01/22/15 at 01:52pm, Pablo Neira Ayuso wrote:
> > Hi John,
> > 
> > On Tue, Jan 20, 2015 at 12:26:13PM -0800, John Fastabend wrote:
> > > I believe I addressed all the comments so far except for the integrate
> > > with 'tc'. I plan to work on the integration pieces next.
> > 
> > I think that postponing the integration with 'tc' means that we're
> > renouncing to provide some abstraction to represent the actions that
> > the device provides. After this patch we'll have a standard API that
> > exposes the vendor specific semantics, *so user configurations will
> > not be portable anymore*.
> > 
> > At least, we should come up with some abstraction / mapping as
> > interface, so the vendors can use them to represent their operations.
> > That interface will provide a trade-off: If the vendor offers an
> > operation that doesn't map to our abstraction, then sorry that
> > operation has to remain behind the curtain.
> 
> I thought this *is* the abstraction ;-) Can you elaborate on which
> parts you consider vendor specific?

+/* rocker specific action definitions */
+struct net_flow_action_arg rocker_set_group_id_args[] = {
+       {
+               .name = "group_id",
+               .type = NFL_ACTION_ARG_TYPE_U32,
+               .value_u32 = 0,
+       },

that is retrieved via ndo_flow_get_actions and fully exposed to
userspace.