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. 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? Thanks.
