Thanks, Ben. That you've even considered this approach makes me feel better about implementing it in my baseline for now.
I'll ponder a longer-term solution, too... From an Openflow perspective, the pinch point seems to be that the netdev name is treated as equivalent to the Openflow port name. Since I only really care that the Openflow port names be repeatable across ofprotos, I considered having the datapath assign the Openflow name when it assigns the port number. That would let the netdev use a longer/uglier name, independent of the Openflow namespace. That change has bigger ripples, though, and I really didn't want to disturb the ofproto provider API. Casey On Thu Mar 08 11:20:40 GMT-800 2012, Ben Pfaff <b...@nicira.com> wrote: > On Thu, Mar 08, 2012 at 11:12:58AM -0800, Casey Barker wrote: > > I'm experimenting with running multiple ofproto instances from within a > > single process, where Open vSwitch is linked as a library, and the > > datapaths operate outside the kernel. These ofproto instances are > > completely independent of each other, each representing a separate > logical > > switching entity. (The reasons for putting them in the same process > are... > > complex.) > > > > Since they're independent, there's now a desire to use some common port > > names on every switching entity -- including those ofprotos that happen > to > > be managed by the same process. That's fine for the ofprotos, but > netdev.c > > tracks all created devices in a static 'netdev_dev_shash,' keyed only by > > netdev_dev.name<https://www.google.com/url?sa=D&q=http://netdev_dev.name>. > That means all netdevs across all ofprotos in a process > > share a global namespace (as is customary for sane use of netdevs). > > > > My proposed departure from sanity is to assign the ports an > > ofproto-specific netdev provider 'type' to differentiate the devs from > each > > other, similar to how type/name works for datapaths. Does anyone see any > > issues with keying the netdev_dev_shash by the concatenation of > netdev_dev > > type + name? It causes some minor ripples in the netdev API, but nothing > > insurmountable. > > > > I imagine this isn't a desirable change for the mainline code, so I > intend > > to keep this hack to myself. I'm more looking for any issues that I'm not > > seeing, or that could crop up in future iterations. (However, I did > notice > > that netdev_open() doesn't compare the 'type' before re-opening an > existing > > dev. Might be worth adding a sanity check as is done for args.) > > Around here, we've been talking about support for Linux kernel network > namespaces, where a single ovs-vswitchd would be able to manage > devices in multiple namespaces. This has the same issue, in that each > network namespace has, um, a separate namespace, so that you can have > "eth0" in multiple network namespaces. So I think that a clean > solution to the problem would help in both cases. > > I've thought of a few different solutions (but I haven't implemented > anything yet). One idea is the same as your solution. Another is to > do the qualification in the "name" part, not the type. For example, > eth0 in the xyzzy namespace would be something like "xyzzy:eth0". I > haven't worked the details in either case. > > If you work out something clean, then posting it here as a proposal > might be helpful for mainline after all. > > The netdev code always seems to have a bigger ripple effect than I > expect. I think that the API must still be badly designed, even after > the number of rewrites we've done after the years. I hope we can > figure out the Right Way(tm) someday. > > Thanks, > > Ben. >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
