>> > > In the driver we could inspect each sk_buff and boost priority of any BOOTP packets so that it will end up in the AC_VO fifo and have hardware coexistence handle it further. I consider that more a pragmatic fix, which is not always the worst thing to go for. However, I would prefer a solution is which user-space, ie. dhcp client can control the priority and/or BT coexistence. > I don't think that the "session solution" as proposed in the RFC is the right one. Because the DHCP could take forever and also because there might be quite a few non-critical packets right after connections. There might be a bunch of services that may wake up and begin to send a whole bunch of things. OTOH, EAPOL and friends *need* priority, so I guess that the per-packet solution is the right one. Note that we could think about a flag in the tx_control in which cfg / mac80211 would let the driver know that this packet is a "high priority packet" or even better "a connection gating packet". This list would include managements / EAPOL / DHCP / any other kind of stuff that look like these. I remember I saw once in the code something that looked like this but can't find it right now. FWIW: here is the code that classifies the packets in iwlwifi: /* High prio packet (wrt. BT coex) if it is EAPOL, MCAST or MGMT */ if (info->band == IEEE80211_BAND_2GHZ && (skb->protocol == cpu_to_be16(ETH_P_PAE) || is_multicast_ether_addr(hdr->addr1) || ieee80211_is_back_req(fc) || ieee80211_is_mgmt(fc))) tx_flags |= TX_CMD_FLG_BT_DIS; -- 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
