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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
