[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54C3902E.6080705@mojatatu.com>
Date: Sat, 24 Jan 2015 07:29:34 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: John Fastabend <john.fastabend@...il.com>,
Thomas Graf <tgraf@...g.ch>
CC: Pablo Neira Ayuso <pablo@...filter.org>,
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
Sorry I have been running around like a lunatic chicken so havent
had time to join the fun discussion. I hope we can make progress at
the meeting.
I am going to skim and jump through the emails and comment.
On 01/22/15 11:58, John Fastabend wrote:
> On 01/22/2015 07:13 AM, Thomas Graf wrote:
>> On 01/22/15 at 10:00am, Jamal Hadi Salim wrote:
>
> Correct this is fully exposed to user space, but it is also self
> contained inside the API meaning I can learn when to use it and what it
> does by looking at the other operations tables the table graph and
> supported headers. The assumption I am making that is not in the API
> explicitly yet. Is that actions named "set_field_name" perform the
> set operation on that field. We can and plan to extend the API to make
> this assumption explicit in the API.
>
From what you describe, you are running into a danger of going too low
level such that the interface will end up weighing too much into
flexibility/perfomance and less into usability. If there is one lesson
i learnt from netfilter is usability counts for something. You dont
want another u32 api (otherwise Jiri wouldnt have to write that new
classifier - there is nothing he is doing that cant be done with
u32).
> In this case I can "learn" that I can match on group_id in some tables
> and then use the above action to set the group_id in others.
>
And this discoverability was part of my concern especially when there is
no "stickiness" to the kernel or Linux tooling for that matter by
going direct to hardware. It is a tactical issue more than anything
else. With the approach, you need a little bit of clue of course, you
really dont even care about compiling the kernel. Essentially the
barrier to entry for SDKs is immensely lowered.
SDK joy. I know you were intending to replace ethtool - but you are
replacing it with a turbo engine and we need to look at a much bigger
scope.
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