On Sat, Aug 23, 2014 at 10:09:13AM -0700, John Fastabend wrote: >On 08/23/2014 07:51 AM, Thomas Graf wrote: >>On 08/23/14 at 11:24am, Jiri Pirko wrote: >>>Sat, Aug 23, 2014 at 12:53:34AM CEST, sfel...@cumulusnetworks.com wrote: >>>> >>>>On Aug 22, 2014, at 12:39 PM, John Fastabend <john.fastab...@gmail.com> >>>>wrote:
[snip] >>>>>- Also there is no programmatic way to learn which flows are >>>>> in hardware and which in software. There is a pr_warn but >>>>> that doesn't help when interacting with the hardware remotely. >>>>> I need some mechanism to dump the set of hardware tables and >>>>> the set of software tables. >>>> >>>>Agreed, we need a way to annotate which flows are installed hardware. >>> >>>Yes, we discussed that already. We need to make OVS daemon hw-offload >>>aware indicating which flow it want/prefers to be offloaded. This is I >>>believe easily extentable feature and can be added whenever the right >>>time is. >> >>I think the swdev flow API is good as-is. The bitmask specyfing the >>offload preference with all the granularity (offload-or-fail, >>try-to-offload, never-offload) needed can be added later, either in >>OVS only or in swdev itself. >> >>What is unclear in this patch is how OVS user space can know which >>flows are offloaded and which aren't. A status field would help here >>which indicates either: flow inserted and offloaded, flow inserted but >>not offloaded. Given that, the API consumer can easily keep track of >>which flows are currently offloaded. >> > >Right. I think this is basically what Jiri and I discussed when he >originally posted the series. For my use cases this is one of the >more interesting pieces. If no one else is looking at it I can try >it on some of the already existing open source drivers that have some >very simple support for ingress flow tables read flow director. While I agree that it would be good to have such controls I'd like to take a small step back as I'm not entirely clear how flow deletion works in the current code. I am specifically refering to the Open vSwitch use-case. My assumption is that if a flow is offloaded then once it is set up in hardware packets won't hit the datapath any more. However, statistics need to be updated in the datapath for active flows otherwise they will be evicted by ovs-vswtichd. In short, I was expecting to see get and statistics callbacks. [snip] _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
