Re: [PATCH V2] Add iwlwifi wireless drivers

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

On Thu, 2007-09-06 at 03:32 +0200, Ian Schram wrote:

> I thought I'd try and answer this question to the best of my ability, since it
> has been asked before. And even though it's open source and now has been submitted
> to this list, leaving this unanswered feels like a creepy way of potential time bombs
> and frustration. That said I'm probably not the best person to do it.

Thanks, I appreciate it.

> iwl3945-rs:
> 
> - the device can retry at different rates, and hence is able to deduct
> from the total number of retries a packet needed at which rates it failed/
> succeeded

We recently discussed this capability, atheros hardware as it as well,
so we need a generic way to tell mac80211 how many retry rates the
hardware can support so that better rate control algorithms can be
written. I don't see this as device specific but rather as something the
mac80211 driver interface is currently lacking. Cf. the "minstrel" rate
control algorithm.

> - tables of expected tpt (throughput?) which are used in the the throughput
> calculation are probably not very universal?
> there aren't identical for 3945 and 4965.

Seems to me like something the driver should be doing and reporting to
the rate control algorithm via some defined interface.

> -some synchronization of the station list with the device ucode happens here

This is totally wrong. Please extend mac80211 instead, maybe the
sta_table_notification callback.

> So that's that. Some questionable implementation details, but it does use
> device specific logic/capabilities in order to decide which rate to use.
> Now what do we do?

As a first step, I think we (i.e. mostly you because only few other
people have an interest right now) should work on defining an interface
between the drivers and mac80211 that allows the drivers to export these
capabilities like "how many different retry rates can I give you with
one packet" in order to allow different rate control algorithms to take
advantage of that. Oh and then don't just implement the interface and
push it onto us as a "ok done" thing but discuss the interface first.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]