[ovs-dev] Merging datapath into the upstream kernel tree
horms at verge.net.au
Thu Aug 5 02:45:52 UTC 2010
On Wed, Aug 04, 2010 at 06:51:26PM -0700, Justin Pettit wrote:
> > I am wondering what the thoughts on merging datapath into
> > the upstream kernel tree are. I would be more than willing
> > to volunteer for the task.
> That would be fantastic. We've been discussing how to move forward with
> this. Here's a quick list of items that we think need to be addressed
> before it would be considered:
Great. I'm pretty excited about this.
> - The kernel module is currently a character device that is
> controlled by ioctls. This should be changed to a module that just
> uses netlink. This is more inline with Linux network
> configuration, and it will be more flexible if new features are
> added, so a consistent userspace application can be used across
I was pondering that the code really should use netlink :-)
> - Don't steal the bridge hooks. This should be trivial with the
> new hooks that should appear in 2.6.36.
Could you give me a pointer to the new hooks?
> - Break out vports. OVS introduces the concept of a vport, which
> is an interface abstraction. It's fairly monolithic at the moment,
> so it will likely need to be more modular.
This I am the least familiar with.
> - Support network namespaces.
That sounds more like post-merge material to me.
> - Rip out bridge compatibility code. This is for backwards
> compatibility with some hypervisors, but shouldn't be needed on new
Could you explain in a little more detail why
the compatibility code won't be needed (or will be needed less)
moving forwards? Certainly I'm very much in favour of removing
compatibility code if it isn't needed. Not least because
its likely to help with getting the code accepted.
> - Add sysfs information. Currently we only support items that
> allows us to impersonate the bridge.
That sounds reasonable, I should be in a better position
to know what to put in there once I'm a bit more familiar
with the code.
> - Possibly call hooks for netfilter/iptables, if necessary.
That also sounds like post-merge work.
> We think reworking the kernel module is the greatest single amount of
> work, and it's already on Ben Pfaff's to-do list. We would love to hear
> your input on areas that we may have missed and suggestions you may have
> for smoothing out the process. If there are any parts you'd like to work
> on, that would be great, too. Let us know how you'd like to contribute.
I'm still getting to grips with the code, and I expect to have more
ideas as that progresses. Looking over the code the things that
struck me were fairly simple - removing compatibility with older kernels
and the like, as thats not appropriate for the upstream kernel tree.
Certainly I think that I can handle the netlink work. I may as
well jump in at the deep-end.
Unfortunately/fortunately I will be more or less off-line next week
for LinuxCon in Boston. So it will be difficult for me to make a concrete
start on anything before that is finished. If any Open vSwitch people
will be in Boston next week, it would be a good chance to meet.
More information about the dev