[ovs-dev] [PATCH V3 1/5] dpif: Change dpif API to allow multiple handler threads read upcall.
Ben Pfaff
blp at nicira.com
Wed Mar 12 05:27:20 UTC 2014
On Fri, Mar 07, 2014 at 06:04:38PM -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 <alexw at nicira.com>
>
> ---
> V2 -> V3:
> - detach the channel refreshing from recv_set().
>
> Note:
> the recv_set() still calls the refresh_channels(), the first time receiving
> packet is enabled. This is in that, when opening the dpif, the
> open_dpif_backer() calls check_variable_length_userdata() and
> check_max_mpls_depth() before setting the handler/revalidator thread. Both
> of these function requires channels established in dpif.
>
> If we move the udpif_set_threads() before the two check functions, both the
> revalidator and the function iteslf will try deleting the flow installed.
> This will cause the warning of "failed to flow_del" and unittest failures.
>
> PATCH -> V2:
> - fold in Ben's clarification.
> - refine the comments.
> - invoke dpif_handlers_set() in udpif_set_threads(). this is a bug.
> the previous code will cause the handlers polling from closed
> fd.
I'm still trying to figure out whether I properly understand the new
API. Here's a suggested replacement for the first paragraph of the
comment on 'port_get_pid'. Is it correct?
/* Returns the Netlink PID value to supply in OVS_ACTION_ATTR_USERSPACE
* actions as the OVS_USERSPACE_ATTR_PID attribute's value, for use in
* flows whose packets arrived on port 'port_no'. In the case where the
* provider allocates multiple Netlink PIDs to a single port, it may use
* 'hash' to spread load among them. The caller need not use a particular
* hash function, because it is not generally necessary to avoid reordering
* between packets received via flow misses (which are spread among PIDs by
* the datapath internally) and those received via userspace actions (which
* are spread via the return value of this function). A 5-tuple hash is
* suitable.
More information about the dev
mailing list