11n is QoS derived but it's not WME.
I think we should extract qos control filed and ht control fields from
header in pre-handlers
one of them is qos parser, just it needs to save the qos fields on
the txrx data
This will be needed in both rx and tx path. With 11n there are few
other points in the code that these fields need to be accessed.
You can query fc whether this fields are set.
ieee80211_txrx_data
u16 fc, ethertype;
+ u16 qos_ctrl; /* cpu order */
+ u16 ht_ctrl;
The other option is to introduce again all the types of headers
24,26...32. I don' t know real reason why they are not present in
mac80211 but it looks intentional.
Next option to avoid the blow up of header types we can use offset functions
int ieee80211_get_qosctl_offset(u16 fc)
int ieee80211_get_htctl_offset(u16 fc)
This will give consistent offset of these control fields but it still
won't work when you use this remove qos field handler.
Other thing is to change ieee80211_get_hdrlen function as the header
is longer now by other 2 octets (ht control field)
On 4/2/07, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
On Mon, 2007-04-02 at 23:30 -0700, mabbas wrote:
> I am calling ieee80211_rx_h_data_agg after ieee80211_rx_h_remove_qos_control which
> clears all QoS data which include QOS_CONTROL_A_MSDU_PRESENT bit. We can solve this by
> adding new field is_frame_agg to ieee80211_txrx_data.u.rx.is_frame_agg which will be set in
> ieee80211_rx_h_parse_qos or we can add new function to ieee80211_rx_pre_handlers just to do that. the other
> option is to shuffle calling sequence here if that possible to call ieee80211_rx_h_data_agg
> before ieee80211_rx_h_remove_qos_control. any opinion?
Since it's part of the QoS stuff that .11n adds I think we should stick
it into the qos parser.
johannes
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
