2012/1/25 David Miller <davem@davemloft.net>:> From: Jesse Gross <jesse@nicira.com>> Date: Tue, 24 Jan 2012 23:11:06 -0800>>> On Tue, Jan 24, 2012 at 8:02 PM, David Miller <davem@davemloft.net> wrote:>>> From: Joseph Glanville <joseph.glanville@orionvm.com.au>>>> Date: Wed, 25 Jan 2012 14:48:37 +1100>>>>>>> The reason why this patch is useful is that it stands to be the only>>>> true mulitpoint L2 VPN with a kernel space forwarding plane.>>>>>> So what you're telling me is that I added this huge openvswitch>>> thing essentially for nothing?>>>> I think it's actually the opposite - Open vSwitch can be used to>> implement this type of thing as well as for many other use cases.>> Then openvswitch is exactly where you should be prototyping and> implementing support for this sort of stuff.>> And only if you cannot obtain reasonable performance using openvswitch> should you be even entertaining the notion of a static implementation.>> That's the whole premise behind putting openvswitch into the tree, so> that guys like you can play around in userspace without having to make> any kernel changes at all.>> I am not applying these patches, the more things you say the more I am> convinced they are not appropriate.>The performance is one of the most critical thing why I have chosen tobuild kernel patch in the first place instead of some user-space app.If I used this approach, I would probably end up with patch forOpenVPN project instead in that time. I am not telling thatopenvswitch is not a good place for prototyping, but I believe thatthis patch is beyond that border as it successfully run in environmentwith more 98 linux-based APs, used for 4K+ users, with no issue formore than 2 years. The performance results from Joseph Glanville evenadds value to it. So I still don't get the point, why my patch andopenvswitch cannot coexists in the kernel together and let user/adminto choose to correct solution for him/her.