linux-kernel - Re: [patch v4, kernel version 3.2.1] net/ipv4/ip

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOzFzEj-UCXwhw0NA=Y=qExG=RdVJB3RAdqU0HrsMo7V+4eGcQ@mail.gmail.com>
Date:	Fri, 27 Jan 2012 09:24:19 +1100
From:	Joseph Glanville <joseph.glanville@...onvm.com.au>
To:	David Miller <davem@...emloft.net>
Cc:	steweg@...t.sk, jesse@...ira.com, 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

David is correct, the forwarding speed of Open vSwitch is at parity
with the Linux Bridging module and its tunneling speed is actually
slightly faster than the in kernel GRE implementation. I have tested
this across a variety of configurations.

Joseph.

On 27 January 2012 05:30, David Miller <davem@...emloft.net> wrote:
> From: Štefan Gula <steweg@...t.sk>
> Date: Thu, 26 Jan 2012 11:57:30 +0100
>
>> 2012/1/26 David Miller <davem@...emloft.net>:
>>> From: Štefan Gula <steweg@...t.sk>
>>> Date: Wed, 25 Jan 2012 23:57:18 +0100
>>>
>>>> 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.
>>>> If I used this approach, I would probably end up with patch for
>>>> OpenVPN project instead in that time. I am not telling that
>>>> openvswitch is not a good place for prototyping, but I believe that
>>>> this patch is beyond that border as it successfully run in environment
>>>> with more 98 linux-based APs, used for 4K+ users, with no issue for
>>>> more than 2 years. The performance results from Joseph Glanville even
>>>> adds value to it. So I still don't get the point, why my patch and
>>>> openvswitch cannot coexists in the kernel together and let user/admin
>>>> to choose to correct solution for him/her.
>>>
>>> You don't even know if openvswitch could provide acceptable levels
>>> of performance, because you haven't even tried.
>>>
>>> I'm not applying your patch.
>> Performance of any user-space application is lower than performance of
>> something running purely inside the kernel-space only. So still don't
>> see any valid reason, why it simply cannot coexists as it doesn't
>> breaks any existing functionality at all?
>
> The only userspace component is setting up the rules, the actual
> packet processing occurs in the openvswitch kernel code.
>
> Are you really unable to understand this?



-- 
Founder | Director | VP Research
Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
99 52 | Mobile: 0428 754 846
--
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/