Hi all, There is a weird interaction between ovs, tc, and wireless when it comes to a wireless interface. In short, mac80211 ( the generic Linux wireless driver ) rewrites the skb->priority field before the packet goes through the tc stack, and all packets end-up in the default class even though they are classified for a specific queue. I've confirmed this with wireless cards, but the same might happen with wired cards that support multiple hardware queues.
More details : Wireless cards are registered by default as mq qdiscs (multiqueue), due to the different queues they have (4 for different classes of data - e.g. voice, video, best effort, one for beacons etc). Before a packet is queued to the qdisc, the device asks the driver which queue should this packet by destined for ( through function ndo_select_queue ). Wireless drivers have their own way of classifying packets to different queues (which I wasn't able to figure out how it works...), and during this call it will reset the skb->priority field on the sk_buff. My understanding is that this is the way ovs maps openflow-queues to tc classes. Even though OVS changes the qdisc to an HTB qdisc with different classes, skb->priority keeps getting reset, and all packets go through the default class. I changed the mac80211 code to keep skb->priority intact, and things were correctly classified in tc. Not sure whether this is a bug, but it's a weird/annoying interaction. I don't really see the point of the driver choosing how to queue packets - I'd rather define the desired functionality on a single point. Ideally I'd like to choose ovs queues to specify tc behavior, and also how different queues are mapped to the 802.11 hardware queues.. -- Yiannis .
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
