[ovs-dev] [PATCH] ofproto-dpif: ovs-vswitchd.log showing unexpected flow

Andy Zhou azhou at nicira.com
Sat Aug 3 03:22:17 UTC 2013


This patch prevents the same subfacet from trying to install the kernel
flow more than once.

This is how a kernel flow can become unexpected to the user space. 
When a incoming packet did not match any flow in the kernel, it
would be sent up to the user space. A subfacet would be created and 
a corresponding kenrel flow installed. So far so good.

Just before the kernel flow was installed, another packet of the same
flow were to arrive at the kernel, it would also be queued up
for user space.  This time, user space would find the subfacet just
created (subfacet_create()) due of the first packet, and attempt
to install the same kernel flow again, but could not (kernel returns EEXIST).
User space would then mark the subfacet as not installed (SF_NOT_INSTALLED).

However, the kernel flow still exists. When it shows up in the user space
during stats update, user space would then declare the kernel flow
as unexpected in the log, and have it removed from the kernel.

In practice, we have seen these messages with netperf TCP_CRR tests and
UDP stream tests.

The fix in the patch seems safe assuming datapath is not actively
managing the flows. When flow is installed into the datapath,
it will be there until explicitly removed by the userspace. This is true
with the ovs current datapath implementation.

The following case is not addressed by this patch. In cases the kernel
flows are removed during runtime, for example, by using ovs-dpctl
commands or by restarting the datapath, the existing subfacet will not
try to install the kernel flow until it is expired and recreated.
In case the subfacet receives steady incoming packets, it may never
expire. In this case, the system will still function correctly but
less efficiently. If this is a concern, this patch may need more work.

Ethan was consulted heavily for analysing the solution. We both felt
this solution is the simplest and safest to solve the problem at hand.
We should post the patch and collect more feedbacks, especially since
this code has not been touched for a long time.

Signed-off-by: Andy Zhou <azhou at nicira.com>
---
 ofproto/ofproto-dpif.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 3bf4fe3..29a93e6 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -3460,7 +3460,7 @@ handle_flow_miss_with_facet(struct flow_miss *miss, struct facet *facet,
         subfacet_update_stats(subfacet, stats);
     }
 
-    if (miss->upcall_type == DPIF_UC_MISS || subfacet->path != want_path) {
+    if (subfacet->path != want_path) {
         struct flow_miss_op *op = &ops[(*n_ops)++];
         struct dpif_flow_put *put = &op->dpif_op.u.flow_put;
 
-- 
1.7.9.5




More information about the dev mailing list