[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54A45309.6080606@broadcom.com>
Date: Wed, 31 Dec 2014 20:48:25 +0100
From: Arend van Spriel <arend@...adcom.com>
To: Andreas Hartmann <andihartmann@...enet.de>
CC: Jiri Kosina <jkosina@...e.cz>,
"Grumbach, Emmanuel" <emmanuel.grumbach@...el.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Borislav Petkov <bp@...en8.de>,
"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"egrumbach@...il.com" <egrumbach@...il.com>,
"peter@...leysoftware.com" <peter@...leysoftware.com>,
"ilw@...ux.intel.com" <ilw@...ux.intel.com>,
"Berg, Johannes" <johannes.berg@...el.com>,
Larry Finger <Larry.Finger@...inger.net>
Subject: Re: [PATCH] Revert "cfg80211: make WEXT compatibility unselectable"
On 12/31/14 16:14, Andreas Hartmann wrote:
> Jiri Kosina wrote:
>> On Wed, 31 Dec 2014, Arend van Spriel wrote:
>>
>>> The thing with WEXT is that it will stay as is. So if tools like wicd
>>> want to support new features like P2P it will need to make the switch. I
>>> checked out wicd repo and found a number of iwconfig calls and they kick
>>> off wpa_supplicant with wext driver.
>>
>> Unfortunately this is by no means just about wicd. I have already received
>> a few off-list mails from people who were wondering why their home-made
>> scripts / tools, which are running 'iwconfig' directly suddenly stopped to
>> work, and that it was indeed fallout of WEXT going away. Given the very
>> short time this has been in mainline, you can probably imagine the
>> fireworks once this appears in major release.
>
> It is not just the userspace tools (I prefer them, too), which need
> wext, but a lot of drivers, too, such as Mediathek drivers e.g. which
> perform *much* better compared to rt2x00, especially concerning USB
> chips like the one used by Linksys AE3000 (3x3 Mimo)
> (https://wikidevi.com/wiki/Linksys_AE3000), which achieves average
> throughputs around 14 MB/s *average* with scp of big (> 10 GB) crypted
> files even through reinforced-concrete floor(!) - rt2x00 is *far* away
> of providing such a performance.
>
> Next bad point of rt2x00 e.g. is the huge CPU overhead - compare
> rt5572sta on Raspi with rt2x00 running netperf and you will see the huge
> problem of rt2x00 (which is covered on x86 by mostly oversized multi
> core CPUs).
>
> Another big advantage of rt5572sta is: it is *stable* over a lot of
> kernel versions (as long as the kernel didn't break interfaces - but
> there are patches to catch them).
>
> Even ath9k, which usually is a really fine driver, is broken on some
> kernel versions (link and throughput is not stable - my use case depends
> *heavily* on very high and longterm stable throughput). That's why I'm
> using a VM for my ath9k-device to be independent of these quality
> problems of mac80211 (or maybe ath9k - don't know) over different kernel
> versions.
>
>
> All in all:
> If you want to get rid of wext, you still have to go a *very* long way
> to get the same *stable* and high throughput quality with *all* chips
> depending on mac80211 and not just a few flagship drivers like Atheros.
Hi Andreas,
That's a nice list of unrelated stuff. This has all nothing to do with
WEXT. Actually, you can build rt5572sta with cfg80211 support
(RT_CFG80211_SUPPORT). This thread is about the configuration API and
not about driver performance.
Regards,
Arend
> Kind regards,
> Andreas Hartmann
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists