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