On Thu, Feb 27, 2014 at 11:44:22AM -0800, Alex Wang wrote:
> This commit changes the API in 'dpif-provider.h' to allow multiple
> handler threads call dpif_recv() simultaneously.
> 
> Signed-off-by: Alex Wang <al...@nicira.com>

The comment on dpif_port_get_pid() says that the 'hash' parameter
should be a 5-tuple hash.  Does it have be calculated a specific way?

This appears to delete the comment on dpif_recv_set(), instead of
updating it.  In particular I don't know exactly what 'n_handlers'
means.

It isn't clear to me where the 'handler_id's come from.

I noticed that new comments talk about "multiple clients", meaning
multiple threads reading packets from a single "struct dpif *".  Old
comments also talked about multiple clients, but they meant different
"struct dpif *"s (often from different processes) referring to a
single datapath.  I'm appending an incremental that tries to clarify
that.  My incremental also makes the suggestions for handling multiple
threads more specific; I'm not sure that my more specific suggestions
are actually what you mean, so please clarify if I misunderstood.

diff --git a/lib/dpif.h b/lib/dpif.h
index 8079751..2d3a50f 100644
--- a/lib/dpif.h
+++ b/lib/dpif.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013 Nicira, Inc.
+ * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -205,10 +205,10 @@
  * connection consists of two flows with 1-ms latency to set up each one.
  *
  * To receive upcalls, a client has to enable them with dpif_recv_set().  A
- * datapath should generally support multiple clients at once (e.g. so that one
- * may run "ovs-dpctl show" or "ovs-dpctl dump-flows" while "ovs-vswitchd" is
- * also running) but need not support multiple clients enabling upcalls at
- * once.
+ * datapath should generally support being opened multiple times (e.g. so that
+ * one may run "ovs-dpctl show" or "ovs-dpctl dump-flows" while "ovs-vswitchd"
+ * is also running) but need not support more than one of these clients
+ * enabling upcalls at once.
  *
  *
  * Upcall Queuing and Ordering
@@ -261,7 +261,7 @@
  * PID in "action" upcalls is that dpif_port_get_pid() returns a constant value
  * and all upcalls are appended to a single queue.
  *
- * The ideal behavior is:
+ * The preferred behavior is:
  *
  *    - Each port has a PID that identifies the queue used for "miss" upcalls
  *      on that port.  (Thus, if each port has its own queue for "miss"
@@ -275,16 +275,13 @@
  *
  *    - Upcalls that specify the "special" Netlink PID are queued separately.
  *
+ * Multiple threads may want to read upcalls simultaneously from a single
+ * datapath.  To support multiple threads well, one extends the above preferred
+ * behavior:
  *
- * Multiple Clients
- * ----------------
- * A datapath may have more than one client and multiple clients may want
- * to read upcalls simultaneously.  In such situation, the additional
- * requirements on the datapath are:
- *
- *    - The datapath must provide a set of per-port Netlink PIDs to each
- *      client.  The distribution of "miss" upcalls must guarantee that the
- *      same flow should always go to the same socket's receive queue.
+ *    - Each port has multiple PIDs.  The datapath distributes "miss" upcalls
+ *      across the PIDs, ensuring that a given flow is mapped in a stable way
+ *      to a single PID.
  *
  *    - For "action" upcalls, the client can specify its own Netlink PID or
  *      other client's Netlink PID of the same port for offloading purpose
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to