AR5416 beacon issue.

[Bernhard Schmidt]

On Tuesday, August 23, 2011 15:10:56 Adrian Chadd wrote:
> On 23 August 2011 20:15, Bernhard Schmidt <bschmidt at freebsd.org> wrote:
> >> Bernhard?
> >
> > Please stop top posting, thanks.
> 
> Ok.
> 
> > You can't over-simplify here. Some HW supports generating seqnos,
> > some other don't and yet again other overwrites it anyways. What
> > you really need is a per-case decision. If the hardware is able
> > to generate seqnos correctly (which afaik ath is) then use it.
> > If the generated numbers are wrong for whatever reason, then try
> > to use those generated in software.
> 
> ath generates sequence numbers ok - except for handling 11n aggregation.
> At that point, you need to do sequence number allocation in software.
> So how's the beacon code (in this example) supposed to handle it?

The net80211 generated beacon frames will always have valid seqno.
If the hardware can't overwrite the seqno the solution is to simply
not touch the frame. :)

> > What you can generalize is, if the HW does something wrong (or
> > not 100% correct) try to use SW as a fallback. See the beacon
> > miss implementation in SW as an example, it is only used for
> > the multiple VAP case, otherwise the HW function itself is used.
> 
> Right. But I'm still unclear about how we could possibly handle it.
> (But I've been deep in this aggregation stuff, so my "big picture"
> handle is not quite working at the moment.)
> 
> For example, with ath sequence number generation - we need to do it in
> software if the NIC is going to be doing 11n, otherwise we can leave
> it as-is.
> So do we somehow teach the net80211 code about the hardware
> capabilities? Do we add a capability _and_ a callback to
> enable/disable it?
> If we're doing 11n then we have to disable it - so net80211 has to
> fill in its own sequence numbers.
> If we're not doing 11n then the ath HAL still disables hardware
> sequence numbers on AR5416 and later - how do you propose we tell the
> driver to flip it on/off?

No reason too, frames generated by net80211 will always have a valid
(well, there is the 11n TX aggr exception) seqno. In the worst case,
just leaving it alone should work out pretty well. For the aggr case,
you have to track the seqnos yourself. It requires knowledge about
HW queues, its orders, the assignment of frames to queues, the
current retry list, ACK status and so on.. net80211 doesn't have all
that knowledge currently.

-- 
Bernhard