#
40f65a4d |
| 07-Aug-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r254014
|
#
552311f4 |
| 17-Jul-2013 |
Xin LI <delphij@FreeBSD.org> |
IFC @253398
|
#
cfe30d02 |
| 19-Jun-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge fresh head.
|
Revision tags: release/8.4.0 |
|
#
47e8d432 |
| 26-Apr-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Add const qualifier to the dst parameter of the ifnet if_output method.
|
#
69e6d7b7 |
| 12-Apr-2013 |
Simon J. Gerraty <sjg@FreeBSD.org> |
sync from head
|
#
a03fbc7e |
| 09-Mar-2013 |
Martin Matuska <mm@FreeBSD.org> |
MFC @248093
|
#
5cda6006 |
| 08-Mar-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Bring over my initial work from the net80211 TX locking branch.
This patchset implements a new TX lock, covering both the per-VAP (and thus per-node) TX locking and the serialisation through to the
Bring over my initial work from the net80211 TX locking branch.
This patchset implements a new TX lock, covering both the per-VAP (and thus per-node) TX locking and the serialisation through to the underlying physical device.
This implements the hard requirement that frames to the underlying physical device are scheduled to the underlying device in the same order that they are processed at the VAP layer. This includes adding extra encapsulation state (such as sequence numbers and CCMP IV numbers.) Any order mismatch here will result in dropped packets at the receiver.
There are multiple transmit contexts from the upper protocol layers as well as the "raw" interface via the management and BPF transmit paths. All of these need to be correctly serialised or bad behaviour will result under load.
The specifics:
* add a new TX IC lock - it will eventually just be used for serialisation to the underlying physical device but for now it's used for both the VAP encapsulation/serialisation and the physical device dispatch.
This lock is specifically non-recursive.
* Methodize the parent transmit, vap transmit and ic_raw_xmit function pointers; use lock assertions in the parent/vap transmit routines.
* Add a lock assertion in ieee80211_encap() - the TX lock must be held here to guarantee sensible behaviour.
* Refactor out the packet sending code from ieee80211_start() - now ieee80211_start() is just a loop over the ifnet queue and it dispatches each VAP packet send through ieee80211_start_pkt().
Yes, I will likely rename ieee80211_start_pkt() to something that better reflects its status as a VAP packet transmit path. More on that later.
* Add locking around the management and BAR TX sending - to ensure that encapsulation and TX are done hand-in-hand.
* Add locking in the mesh code - again, to ensure that encapsulation and mesh transmit are done hand-in-hand.
* Add locking around the power save queue and ageq handling, when dispatching to the parent interface.
* Add locking around the WDS handoff.
* Add a note in the mesh dispatch code that the TX path needs to be re-thought-out - right now it's doing a direct parent device transmit rather than going via the vap layer. It may "work", but it's likely incorrect (as it bypasses any possible per-node power save and aggregation handling.)
Why not a per-VAP or per-node lock?
Because in order to ensure per-VAP ordering, we'd have to hold the VAP lock across parent->if_transmit(). There are a few problems with this:
* There's some state being setup during each driver transmit - specifically, the encryption encap / CCMP IV setup. That should eventually be dragged back into the encapsulation phase but for now it lives in the driver TX path. This should be locked.
* Two drivers (ath, iwn) re-use the node->ni_txseqs array in order to allocate sequence numbers when doing transmit aggregation. This should also be locked.
* Drivers may have multiple frames queued already - so when one calls if_transmit(), it may end up dispatching multiple frames for different VAPs/nodes, each needing a different lock when handling that particular end destination.
So to be "correct" locking-wise, we'd end up needing to grab a VAP or node lock inside the driver TX path when setting up crypto / AMPDU sequence numbers, and we may already _have_ a TX lock held - mostly for the same destination vap/node, but sometimes it'll be for others. That could lead to LORs and thus deadlocks.
So for now, I'm sticking with an IC TX lock. It has the advantage of papering over the above and it also has the added advantage that I can assert that it's being held when doing a parent device transmit. I'll look at splitting the locks out a bit more later on.
General outstanding net80211 TX path issues / TODO:
* Look into separating out the VAP serialisation and the IC handoff. It's going to be tricky as parent->if_transmit() doesn't give me the opportunity to split queuing from driver dispatch. See above.
* Work with monthadar to fix up the mesh transmit path so it doesn't go via the parent interface when retransmitting frames.
* Push the encryption handling back into the driver, if it's at all architectually sane to do so. I know it's possible - it's what mac80211 in Linux does.
* Make ieee80211_raw_xmit() queue a frame into VAP or parent queue rather than doing a short-cut direct into the driver. There are QoS issues here - you do want your management frames to be encapsulated and pushed onto the stack sooner than the (large, bursty) amount of data frames that are queued. But there has to be a saner way to do this.
* Fragments are still broken - drivers need to be upgraded to an if_transmit() implementation and then fragmentation handling needs to be properly fixed.
Tested:
* STA - AR5416, AR9280, Intel 5300 abgn wifi * Hostap - AR5416, AR9160, AR9280 * Mesh - some testing by monthadar@, more to come.
show more ...
|
Revision tags: release/9.1.0 |
|
#
300675f6 |
| 27-Nov-2012 |
Alexander Motin <mav@FreeBSD.org> |
MFC
|
#
a10c6f55 |
| 11-Nov-2012 |
Neel Natu <neel@FreeBSD.org> |
IFC @ r242684
|
#
23090366 |
| 04-Nov-2012 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Sync from head
|
#
30e4856a |
| 26-Oct-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Fix up some initial issues with creation and deletion of hotplugged net80211 devices and vaps.
* vnet sets vnet0 during kldload and device probe/attach, but not for the hotplug event. Thus, plugg
Fix up some initial issues with creation and deletion of hotplugged net80211 devices and vaps.
* vnet sets vnet0 during kldload and device probe/attach, but not for the hotplug event. Thus, plugging in a NIC causes things to panic. So, add a CURVNET_SET(vnet0) for now during the attach phase, until the hotplug code is taught to set CURVNET_SET(vnet0).
* there's also no implied detach vnet context - so teach the detach path about ifp->if_vnet.
* When creating/deleting vaps, also set the vnet context appropriately. These can be done at any time.
Now, the problems!
* ieee80211.c is supposed to be OS-portable code, with no OS-specific stuff like vnet. That should be fixed.
* When the device hotplug code gets taught about CURVNET_SET(vnet0), the device vnet set can go away; but the VAP vnet set still needs to be there.
* .. and there still is the question about potentially adding an implied CURVNET_SET(ifp->if_vnet) on if_free(), since any/all devices may end up being detached by a hotplug event in today's world. That's going to be a topic of a subsequent commit.
show more ...
|
#
6a068746 |
| 15-May-2012 |
Alexander Motin <mav@FreeBSD.org> |
MFC
|
#
38f1b189 |
| 26-Apr-2012 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r234692
sys/amd64/include/cpufunc.h sys/amd64/include/fpu.h sys/amd64/amd64/fpu.c sys/amd64/vmm/vmm.c
- Add API to allow vmm FPU state init/save/restore.
FP stuff discussed with: kib
|
Revision tags: release/8.3.0_cvs, release/8.3.0 |
|
#
8833b15f |
| 03-Apr-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r232686 through r233825 into projects/pf/head.
|
#
b94299c4 |
| 25-Mar-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Create a new task to handle 802.11n channel width changes.
Currently, a channel width change updates the 802.11n HT info data in net80211 but it doesn't trigger any device changes. So the device dr
Create a new task to handle 802.11n channel width changes.
Currently, a channel width change updates the 802.11n HT info data in net80211 but it doesn't trigger any device changes. So the device driver may decide that HT40 frames can be transmitted but the last device channel set only had HT20 set.
Now, a task is scheduled so a hardware reset or change isn't done during any active ongoing RX. It also means that it's serialised with the other task operations (eg channel change.)
This isn't the final incantation of this work, see below.
For now, any unmodified drivers will simply receive a channel change log entry. A subsequent patch to ath(4) will introduce some basic channel change handling (by resetting the NIC.) Other NICs may need to update their rate control information.
TODO:
* There's still a small window at the present moment where the channel width has been updated but the task hasn't been fired. The final version of this should likely pass in a channel width field to the driver and let the driver atomically do whatever it needs to before changing the channel.
PR: kern/166286
show more ...
|
#
8fa0b743 |
| 23-Jan-2012 |
Xin LI <delphij@FreeBSD.org> |
IFC @230489 (pending review).
|
#
7b2b15eb |
| 22-Jan-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Mark the taskqueue as the _net80211_ taskqueue.
This makes it much easier to determine whether an event occurs in the net80211 taskqueue (which was called "ath0 taskq") or the ath driver taskqueue (
Mark the taskqueue as the _net80211_ taskqueue.
This makes it much easier to determine whether an event occurs in the net80211 taskqueue (which was called "ath0 taskq") or the ath driver taskqueue (which is also called "ath0 taskq".)
show more ...
|
#
80dbff4e |
| 04-Jan-2012 |
Sean Bruno <sbruno@FreeBSD.org> |
IFC to head to catch up the bhyve branch
Approved by: grehan@
|
Revision tags: release/9.0.0 |
|
#
fcd9500f |
| 17-Dec-2011 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
Fix some net80211 enum nits: - ic_vap_create() uses an ieee80211_opmode argument - ieee80211_rate2media() takes an ieee80211_phymode argument - ieee80211_plcp2rate() takes an ieee80211_phytype argume
Fix some net80211 enum nits: - ic_vap_create() uses an ieee80211_opmode argument - ieee80211_rate2media() takes an ieee80211_phymode argument - ieee80211_plcp2rate() takes an ieee80211_phytype argument - cast to enum ieee80211_protmode and ieee80211_roamingmode to silence compiler warnings
Submitted by: arundel@
show more ...
|
#
155438b4 |
| 16-Mar-2011 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@219680
|
#
6f897ba9 |
| 13-Mar-2011 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
While determining the maxrate for ieee80211_media_setup() honor the device capabilities.
|
#
fbbe47a9 |
| 13-Mar-2011 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
First step on removing the harcoded RX/TX stream and MCS0-15 assumptions.
Initialize ic_rxstream/ic_txstream with 2, for compatibility reasons. Introduce 4 new HTC flags, which are used in addition
First step on removing the harcoded RX/TX stream and MCS0-15 assumptions.
Initialize ic_rxstream/ic_txstream with 2, for compatibility reasons. Introduce 4 new HTC flags, which are used in addition to ic_rxstream and ic_txstream to compute the hc_mcsset content and also for initializing ni_htrates. The number of spatial streams is enough to determine support for MCS0-31 but not for MCS32-76 as well as some TX parameters in the hc_mcsset field.
show more ...
|
#
db06a6f4 |
| 12-Mar-2011 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@219553
|
#
f136f45f |
| 10-Mar-2011 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
Complete the MCS rate table based on the final 802.11n std. While here adjust the IEEE80211_HTRATE_MAXSIZE constant, only MCS0 - 76 are valid the other bits in the mcsset IE (77 - 127) are either res
Complete the MCS rate table based on the final 802.11n std. While here adjust the IEEE80211_HTRATE_MAXSIZE constant, only MCS0 - 76 are valid the other bits in the mcsset IE (77 - 127) are either reserved or used for TX parameters.
show more ...
|
Revision tags: release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0 |
|
#
0c21a60c |
| 05-Dec-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
svn+ssh://svn.freebsd.org/base/head@216199
|