From: Johannes Berg <johannes@sipsolutions.net>
To: Emmanuel Grumbach <egrumbach@gmail.com>
Cc: "Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] mac80211: synchronize_net() before flushing the queues
Date: Fri, 23 Jan 2015 14:20:08 +0100 [thread overview]
Message-ID: <1422019208.2728.34.camel@sipsolutions.net> (raw)
In-Reply-To: <CANUX_P0wvnNKV+-TtGV62ujMxtDDbJ=uEhaxKQF2ePvBcvyOnA@mail.gmail.com> (sfid-20150123_123607_358282_F98B1290)
On Fri, 2015-01-23 at 13:36 +0200, Emmanuel Grumbach wrote:
> > It's not actually just "one packet for each vif/ac" - it's a whole tail
> > of whatever other RCU usages there are. Back when this was discussed,
> > the wizery people measured this to hundreds of ms in many not too
> > uncommon cases.
>
> That's the part I didn't know. I wasn't aware that this
> synchronize_net() was there and that someone removed it.
This particular one might not have been there - I don't remember. There
were some in this path and we removed quite a few. However, if you have
keys, wpa_s is currently clearing them, which calls it for every single
key. I once had worked on an optimisation here (telling wpa_s not to
clear keys because we handle that when stations are deleted anyway) but
so far that didn't really go anywhere.
> I just wonder how we handle the case where we still have packets in
> the Tx path and we bring everything down. I can check the code, but
> not right now.
Well - I didn't expect you to check anything now :-)
I was more noting this down for 'future work'. It's possible, perhaps,
that we cannot do anything else here, but then we should think about the
other optimisations again...
johannes
prev parent reply other threads:[~2015-01-23 13:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-22 21:30 [PATCH] mac80211: synchronize_net() before flushing the queues Emmanuel Grumbach
2015-01-23 9:56 ` Johannes Berg
2015-01-23 10:18 ` Grumbach, Emmanuel
2015-01-23 10:33 ` Johannes Berg
2015-01-23 11:36 ` Emmanuel Grumbach
2015-01-23 13:20 ` Johannes Berg [this message]
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=1422019208.2728.34.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=egrumbach@gmail.com \
--cc=emmanuel.grumbach@intel.com \
--cc=linux-wireless@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).