netdev - Re: [PATCH net-next 2/2] openvswitch: Use zerocopy if applicable when performing the upcall

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-next>] [day] [month] [year] [list]

Message-ID: <20130607122139.GA21856@casper.infradead.org>
Date:	Fri, 7 Jun 2013 13:21:39 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	Jesse Gross <jesse@...ira.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	netdev <netdev@...r.kernel.org>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>
Subject: Re: [PATCH net-next 2/2] openvswitch: Use zerocopy if applicable
 when performing the upcall

On 05/27/13 at 10:28am, Jesse Gross wrote:
> On Saturday, May 25, 2013, Eric Dumazet wrote:
> 
> > On Sat, 2013-05-25 at 08:02 +0100, Thomas Graf wrote:
> >
> > > I ran TCP_CRR to verify the SYN/ACK use case and I did not
> > > observe a difference. If you have any specific test in mind
> > > I will be glad to run that before posting the 2nd revision.
> >
> > I guess you should test with rx checksum disabled as well, Jesse seemed
> > to be concerned about that.
> 
> 
>  I was actually thinking about the transmit side - rx checksum verification
> doesn't matter much here since the result will get thrown away. However, if
> the packet is CHECKSUM_PARTIAL then the checksum will have to get filled in
> first and that's the code path that is a little different now.

Do we actually need to complete the checksum before doing the
upcall and if so, why? Couldn't the slow path do that if needed?
The only reason I can think of where it would matter is if a
controller injects the packet into another network stack such
as RouteFlow.

On the receive side, hitting an ovs bridge connected to two
interface with ~18G of randomized flows:

3.10.0-rc2+:
+   9.44%   ksoftirqd/0  [k] csum_partial_copy_generic
+   3.54%  ovs-vswitchd  [k] copy_user_enhanced_fast_string
+   3.08%       swapper  [k] intel_idle
+   2.47%   ksoftirqd/0  [k] memset
+   2.21%   ksoftirqd/0  [k] memcpy
+   1.64%   ksoftirqd/0  [k] __nla_reserve
+   1.26%  ovs-vswitchd  [k] netlink_recvmsg
+   1.07%   ksoftirqd/0  [k] __netif_receive_skb_core
+   1.02%   ksoftirqd/0  [k] __pskb_pull_tail
+   0.98%       swapper  [k] csum_partial_copy_generic
+   0.95%  ovs-vswitchd  [k] _raw_spin_lock
+   0.94%  ovs-vswitchd  [k] _raw_spin_lock_irqsave
+   0.83%  ovs-vswitchd  [k] memcpy
+   0.80%   ksoftirqd/0  [k] __alloc_skb
+   0.78%   ksoftirqd/0  [k] skb_copy_bits
+   0.71%       swapper  [k] menu_select
+   0.71%   ksoftirqd/2  [k] csum_partial_copy_generic                              

3.10.0-rc2+ + zerocopy
+   4.84%    ovs-vswitchd  [k] copy_user_enhanced_fast_string
+   4.74%         swapper  [k] intel_idle
+   3.14%         swapper  [k] memset
+   3.04%         swapper  [k] memcpy
+   2.10%         swapper  [k] __nla_reserve
+   1.44%         swapper  [k] skb_copy_bits
+   1.40%         swapper  [k] __netif_receive_skb_core
+   1.34%         swapper  [k] __pskb_pull_tail
+   1.23%    ovs-vswitchd  [k] _raw_spin_lock
+   1.16%    ovs-vswitchd  [k] fib_table_lookup
+   1.16%         swapper  [k] irq_entries_start
+   1.09%    ovs-vswitchd  [k] memcpy
+   1.05%         swapper  [k] __alloc_skb
+   1.03%         swapper  [k] lapic_next_deadline
+   1.02%         swapper  [k] build_skb
+   0.99%         swapper  [k] skb_zerocopy                  
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html