[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54C11094.2000807@mojatatu.com>
Date: Thu, 22 Jan 2015 10:00:36 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Pablo Neira Ayuso <pablo@...filter.org>,
Thomas Graf <tgraf@...g.ch>
CC: John Fastabend <john.fastabend@...il.com>,
simon.horman@...ronome.com, sfeldma@...il.com,
netdev@...r.kernel.org, davem@...emloft.net, gerlitz.or@...il.com,
andy@...yhouse.net, ast@...mgrid.com, Jiri Pirko <jiri@...nulli.us>
Subject: Re: [net-next PATCH v3 00/12] Flow API
On 01/22/15 09:00, Pablo Neira Ayuso wrote:
>
> +/* 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.
>
My main concern is along similar lines (I did express it earlier and
I think Jiri chimed in as well).
The API exposes direct access to hardware. I am sure this was a result
of trying to replace the ethtool interface (which was primitive).
By providing vendors direct access to the hardware - they do not need
to use any traditional Linux tooling/APIs. I see this as a gaping hole
for vendor SDKs with their own definitions of their own hardware that
doesnt work with anyone else. i.e it seems to standardize proprietary
interfaces. Maybe thats what Pablo is alluding to.
Interfacing tc or nftables (or pick your favorite linux tool here) would
be preferable.
cheers,
jamal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists