Thu, Sep 04, 2014 at 11:23:35AM CEST, simon.hor...@netronome.com wrote: >On Thu, Sep 04, 2014 at 11:09:26AM +0200, Jiri Pirko wrote: >> 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. > >Great. Will that also include some swdev API and datapath modifications?
sure. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
