Date:	Fri, 23 Jan 2015 16:56:53 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	Thomas Graf <tgraf@...g.ch>, Jamal Hadi Salim <jhs@...atatu.com>,
	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
Subject: Re: [net-next PATCH v3 00/12] Flow API

Fri, Jan 23, 2015 at 04:43:48PM CET, john.fastabend@...il.com wrote:
>On 01/23/2015 07:25 AM, Jiri Pirko wrote:
>>Fri, Jan 23, 2015 at 03:07:24PM CET, tgraf@...g.ch wrote:
>>>On 01/23/15 at 02:43pm, Jiri Pirko wrote:
>>>>Fri, Jan 23, 2015 at 01:28:38PM CET, tgraf@...g.ch wrote:
>>>>>If I understand this correctly then you propose to do the decision on
>>>>>whether to implement a flow in software or offload it to hardware in the
>>>>>xflows classifier and action. I had exactly the same architecture in mind
>>>>>initially when I first approached this and wanted to offload OVS
>>>>>datapath flows transparently to hardware.
>>>>
>>>>Think about xflows as an iface to multiple backends, some sw and some hw.
>>>>User will be able to specify which backed he wants to use for particular
>>>>"commands".
>>>>
>>>>So for example, ovs kernel datapath module will implement an xflows
>>>>backend and register it as "ovsdp". Rocker will implement another xflows
>>>>backend and register it as "rockerdp". Then, ovs userspace will use xflows
>>>>api to setup both backends independently, but using the same xflows api.
>>>>
>>>>It is still up to userspace to decide what should be put where (what
>>>>backend to use).
>>>
>>>OK, sounds good so far. Although we can't completely ditch the existing
>>>genl based OVS flow API for obvious backwards compatibility reasons ;-)
>>
>>Sure.
>
>Replied to the other thread before seeing this, but some comments.
>
>>
>>>
>>>How does John's API fit into this? How would you expose capabilities
>>>through xflows? How would it differ from what John proposes?
>>
>>This certainly need more thinking. The capabilities could be exposed
>>either by separate a genl api (like in this version) or directly via TC
>>netlink iface (RTM_GETTFILTERCAP, RTM_GETACTIONCAP). The insides of the
>>message can stay the same. I like the second way better.
>>
>
>For what its worth I started this route when I did the flow API before
>ditching it and going to its own netlink family.
>
>>flow manipulation would happen as standard TC filters/actions manipulation.
>>Here, the Netlink messages could be also very similar to what John has now.
>>
>
>In fact I think they are almost the same ;) I don't mind doing the
>embedding as long as there is some sort of plan for how to attach
>filters to hardware. This is where I got stuck. I think you need
>a new attach point in the hardware. See my other reply.

The special "offload" qdisc of some sort sound a good way to me.


>
>>
>>>
>>>Since this would be a regular tc classifier I assume it could be
>>>attached to any tc class and interface and then combined with other
>>>classifiers which OVS would not be aware of. How do you intend to
>>>resolve such conflicts?
>>>
>>>Example:
>>>eth0:
>>>   ingress qdisc:
>>>     cls prio 20 u32 match [...]
>>>     cls prio 10 xflows [...]
>>>
>>>If xflows offloads to hardware, the u32 classifier with higher
>>>priority is hidden unintentionally.
>>
>>
>>Right. We have to either introduce some limitations for xflows to
>>disallow this or let the user to take care of this. But it's similar
>>problem as if you use tc with John's API or ovs with John's API.
>>
>
>But with the current API its clear that the rules managed by the
>Flow API are in front of 'tc' and 'ovs' on ingress. Just the same
>as it is clear 'tc' ingress rules are walked before 'ovs' ingress
>rules. On egress it is similarly clear that 'ovs' does a forward
>rule to a netdev, then 'tc' fiters+qdisc is run, and finally the
>hardware flow api is hit.


Seems like this would be resolved by the separe "offload" qdisc.

>
>I also think it is clear that when a packet never enters the software
>dataplane _only_ the hardware dataplane rules are used namely the
>entries in the Flow API.
>
>The cases I've been experimenting with using Flow API it is clear
>on the priority and what rules are being used by looking at counters
>and "knowing" the above pipeline mode.
>
>Although as I type this I think a picture would help and some
>documentation.
>
>.John
>
>
>-- 
>John Fastabend         Intel Corporation
--
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