From: John Fastabend <john.fastabend@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>,
John Fastabend <john.r.fastabend@intel.com>,
Eric Dumazet <eric.dumazet@gmail.com>,
Linux Kernel Network Developers <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC Patch net-next] net_sched: make classifying lockless on ingress
Date: Mon, 23 Dec 2013 22:08:49 -0800 [thread overview]
Message-ID: <52B924F1.9020201@gmail.com> (raw)
In-Reply-To: <CAM_iQpWAdsT=HX6AdK8oqPOFwzpBvPN__335Fuv3zEeS4HEWHQ@mail.gmail.com>
On 12/23/2013 04:56 PM, Cong Wang wrote:
> On Sat, Dec 21, 2013 at 3:09 PM, John Fastabend
> <john.fastabend@gmail.com> wrote:
>>
>> I solved this by making them per CPU and synchronizing when I hit
>> an operation that required sync'ing them. Going forward if folks
>> have the time to write SMP aware qdisc's that work with eventually
>> consistent counters that would be great.
>>
>
> Interesting, then you have to copy the same filters and actions
> to all per-cpu-ingress-qdisc, right? Also you need to handle
> CPU online/offline event.
>
> The number of CPU's grows fast today, so the total size
> of such ingress qdisc would be huge if I install lots
> of filters and action.
>
In this case I was specifically talking about statistics so the
bstats and qstats.
As long as the qdisc's do not require global state this works well
enough. However as Jamal keeps pointing out the problem is any qdisc
which requires global state requires locking (I paraphrase but I think
replicate the spirit correctly) and this doesn't work well with many
CPUs. So you either replicate the qdiscs one per queue like we do in
the mq and mqprio case effectively removing any global state or you
develop qdiscs that don't require global state or at least work with
eventually consistent data to avoid the constant syncing of data.
I think though a qdisc per nic queue is really not as bad as you think.
For example we do this on the tx side and it works OK. Note its per
RX queue and not per CPU.
.John
--
John Fastabend Intel Corporation
next prev parent reply other threads:[~2013-12-24 6:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-20 23:28 [RFC Patch net-next] net_sched: make classifying lockless on ingress Cong Wang
2013-12-20 23:49 ` Eric Dumazet
2013-12-20 23:57 ` Cong Wang
2013-12-21 0:08 ` Eric Dumazet
2013-12-21 0:24 ` Cong Wang
2013-12-21 2:32 ` John Fastabend
2013-12-21 22:11 ` Jamal Hadi Salim
2013-12-21 23:09 ` John Fastabend
2013-12-22 16:01 ` Jamal Hadi Salim
2013-12-24 0:56 ` Cong Wang
2013-12-24 6:08 ` John Fastabend [this message]
2013-12-26 12:02 ` Jamal Hadi Salim
2013-12-21 1:09 ` John Fastabend
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=52B924F1.9020201@gmail.com \
--to=john.fastabend@gmail.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jhs@mojatatu.com \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@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;
as well as URLs for NNTP newsgroup(s).