On Wed, Sep 21, 2011 at 10:43:48PM -0700, Jesse Gross wrote: > On Wed, Sep 21, 2011 at 10:28 PM, Ben Pfaff <b...@nicira.com> wrote: > > On Mon, Sep 19, 2011 at 03:00:05PM -0700, Jesse Gross wrote: > >> Currently we publish several multicast groups for upcalls and let > >> userspace sockets subscribe to them. ??The benefit of this is mostly > >> that userspace is the one doing the subscription - the actual > >> multicast capability is not currently used and probably wouldn't be > >> even if we moved to a multiprocess model. ??Despite the convenience, > >> multicast sockets have a number of disadvantages, primarily that > >> we only have a limited number of them so there could be collisions. > >> In addition, unicast sockets give additional flexibility to userspace > >> by allowing every object to potentially have a different socket > >> chosen by userspace for upcalls. ??Finally, any future optimizations > >> for upcalls to reduce copying will likely not be compatible with > >> multicast anyways so disallowing it potentially simplifies things. > >> > >> We also never unregistered the multicast groups registered for upcalls > >> and leaked them on module unload. ??As a side effect, this solves that > >> problem. > >> > >> Signed-off-by: Jesse Gross <je...@nicira.com> > > > > As a first thought: did you consider making the pid an argument to the > > "send to userspace" action, as opposed to a property of the flow? > > Yes, that's actually the direction that I want to go in the future > since it both saves memory for the majority of flows that don't send > packets to userspace and provides additional flexibility. > > I don't think that it works at the moment though: > * The current sFlow upcall doesn't fit in (obviously going away soon). > * When forming the userspace action, either the code outside of > dpif-linux needs to know about the pid argument or we need to do a > translation step from userspace to kernel flow formats. I'd still > like to do the latter for other reasons, at which point this would fit > in naturally, but we haven't agreed on it yet.
That makes sense. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
