On Thu, Mar 17, 2016 at 9:24 AM, Samuel Gauthier <samuel.gauth...@6wind.com> wrote: > 2016-03-17 0:23 GMT+01:00 Jesse Gross <je...@kernel.org>: >> On Wed, Mar 16, 2016 at 8:07 AM, Samuel Gauthier >> <samuel.gauth...@6wind.com> wrote: >>> This patchset adds a netlink api to refresh an existing flow in >>> openvswitch. >>> >>> When a packet is sent in the openvswitch kernel datapath and no >>> flow is found, the packet is sent to the ovs-vswitchd daemon, >>> which will process the packet, and ask the kernel to create a new >>> flow. The next packets for this flow will be processed by the >>> kernel datapath. If a flow is not used for a (configurable) >>> period of time, ovs-vswitchd removes the flow from the kernel. >>> >>> As a result, it can be tricky to test the kernel datapath against >>> packets, as the first packets of each flow will have to go >>> through the ovs-vswitchd daemon. For instance, to do a zeroloss >>> performance test, you establish the flows, and then you have to >>> perform your zeroloss test before the flow is removed by >>> ovs-vswitchd. >>> >>> It is possible to configure a flow timeout in ovs-vswitchd (using >>> other_config:max-idle option), but it changes the behavior for >>> all the flows, which is not always what you want. >> >> It seems to me that it would be preferable to implement the necessary >> behavior in userspace to handle this directly. The logic that is >> removing the flow is in userspace, so rather than asking the kernel to >> lie about the current state of things, we can just modify the logic to >> handle this case. > > It seemed like a problem limited to the kernel datapath (i.e.: not to > the other ovs datapaths), so it made sense to me to fix it by a > netlink API.
I don't think that is true - the flow eviction logic is in userspace, so it should be common to all datapaths. What the kernel is providing is really very simple, just the last used time. > The idea was to do something similar to the OVS_FLOW_ATTR_CLEAR > attribute (which sets the flow statistics and used field to 0). > > This said, I could have a look to a pure userland solution, but I am > not sure how to do it. Could you elaborate what you have in mind? Well, truthfully, I would just use the existing max-idle option that you mentioned. I'm not entirely sure what the issue is with it applying to all flows, however, presumably it could be modified to only apply to a subset if necessary. max-idle is implemented purely in userspace, so I would start by looking at that and see how to tailor it.
