* Question on ieee80211_tx_status
@ 2013-04-23 19:12 Ben Greear
2013-04-24 11:12 ` Johannes Berg
0 siblings, 1 reply; 3+ messages in thread
From: Ben Greear @ 2013-04-23 19:12 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
It appears that ieee80211_tx_status also scales poorly
when using large numbers of virtual stations connected
to a single AP, due to for_each_sta_info(local, hdr->addr1, sta, tmp)...
I'm going to try using the vif-hashing to make this faster,
but first a question:
Since it matches on MAC addresses, should it
just return at the bottom of the loop since it has
found a match, and MACs are supposed to be unique?
for_each_sta_info(local, hdr->addr1, sta, tmp) {
/* skip wrong virtual interface */
if (!ether_addr_equal(hdr->addr2, sta->sdata->vif.addr))
continue;
...
If so, that would be a good improvement since the hash can easily
be turned into a linear search even in AP mode (without all of
my virtual-station scenarios)...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Question on ieee80211_tx_status 2013-04-23 19:12 Question on ieee80211_tx_status Ben Greear @ 2013-04-24 11:12 ` Johannes Berg 2013-04-24 16:00 ` Ben Greear 0 siblings, 1 reply; 3+ messages in thread From: Johannes Berg @ 2013-04-24 11:12 UTC (permalink / raw) To: Ben Greear; +Cc: linux-wireless@vger.kernel.org On Tue, 2013-04-23 at 12:12 -0700, Ben Greear wrote: > It appears that ieee80211_tx_status also scales poorly > when using large numbers of virtual stations connected > to a single AP, due to for_each_sta_info(local, hdr->addr1, sta, tmp)... > > I'm going to try using the vif-hashing to make this faster, > but first a question: > > Since it matches on MAC addresses, should it > just return at the bottom of the loop since it has > found a match, and MACs are supposed to be unique? > > for_each_sta_info(local, hdr->addr1, sta, tmp) { > /* skip wrong virtual interface */ > if (!ether_addr_equal(hdr->addr2, sta->sdata->vif.addr)) > continue; > ... I think that'd be mostly safe, since we don't allow the same station to be added to multiple VLANs. However, I'm not entirely sure if it really is safe in the case of WDS interfaces. > If so, that would be a good improvement since the hash can easily > be turned into a linear search even in AP mode (without all of > my virtual-station scenarios)... I don't really see how the hash could be linear? When the low byte of MAC addresses is the same, but otherwise? johannes ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Question on ieee80211_tx_status 2013-04-24 11:12 ` Johannes Berg @ 2013-04-24 16:00 ` Ben Greear 0 siblings, 0 replies; 3+ messages in thread From: Ben Greear @ 2013-04-24 16:00 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org On 04/24/2013 04:12 AM, Johannes Berg wrote: > On Tue, 2013-04-23 at 12:12 -0700, Ben Greear wrote: >> It appears that ieee80211_tx_status also scales poorly >> when using large numbers of virtual stations connected >> to a single AP, due to for_each_sta_info(local, hdr->addr1, sta, tmp)... >> >> I'm going to try using the vif-hashing to make this faster, >> but first a question: >> >> Since it matches on MAC addresses, should it >> just return at the bottom of the loop since it has >> found a match, and MACs are supposed to be unique? >> >> for_each_sta_info(local, hdr->addr1, sta, tmp) { >> /* skip wrong virtual interface */ >> if (!ether_addr_equal(hdr->addr2, sta->sdata->vif.addr)) >> continue; >> ... > > I think that'd be mostly safe, since we don't allow the same station to > be added to multiple VLANs. However, I'm not entirely sure if it really > is safe in the case of WDS interfaces. Would you ever need to send an ACK multiple times? If so, then my approach would be wrong, but if you never should, then my approach would be more right than the current code. It would seem to me that you should never ack a packet more than once, but I don't actually know enough about the protocol to know if that is a valid assumption. >> If so, that would be a good improvement since the hash can easily >> be turned into a linear search even in AP mode (without all of >> my virtual-station scenarios)... > > I don't really see how the hash could be linear? When the low byte of > MAC addresses is the same, but otherwise? Sure, just randomize octed 3 and 4 and leave octet 5 the same. Easily done in certain test tools :) The new RFC patch I posted uses a better hash, and fixes all of the linear walk issues that show up in 'perf top' with 300 stations on a relatively weak Atom system... Also, to deal with cases where sdata may have duplicate macs, I just added a for_each_sdata() macro that should quickly walk a hash list of sdata objects and get the same behaviour efficiently (assuming that you don't have large amounts of sdata with the same MAC, but that seems unlikely to happen). Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-04-24 16:00 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-04-23 19:12 Question on ieee80211_tx_status Ben Greear 2013-04-24 11:12 ` Johannes Berg 2013-04-24 16:00 ` Ben Greear
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).