On 15/11/15(Sun) 21:32, Stefan Sperling wrote:
> On Sun, Nov 15, 2015 at 08:27:28PM +0100, Martin Pieuchot wrote:
> > I'm really concerned about the use of tasks in iwm_ampdu_rx_{start,stop}
> >
> > By looking at iwn(4) which also has a lot of bits for handling A-MPDU
> > and A-MSDU frames, it seems to me that this go against damien@'s design.
> > This design might have its own set of problems, but I fear that working
> > around them might add another set of problems on top.
>
> iwm(4) runs all fw commands in process context and checks for errors
> after tsleep(). This means we cannot return errors to the interrupt
> context which triggered the commands.
> Remember this? http://marc.info/?l=openbsd-tech&m=143463744006189&w=2
>
> iwn(4) triggers fw commands in interrupt context and ignores errors.
I remember, that's why I'm raising the subject again.
> I'm still not sure which is better. Perhaps iwm(4) should do what iwn(4)
> does. Perhaps not. But this is a general problem with iwm(4) and it's not
> restricted to just this task. I'm simply following the current pattern.
I'm not saying that's better. I'm saying that the actual 11n driver/
stack glue has been designed with iwn(4)'s behavior in mind. So I
think that's one argument more to do the same with iwm(4)... At least
at this stage.
> > Are you sure that when these functions are called it is safe to modify
> > the soft states of the Block Ack agreements before notifying the
> > hardware?
>
> The soft state is one layer removed from the real action.
>
> Based on my understanding so far, I believe it works like this:
>
> [...]
>
> If the hardware fails to set up a block ack we agreed to, or if
> for some other reason the hardware isn't set up for block ack yet
> when we receive an A-MPDU, I think the worst case should be that
> the sending AP will time out its BA agreement, and perhaps it will
> see dropped frames and retry. net80211 will recognize duplicates
> based on their sequence numbers and drop them. Non-aggregated frames
> are always a valid fallback so the AP may choose to try negotiating
> block ack again, or it might not.
Then I think it's fine.
