From: Thomas Graf <tgraf@suug.ch>
To: Jesse Gross <jesse@nicira.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
netdev <netdev@vger.kernel.org>,
"dev@openvswitch.org" <dev@openvswitch.org>
Subject: Re: [PATCH net-next 2/2] openvswitch: Use zerocopy if applicable when performing the upcall
Date: Fri, 7 Jun 2013 13:21:39 +0100 [thread overview]
Message-ID: <20130607122139.GA21856@casper.infradead.org> (raw)
In-Reply-To: <CAEP_g=944Wq982rDSC0hrqUBu8Sf6MCtQN0NhgyU5FDr9UB3ww@mail.gmail.com>
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
next prev parent reply other threads:[~2013-06-07 12:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-24 14:52 [PATCH net-next 0/2] Open vSwitch zerocopy upcall Thomas Graf
2013-05-24 14:52 ` [PATCH net-next 1/2] net: Export skb_zerocopy() to zerocopy from one skb to another Thomas Graf
2013-05-24 15:31 ` Eric Dumazet
2013-05-24 16:01 ` Thomas Graf
2013-05-24 14:52 ` [PATCH net-next 2/2] openvswitch: Use zerocopy if applicable when performing the upcall Thomas Graf
2013-05-24 17:24 ` Jesse Gross
2013-05-24 18:58 ` Eric Dumazet
2013-05-24 21:23 ` Jesse Gross
2013-05-24 21:57 ` Eric Dumazet
2013-05-24 22:18 ` Jesse Gross
2013-05-24 22:34 ` Eric Dumazet
2013-05-25 0:08 ` Jesse Gross
2013-05-25 0:32 ` Eric Dumazet
2013-05-25 7:02 ` Thomas Graf
2013-05-25 14:39 ` Eric Dumazet
2013-05-27 1:28 ` Jesse Gross
2013-06-07 12:21 ` Thomas Graf [this message]
2013-06-10 20:34 ` Jesse Gross
2013-06-10 20:43 ` David Miller
2013-06-10 20:55 ` Jesse Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130607122139.GA21856@casper.infradead.org \
--to=tgraf@suug.ch \
--cc=dev@openvswitch.org \
--cc=eric.dumazet@gmail.com \
--cc=jesse@nicira.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).