[ovs-dev] Merging the Datapath (Take III)

Simon Horman 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 mailing list