lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 26 Jan 2012 00:18:37 +0100 From: Dave Taht <dave.taht@...il.com> To: Štefan Gula <steweg@...t.sk> Cc: David Miller <davem@...emloft.net>, jesse@...ira.com, joseph.glanville@...onvm.com.au, eric.dumazet@...il.com, kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [patch v4, kernel version 3.2.1] net/ipv4/ip_gre: Ethernet multipoint GRE over IP 2012/1/25 Štefan Gula <steweg@...t.sk>: > 2012/1/25 David Miller <davem@...emloft.net>: >> From: Jesse Gross <jesse@...ira.com> >> Date: Tue, 24 Jan 2012 23:11:06 -0800 >> >>> On Tue, Jan 24, 2012 at 8:02 PM, David Miller <davem@...emloft.net> wrote: >>>> From: Joseph Glanville <joseph.glanville@...onvm.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 to > build kernel patch in the first place instead of some user-space app. I am very interested in testing this patch, for the kinds of environments I care about (embedded, cpe, etc) but I won't be able to get around to it for a week or so. I found the overall simplicity of this approach vs the complexity of the alternatives, appealing, and the performance numbers also. -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists