[ovs-dev] Merging the Datapath (Take III)
horms at verge.net.au
Mon Feb 7 02:29:18 UTC 2011
On Mon, Jan 31, 2011 at 02:40:05PM -0800, Jesse Gross wrote:
> On Sun, Jan 30, 2011 at 4:35 PM, Simon Horman <horms at verge.net.au> wrote:
> > Hi Jesse, Hi All,
> > some time last year I agreed to help out with merging the datapath
> > into the upstream kernel. That offer is very much still open so I
> > would like to discuss what the open issues are. The list I have
> > from last timed that we discussed this is:
> Sorry for moving so slowly on this, though things are going in the
> right direction. The Netlink changes took much longer than
> anticipated plus it seems like something is always popping up.
> However, we are definitely still interested in merging upstream and
> appreciate all of your help.
Thanks, that is good news.
> > 1) Netlink kernel/user API
> > - Progress seems to have been made here
> > but I am unsure what the status is
> The kernel/userspace interface is by far the largest (and most
> important) piece of work. The biggest component, moving from ioctls
> to a Netlink based interface, was just merged on Friday. There are
> still some issues shaking out from that but it should provide a solid
> base to work from. Beyond the actual transport mechanism, there are
> still a few design warts that were carried over from the previous
> interface. Most of these are special case implementations for
> particular features that should be genericized and the special case
> dropped. Some examples of this are IPv4 fragment handling, sampling,
> spoofed ARP detection, etc. I'd like to remove these before being
> locked in.
Ok, it sounds like things are certainly moving in the right direction.
> > 2) Handle RPS by clearing rxhash as necessary
> > - I have finally started the ball rolling here with
> > a small RFC patch earlier this morning.
> Thanks, I'll take a look at this shortly.
A new version is on its way, thanks for your feedback.
> > 3) Update VLAN handling for recent changes that were included in 2.6.37.
> > - I'm still trying to get my mind around this.
> I can handle this.
Thanks, those patches look good to me.
Though I have not had time to test them.
> > 4) Hash table implementation. Jesse's description of this problem follows:
> This still remains to be done.
> Those are the primary areas though there are a few other miscellaneous
> cleanups to be done (i.e. Stephen Hemminger pointed out in the past
> that our make_writeable function is not very efficient). #1 is by far
> the biggest bucket of work.
Personally, I see 1) as a blocker and the reset as
things that could be ironed out post-merge.
More information about the dev