From: Eric Dumazet <eric.dumazet@gmail.com>
To: Changli Gao <xiaosuo@gmail.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
"David S. Miller" <davem@davemloft.net>, jamal <hadi@cyberus.ca>,
Tom Herbert <therbert@google.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH v4] net: batch skb dequeueing from softnet input_pkt_queue
Date: Thu, 22 Apr 2010 09:21:17 +0200 [thread overview]
Message-ID: <1271920877.7895.4757.camel@edumazet-laptop> (raw)
In-Reply-To: <p2i412e6f7f1004212330y6f3e2a92oa295e528afde3cd4@mail.gmail.com>
Le jeudi 22 avril 2010 à 14:30 +0800, Changli Gao a écrit :
> On Thu, Apr 22, 2010 at 2:18 PM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
> > On Thu, 22 Apr 2010 13:51:53 +0800
> > Changli Gao <xiaosuo@gmail.com> wrote:
> >
> >> + struct sk_buff *input_pkt_queue_head;
> >> + struct sk_buff **input_pkt_queue_tailp;
> >> + unsigned int input_pkt_queue_len;
> >> + unsigned int process_queue_len;
> >
> > Why is opencoding a skb queue a step forward?
> > Just keep using sk_queue routines, just not the locked variants.
> >
>
> I want to keep the critical section of rps_lock() as small as possible
> to reduce the potential lock contention, when RPS is used.
>
Jamal perf reports show lock contention but also cache line ping pongs.
Yet, you keep a process_queue_len shared by producers and consumer.
Producers want to read it, while consumer decrement it (dirtying its
cache line) every packet, slowing down the things.
The idea of batching is to let the consumer process its local queue with
no impact to producers.
Please remove it completely, or make the consumer zero it only at the
end of batch processing.
A cache line miss cost is about 120 cycles. Multiply it by 1 million
packet per second...
next prev parent reply other threads:[~2010-04-22 7:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-22 5:51 [PATCH v4] net: batch skb dequeueing from softnet input_pkt_queue Changli Gao
2010-04-22 6:18 ` Stephen Hemminger
2010-04-22 6:30 ` Changli Gao
2010-04-22 7:21 ` Eric Dumazet [this message]
2010-04-22 8:03 ` Changli Gao
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=1271920877.7895.4757.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=hadi@cyberus.ca \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
--cc=therbert@google.com \
--cc=xiaosuo@gmail.com \
/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