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? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
