[ovs-dev] [PATCH V2] dpif: Change dpif API to allow multiple handler threads read upcall.

Alex Wang alexw at nicira.com
Thu Mar 6 17:40:20 UTC 2014


Thanks Han,~

Your suggestion makes sense.  I'll add a "bool upcall_enable" in "struct
dpif_linux"
and detach the refresh_channels() from recv_set().

Alex Wang,


On Thu, Mar 6, 2014 at 5:38 AM, Han Zhou <zhouhan at gmail.com> wrote:

> Hi Alex,
>
> On Wed, 2014-03-05 at 16:34 -0800, Alex Wang wrote:
>
> > @@ -352,17 +358,45 @@ struct dpif_class {
> >      /* Enables or disables receiving packets with dpif_recv() for
> 'dpif'.
> >       * Turning packet receive off and then back on is allowed to change
> Netlink
> >       * PID assignments (see ->port_get_pid()).  The client is
> responsible for
> > -     * updating flows as necessary if it does this. */
> > -    int (*recv_set)(struct dpif *dpif, bool enable);
> > +     * updating flows as necessary if it does this.
> > +     *
> > +     * The 'n_handlers' specifies the number of upcall handlers there
> are.
> > +     * Since multiple upcall handlers can read upcalls simultaneously
> from
> > +     * 'dpif', each port can have multiple Netlink sockets, one per
> upcall
> > +     * handler.  And recv_set() is responsible for the following tasks:
> > +     *
> > +     *    When receiving is enabled:
> > +     *
> > +     *    - create 'n_handlers' Netlink sockets for each port.
> > +     *
> > +     *    - create 'n_handlers' poll loops, one for each upcall handler.
> > +     *
> > +     *    - registering the Netlink sockets for the same upcall handler
> to
> > +     *      the corresponding poll loop.
> > +     *
> > +     *    When receiving is disabled:
> > +     *
> > +     *    - the opposite of above.
> > +     *
> > +     * */
> > +    int (*recv_set)(struct dpif *dpif, bool enable, uint32_t
> n_handlers);
> > +
> > +    /* Refreshes the poll loops and Netlink sockets associated to each
> port,
> > +     * when the number of upcall handlers is changed to 'n_handlers' and
> > +     * receiving packets is enabled for 'dpif'. */
> > +    int (*handlers_set)(struct dpif *dpif, uint32_t n_handlers);
>
> Now since you already have a separate interface handlers_set() to update
> n_handlers, why still keep the n_handlers parameter in recv_set()? This
> makes the meaning of recv_set() unclear when it is called with "enabled"
> state equal to current recv state. See the implementation of
> dpif_linux_recv_set__() in dpif-linux.c in patch 4/5.
>
> In my opinion it would be more clear if:
> - handlers_set() is responsible for setting/updating handler number and
> refreshing channels if recv is already enabled.
> - recv_set() only enable/disables receiving. When enabling, use
> current/default n_handlers to create channels.
>
> Best regards,
> Han
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140306/ace109f5/attachment-0005.html>


More information about the dev mailing list