Thu, Sep 04, 2014 at 11:03:46AM CEST, simon.hor...@netronome.com wrote: >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.
Yes, that is exactly what happens. > >In short, I was expecting to see get and statistics callbacks. We plan to implement this in rocker device as one of next steps. > >[snip] _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
