Sorry for long delay here. I wanted to point out something about: "At a high level, the fraction of packets that make it to userspace should be very small. So it is not worth the optimization"
If we have the port NORMAl (and perhaps, FLOOD) set, then the queuing of packets to userspace happens very often. And at startup, the queue (both in kernel and userspace) gets full quickly. This port NORMAL also causes kernel flows to be created, set, deleted and re-created, etc. During the time a kernel flow is deleted and a new one is created, packets that used to have matching flow now go to userspace. So I believe the packet queuing performance issue stands (unless we find a different way of handling NORMAL and FLOOD of ports, at least). Sam ===================================== Date: Thu, 14 Aug 2014 15:28:28 +0000 From: Nithin Raju <nit...@vmware.com> To: "dev@openvswitch.org" <dev@openvswitch.org> Subject: Re: [ovs-dev] Agenda for IRC neeting for 8/13 Message-ID: <34ae845b-bf0f-4a2f-a542-092973e58...@vmware.com> Content-Type: text/plain; charset="iso-8859-2" hi, I just wanted to send out the meeting minutes for any future reference: Attendees: Alin Serdean, Samuel Ghinet, Ankur Sharma, Saurabh Shah, Ben Pfaff, Nithin Raju. 1. Netlink implementation discussion - design discussions, status. ------------------------------------------------------------------- - Synced up on where things are. VMware folks to send out kernel patch, and try to integrate with the patch that Alin sent out for porting dpif-linux.c. - No licensing issues around defining data structures to handle netlink commands. Licensing issues can arise if we start reusing data structure as is from the Linux datapath. - We might need a mapping structure to map from nl_attr() to a more 'convenient' and contained data structure that can be consumed by the handler functions. We'll look at Cloudbase's mapping structures as well as VMware's data structures defined in OvsPub.h. - Ankur will be posting a patch soon for the netlink parsing. Ben clarified that we should use the Apache2 licensed code from userspace. - Expectedly, there are things that need to be ironed out regarding the IOCP. Evidently, Alin needs to know this to make the userspace changes. We'll discuss this over the ML next week. - Another area of discussion was around the implementation of flow dump. It was explained that the kernel need not take a snapshot of the kernel flowtable to implement flowdump. This provides clarity, and we can make progress on where to maintain the index during flow dump. Further discussions on the ML. - #Action-item: VMware to send out the patch. - #Action-item: VMware to review the patch sent by Alin to port dpif-linux.c to Windows posted the same day earlier. 2. Discussion about the persistent ports patch that Cloudbase is tasked with. ----------------------------------------------------------------------------- - Sam pointed out that a review is already out. 3. Discussion about P0 issues. ------------------------------ - We duped one of the issues, and tagged the Netlink implementation (enhancement) one as P0. - We'll be looking at Sam's changes to one of the P0 issues. 4. Discussion of other issues. ------------------------------ - None. 5. Queue packets inside the kernel and only send information needed to the userspace, instead of sending the whole packet. -------------------------------------------------------------------------------------------------------------------------- - This is a topic that has been discussed earlier internally in VMware, perhaps publicly as well. - At a high level, the fraction of packets that make it to userspace should be very small. So it is not worth the optimization. - There may be some usecases specific to Windows and we'll discuss on the ML. - #Action-item: VMware to explain the current rationale on the ML or on the issue (ovs-issues/issues/14) 6.. Spooky hash. ---------------- - It was agreed that Cloudbase folks would get some performance numbers and if it is better than the existing hash, we'll take it up. 7. Coding styles. 8. Packet buffer management. 9. Fixed sized array -------------------- - Reviews to follow up on the ML. 10. Reference counting ---------------------- - This was seen as useful for flowtable if not for vport. That said, it would be a good idea to lay out the usecase in pseudo code and then take it up. Reviews will follow on the ML. thanks, Nithin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
