I need to ask a clarifying question, and think you should get some background. For starters, yes, TC is the only API by which you can set arbitrary layer-2 priority tag (802.1p). GQoS does not allow setting layer-2 priority (only layer-3 DSCP) and qWAVE (qos2) will only set layer-2 for adaptive flows (QOSAddSocketToFlow is *not* called with the QOS_NON_ADAPTIVE_FLOW flag) where the end-to-end path between source and destination will not drop a packet that contains the 802.1p tag. Essentially, qWAVE does an experiment to determine whether the tag will get dropped, and won't add it if so. You take a risk using TC to add layer-2 tag because it does not do this test and the frame may get dropped by some intermediate network element (network switch or NIC on receiving station).
All that said, I'm not sure what you mean by modifying a TC filter (which is used to match traffic for applying flow properties to) You set 802.1p essentially the same way you set DSCP. In the flow setup, you specify that you want layer-2, layer-3, or both priorities, and what specific value to use. A filter has nothing to do with it. I may be missing something, so please elaborate on what you are trying to do, and I'll try to be of more help. Are you asking specifically how to set 802.1p tag instead of DSCP in the flow creation
-- Gabe Frost [MSFT]
How are you comming to the conclusion that 802.1p tags aren't being added to outgoing traffic For starters, Windows NDIS documentation specifically requires NDIS miniport drivers to strip the 802.1p tag on the receive path, and populate the out-of-band structure with the information for drivers further up the stack. Also, because it's actually the miniport/NIC that adds the 802.1p tag to outgoing frames on the transmit path, tracing software such as NetMon or WireShark will not see the tag. In review:
The only way you can detect if a tag is in a frame is if you purposly use a NIC which behaves incorrectly on the receiving machine, i.e. does not strip the 1p tag on receive. You would then run the sniffer software on that receiving machine to detect the tag. Alternatively, you can write an NDIS filter driver that inspects the out-of-band data structure to see if 1Q.UserPriority is populated.
-- Gabe Frost [MSFT]
This is the correct behavior. It does not matter if the 802.1p tagging option is enabled in the NIC on the receive side. NDIS specification explicitly says any packet received that has an 802.1p tag; the tag must be removed before passing up the stack (the 802.1p tag option only applies to packets being sent, not received). This is why you cannot see the 802.1p tag by running a sniffer on the sender or the receiver. The only way to actually see the tag is to find a NIC which does not follow NDIS specification (some REALTEK NICs operate this way), or to write an NDIS intermediate (NDIS IM) driver which examines the following structure:
NDIS_NET_BUFFER_LIST_8021Q_INFO.UserPriority
The latter is the best option. Please look in the Windows SDK for the NDIS IM sample driver as a starting point. You can then modify this code to look at the above mentioned structure. When the miniport driver removes the 802.1p tag, it populates NDIS_NET_BUFFER_LIST_8021Q_INFO.UserPriority with the value.