All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: "Paweł Staszewski" <pstaszewski@itcare.pl>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
	brouer@redhat.com, Alexander Duyck <alexander.duyck@gmail.com>
Subject: Re: Kernel 4.13.0-rc4-next-20170811 - IP Routing / Forwarding performance vs Core/RSS number / HT on
Date: Mon, 14 Aug 2017 18:19:57 +0200	[thread overview]
Message-ID: <20170814181957.5be27906@redhat.com> (raw)
In-Reply-To: <ce33b7b3-ae00-b6f0-e82a-6df3d5a5e995@itcare.pl>


On Sun, 13 Aug 2017 18:58:58 +0200 Paweł Staszewski <pstaszewski@itcare.pl> wrote:

> To show some difference below comparision vlan/no-vlan traffic
> 
> 10Mpps forwarded traffic vith no-vlan vs 6.9Mpps with vlan

I'm trying to reproduce in my testlab (with ixgbe).  I do see, a
performance reduction of about 10-19% when I forward out a VLAN
interface.  This is larger than I expected, but still lower than what
you reported 30-40% slowdown.

[...]

> >>> perf top:
> >>>
> >>>    PerfTop:   77835 irqs/sec  kernel:99.7%  
> >>> ---------------------------------------------
> >>>
> >>>       16.32%  [kernel]       [k] skb_dst_force
> >>>       16.30%  [kernel]       [k] dst_release
> >>>       15.11%  [kernel]       [k] rt_cache_valid
> >>>       12.62%  [kernel]       [k] ipv4_mtu  
> >> It seems a little strange that these 4 functions are on the top  

I don't see these in my test.

> >>  
> >>>        5.60%  [kernel]       [k] do_raw_spin_lock  
> >> Why is calling/taking this lock? (Use perf call-graph recording).  
> > can be hard to paste it here:)
> > attached file

The attached was very big. Please don't attach so big file on mailing
lists.  Next time plase share them via e.g. pastebin. The output was a
capture from your terminal, which made the output more difficult to
read.  Hint: You can/could use perf --stdio and place it in a file
instead.

The output (extracted below) didn't show who called 'do_raw_spin_lock',
BUT it showed another interesting thing.  The kernel code
__dev_queue_xmit() in might create route dst-cache problem for itself(?),
as it will first call skb_dst_force() and then skb_dst_drop() when the
packet is transmitted on a VLAN.

 static int __dev_queue_xmit(struct sk_buff *skb, void *accel_priv)
 {
 [...]
	/* If device/qdisc don't need skb->dst, release it right now while
	 * its hot in this cpu cache.
	 */
	if (dev->priv_flags & IFF_XMIT_DST_RELEASE)
		skb_dst_drop(skb);
	else
		skb_dst_force(skb);


- - 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

Extracted part of attached perf output:

 --5.37%--ip_rcv_finish
   |          
   |--4.02%--ip_forward
   |   |          
   |    --3.92%--ip_forward_finish
   |       |          
   |        --3.91%--ip_output
   |          |          
   |           --3.90%--ip_finish_output
   |              |          
   |               --3.88%--ip_finish_output2
   |                  |          
   |                   --2.77%--neigh_connected_output
   |                     |          
   |                      --2.74%--dev_queue_xmit
   |                         |          
   |                          --2.73%--__dev_queue_xmit
   |                             |          
   |                             |--1.66%--dev_hard_start_xmit
   |                             |   |          
   |                             |    --1.64%--vlan_dev_hard_start_xmit
   |                             |       |          
   |                             |        --1.63%--dev_queue_xmit
   |                             |           |          
   |                             |            --1.62%--__dev_queue_xmit
   |                             |               |          
   |                             |               |--0.99%--skb_dst_drop.isra.77
   |                             |               |   |          
   |                             |               |   --0.99%--dst_release
   |                             |               |          
   |                             |                --0.55%--sch_direct_xmit
   |                             |          
   |                              --0.99%--skb_dst_force
   |          
    --1.29%--ip_route_input_noref
        |          
         --1.29%--ip_route_input_rcu
             |          
              --1.05%--rt_cache_valid

  reply	other threads:[~2017-08-14 16:20 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11 17:51 Kernel 4.13.0-rc4-next-20170811 - IP Routing / Forwarding performance vs Core/RSS number / HT on Paweł Staszewski
2017-08-12 12:23 ` Jesper Dangaard Brouer
2017-08-12 17:27   ` Paweł Staszewski
2017-08-13 16:58     ` Paweł Staszewski
2017-08-14 16:19       ` Jesper Dangaard Brouer [this message]
2017-08-14 16:33         ` Eric Dumazet
2017-08-14 16:57         ` Paolo Abeni
2017-08-15  0:45           ` Paweł Staszewski
2017-08-15  1:07             ` Eric Dumazet
2017-08-15  1:17               ` Eric Dumazet
2017-08-15  9:11                 ` Paweł Staszewski
2017-08-15  9:19                   ` Paweł Staszewski
2017-08-15 10:05                   ` Jesper Dangaard Brouer
2017-09-21 21:26                   ` Paweł Staszewski
2017-09-21 21:34                     ` Eric Dumazet
2017-09-21 21:34                       ` Paweł Staszewski
2017-09-21 21:41                     ` Florian Fainelli
2017-09-21 21:43                       ` Paweł Staszewski
2017-09-21 21:54                       ` Eric Dumazet
2017-09-21 22:07                         ` Florian Fainelli
2017-09-22  0:37                           ` Eric Dumazet
2017-10-18 21:49                       ` Paweł Staszewski
2017-10-18 21:54                         ` Eric Dumazet
2017-10-18 22:45                           ` Paweł Staszewski
2017-09-09  9:03                 ` Paweł Staszewski
2017-09-11 16:57                   ` Paweł Staszewski
2017-09-11 22:11                     ` Paweł Staszewski
2017-08-15  9:35           ` Jesper Dangaard Brouer
2017-08-15  0:38         ` Paweł Staszewski
2017-08-15  9:23           ` Jesper Dangaard Brouer
2017-08-15  9:30             ` Paweł Staszewski
2017-08-15  9:57               ` Jesper Dangaard Brouer
2017-08-15 10:02                 ` Paweł Staszewski
2017-08-15 10:05                   ` Paweł Staszewski
2017-08-15 10:28                     ` Jesper Dangaard Brouer
2017-08-14  0:07     ` Alexander Duyck
2017-08-14 15:07       ` Paweł Staszewski

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=20170814181957.5be27906@redhat.com \
    --to=brouer@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pstaszewski@itcare.pl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.