[OpenWrt-Devel] Why OpenWrt sucks?

[Felix Fietkau]

On 2015-03-10 20:22, Zefir Kurtisi wrote:
> On 03/09/2015 11:28 PM, David Lang wrote:
>> On Mon, 9 Mar 2015, José Vázquez wrote:
>> 
>>> OpenWRT is a linux distro oriented to networking so the kernel and
>>> drivers are important, but you must not forget that the init process
>>> (procd and related after AA) is one of the cores of this distro and
>>> makes it work. The most relevant packages are oriented to networking,
>>> but with the feeds you can make anything that you want, making it very
>>> versatile.
>>> Also we must take in mind that OpenWRT works with GPL drivers and code
>>> (only few are proprietary); I think that one of the main advantages of
>>> use them is that anybody can contribute, and IMHO, are easy to
>>> maintain.
>>> One of the performance penalties come with the network drivers: while
>>> proprietary drivers are tightly coupled with the hardware, the drivers
>>> developed by OpenWRT guys and collaborators should not be so
>>> "complicated" because when the kernel version is changed they can
>>> generate a lot of problems and headaches, while more "generic" drivers
>>> do not take advantage of all the hardware features, overloading the
>>> cpu with tasks that in stock firmwares are managed by specific
>>> subsystems that are faster for those specific tasks.
>> 
>> there is no reason why the open drivers need to be slower than the proprietary
>> ones. History has shown that with sufficient information, the open drivers end up
>> being as fast, or faster than the proprietary ones. But it does take time and
>> cooperation with the manufacturer to do this with the latest hardware.
>> 
> At least for ath9k I can confirm that - if there is a performance disadvantage to
> the closed source reference driver at all - it is not because it is closed or
> keeps information secret. In fact, beside some very specific functions not useful
> for the common user, all relevant information from the reference driver already
> found its way into ath9k.
> 
> With that, if there is a performance gap, it is because of the difference in
> architecture. Compared to the mac80211-ath9k combo, QCA's reference drivers are
> almost monolithic (ok, there is a mac and a hal, but with as much cross-layer
> optimizations as possible) and that is where you gain some speed percentage.
Even the QCA reference driver has a separation between protocol stack
and the hardware driver. Aside from the fact that its protocol stack is
only used by its own driver, it is not significantly more monolithic in
design.

> This gives at least two sources for optimization for the reference driver: 1) save
> inter-layer processing overhead (passing commands from hostapd directly to HW is
> cheaper than passing it through 4 layers), and 2) vastly reduce locking when you
> are in full control of concurrency.
The overhead of commands issued by hostapd is pretty much irrelevant.
All that matters for driver performance is the actual data path (network
stack, mac80211 tx/rx, driver tx/rx).
Also, I've not seen any indication in my tests that locking is a
measurable cause of performance issues.
When it comes to performance issues, guesswork is meaningless,
measurements (e.g. profiling results) matter!

- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel