Searched hist:283980 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-11-stable/sys/net80211/ | ||
| H A D | ieee80211_freebsd.h | diff 283980 Thu Jun 04 04:37:56 MDT 2015 adrian First pass of adding transmit parameters as an option for outbound 802.11 mbufs. The raw transmit path currently doesn't make it easy to queue these frames: * there's no node reference stored in the mbuf, like for the normal path, and * the bpf supplied raw transmit parameters (rate, rts/cts, etc) are passed in as an argument, not as an mbuf tag. In order to support driver queuing of these frames, we need to be able to put the above into the mbuf before the driver gets it, so the driver /can/ put it into a queue if needed. Use an mbuf tag and for now just verbatim copy the bpf parameters into it. Later on it may grow to include more options but this will do for now. Why would you want to queue raw frames? Well, in the case of iwn(4), we can't send the firmware frames to transmit before we hear a beacon - the firmware will consider passive channels as unavailable until it hears a beacon. The firmware "passive" channel state is cleared upon each RXON command, which is sent to update association status. So, when we attempt association and authorisation, the RXON command causes the firmware to clear out what it's already seen, and so we have to wait for a beacon before we can transmit. Before people get overly excited - this alone doesn't "fix" 5GHz operation - it just makes it (more) possible. The aim here is to convert all the drivers over to use a raw_xmit() API that doesn't include the node and params - instead they'd get those from the mbuf. Then raw_xmit() becomes just a side-channel version of the normal transmit path for management traffic. MFC after: 2 weeks Sponsored by: Norse Corp, Inc. |
| H A D | ieee80211_freebsd.c | diff 283980 Thu Jun 04 04:37:56 MDT 2015 adrian First pass of adding transmit parameters as an option for outbound 802.11 mbufs. The raw transmit path currently doesn't make it easy to queue these frames: * there's no node reference stored in the mbuf, like for the normal path, and * the bpf supplied raw transmit parameters (rate, rts/cts, etc) are passed in as an argument, not as an mbuf tag. In order to support driver queuing of these frames, we need to be able to put the above into the mbuf before the driver gets it, so the driver /can/ put it into a queue if needed. Use an mbuf tag and for now just verbatim copy the bpf parameters into it. Later on it may grow to include more options but this will do for now. Why would you want to queue raw frames? Well, in the case of iwn(4), we can't send the firmware frames to transmit before we hear a beacon - the firmware will consider passive channels as unavailable until it hears a beacon. The firmware "passive" channel state is cleared upon each RXON command, which is sent to update association status. So, when we attempt association and authorisation, the RXON command causes the firmware to clear out what it's already seen, and so we have to wait for a beacon before we can transmit. Before people get overly excited - this alone doesn't "fix" 5GHz operation - it just makes it (more) possible. The aim here is to convert all the drivers over to use a raw_xmit() API that doesn't include the node and params - instead they'd get those from the mbuf. Then raw_xmit() becomes just a side-channel version of the normal transmit path for management traffic. MFC after: 2 weeks Sponsored by: Norse Corp, Inc. |
Completed in 78 milliseconds