James Harper wrote: 
How are you trying to support this? It should be as simple as telling Windows that it is supported and then maintaining different packet queues in your driver. I don't think that there is any state information that is shared between different adapters.

What happens on the backend interface and beyond is pretty much beyond your control, but as long as they respect the priority tags it should be fine, and even if they don't at least you have transmitted the packets based on the priority so you've done your bit.
It is a requirement for NDIS6.0 driver when testing NDISTest 6.0(priority). Only a warning reported for NDIS5.1 driver.

The server side will send packets with Non-Zero priority, and client side will check whether the packets received is with correct priority or not. So if keep a different queue in miniport dirver, miniport can not put the priority tag in the frame, and receive side still fails to receive the correct priority tag packets.

Following information is i googled:

The specific NDIS structure is NDIS_NET_BUFFER_LIST_8021Q_INFO, which contains member variables for both VlanID and UserPriority, and is passed to the NDIS miniport driver for implementing both priority tagging (UserPriority) and VLAN (VlanId). It is up to the NDIS miniport driver to actually insert the 802.1Q tag into the frame based on these values before transmitting on the wire. A miniport driver will only insert this tag if the feature is supported and enabled in the advanced properties of the NIC driver;

The miniport drivers must strip the tag when received, and populate the NDIS_NET_BUFFER_LIST_8021Q_INFO UserPriority and VlanId fields with the values in the tag.

Details is in http://social.msdn.microsoft.com/forums/en-US/networkqosqwave/thread/a774a51c-6c6b-4374-a190-48153b5a74f7/

Any suggestions?

Thanks
Annie.