[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