On Mon, Jan 31, 2011 at 02:40:05PM -0800, Jesse Gross wrote: > On Sun, Jan 30, 2011 at 4:35 PM, Simon Horman <[email protected]> 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. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev_openvswitch.org
