All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: "Jesper Dangaard Brouer" <brouer@redhat.com>,
	"Paweł Staszewski" <pstaszewski@itcare.pl>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
	Alexander Duyck <alexander.duyck@gmail.com>,
	Eric Dumazet <eric.dumazet@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:57:50 +0200	[thread overview]
Message-ID: <1502729870.8411.63.camel@redhat.com> (raw)
In-Reply-To: <20170814181957.5be27906@redhat.com>

On Mon, 2017-08-14 at 18:19 +0200, Jesper Dangaard Brouer wrote:
> 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);

I think that the high impact of the above code in this specific test is
mostly due to the following:

- ingress packets with different RSS rx hash lands on different CPUs
- but they use the same dst entry, since the destination IPs belong to
the same subnet
- the dst refcnt cacheline is contented between all the CPUs

Perhaps we can inprove the situation setting the IFF_XMIT_DST_RELEASE
flag for vlan if the underlaying device does not have (relevant)
classifier attached? (and clearing it as needed)

Paolo

  parent reply	other threads:[~2017-08-14 16:57 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
2017-08-14 16:33         ` Eric Dumazet
2017-08-14 16:57         ` Paolo Abeni [this message]
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=1502729870.8411.63.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=brouer@redhat.com \
    --cc=eric.dumazet@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.