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

[Jamal Hadi Salim <jhs@mojatatu.com>]

On 01/23/15 10:34, John Fastabend wrote:

> First 'tc' infrastructure doesn't have any classifier that would map
> well to this today so you are talking about a new classifier looks like
> Jiri is calling it xflows. This is fine.

I know you know this (and apologies for the little Australian Bike
Shed tangent):
You can do _any_ classifier you want. xflows just happens to make the
OF people happy. Someone else who wants to classify on pcre like
strings can go ahead and write another one.
i.e there is no monopoly on what a classifier should be.

> Now 'xflows' needs to implement the same get operations that exist in
> this flow API otherwise writing meaningful policies as Thomas points out
> is crude at best.

It is crude only if you assume the kernel is doing your policies
and fixing any conflicts. Let the kernel do mechanisms and have user
space do the brainy part. No need to give total autonomy to the kernel.


> So this tc classifier supports 'get headers',
> 'get actions', and 'get tables' and then there associated graphs. All
> good so far. This is just an embedding of the existing API in the 'tc'
> netlink family. I've never had any issues with this. Finally you build
> up the 'get_flow' and 'set_flow' operations I still so no issue with
> this and its just an embedding of the existing API into a 'tc
> classifier'. My flow tool becomes one of the classifier tools.
>

You have very few generic verbs really within tc and i dont see
much more needed.
GET/SET(mods for create/append/replace)/DEL with the object
being a noun. Add a handful for capabilities exercising verbs and
you should be on your way.
BTW: I did have capabilities in actions for years but Cong sent a
patch about a year or so ago to kill them because they were not being
exercised from user space tc - I protested but Dave overruled me.
There are still remnants - look at struct tcf_common field
tcfc_capab - the original intent was to have that look like netdev
features bitmask. In any case i never got to proper implementation
and have gained a lot of experience since those early days
and my thinking has changed.


> Now what should I attach my filter to? Typically we attach it to qdiscs
> today. But what does that mean for a switch device? I guess I need an
> _offloaded qdisc_? I don't want to run the same qdisc in my dataplane
> of the switch as I run on the ports going into/out of the sw dataplane.

I dont know if you need a qdisc necessarily that sits in hardware.
But you need to anchor your policy somewhere. The ingress qdisc is
really a dummy for this purpose. It is the beggining of the pipeline.
Most of the hardware i have looked at has some anchor point for the
hardware ACLs. Typically around a queue or a port. Sometime i find it
hard to use this model because of vendor SDKs and APIs they offer.

> Similarly I don't want to run the same set of filters. So at this point
> I have a set of qdiscs per port to represent the switch dataplane and
> a set of qdiscs attached to the software dataplane. If people think this
> is worth doing lets do it. It may get you a nice way to manage QOS while
> your @ it.
>

Lets discuss at the meeting. I am just skimming these emails (the
conference is chewing a lot of my time so i will mostly be absent).
Sorry if i am not responding to some things.

cheers,
jamal


>
>