Re: [PATCH net-next 0/2] ovs: refresh a flow via netlink

On Thu, Mar 17, 2016 at 9:24 AM, Samuel Gauthier
[off-list ref] wrote:

2016-03-17 0:23 GMT+01:00 Jesse Gross [off-list ref]:

quoted

On Wed, Mar 16, 2016 at 8:07 AM, Samuel Gauthier
[off-list ref] wrote:

quoted

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