please update -head if you're running it - testing changes to NULL frames and sequence number offload

hi!

I've been sitting on this for a while and noodling on the devices I have
here.
If you're using -HEAD, please update and let me know if wifi is OK or not
OK after today's commits.


First up is enabling sequence number offloading in almost everything. I
think the only thing left to do is the linuxkpi layer and then
thoroughly test the heck out of it. The TL;DR is that now the sequence
number assignment is done by a call from the driver - at the same time it's
doing encryption and other setup - rather than net80211. This removes the
need for the "TX lock" in the net80211 transmit path.

I added this way back in 2011/2012 timeframe because I noticed that after
the vap work, sometimes i'd get dropped packets / hung data streams. What
was happening was the sequence numbers were assigned by net80211, but the
encryption - and the encryption sequence IVs - were being done in the
driver. This can happen concurrently across multiple CPUs, or even
preempted on a single CPU. It wasn't a problem on earlier single CPU setups
because preemption wasn't as aggressive, and pre-VAP the encapsulation /
encryption was actually done by the driver calling into net80211.

I cheaped out and added that lock. It fixed it for everything, with the
cost of concurrency performance and some LORs.

So, my goal is to finally get rid of the lock entirely during -16.

Secondly, the NULL data frame handling. This is something that has plagued
things like iwn(4) forever, where the TX sequence number would get out of
whack with the TX DMA ring (oh no I'm going into the weeds.) Anyway, it
would cause the firmware to crash. A lot of NICs with firmware MACs
actually generate their own NULL data frames so there's no need for us to
do it. I've turned it off for a handful of NICs so we can test it out.

Thanks! More to come once this settles.



-adrian