I would recommend to try this out in both settings. WiFi WMM is not free of side-effects so using AC_VI, and AC_VO is not a clear win in all cases (both classes can hog considerable amounts of air time, and AC_VO is limited in how much aggregation it can perform resulting in an overall throughput loss). So I would be weary to use WMM unless I had made sure that the amount of traffic in AC_VI and AC_VO (especially the latter) was sufficiently low. But that realy depends on the local use-case, so I would say, try out both options.
I always play on WiFi. As you may know by now, I'm not fond of FPS, and all my gaming is done in GeForce NOW. Based on the nft ruleset it might or might not impact your gaming if you are on WiFi. However, in my network, there are two considerations:
I have minimal prioritisation of traffic (@moeller0 TM), i.e., GeForce NOW, Zoom, Teams and VoIP.
I overwrite my qos_map so any EF packets go over AC_VI. I only use AC_VO for a few things, and gaming is not one of them.
My results are good. My latency is always around 25 ms and jitter sub 2 ms, with a median of 1 ms. Of course, your mileage might be very different.
UPDATE
After the last year of back and forth with DSCP marking, scripts, and a whole set of different approaches by people in this forum, I'm dumping my brain here. And I will lean on what I said so many times to someone in this forum, stop with the "it feels slow" nonsense and provide data, please.
I see that many people are using these DSCP markings, scripts, etc., when they connect one computer via Ethernet to the router while any other traffic in the network is non existent. So, to be clear, these scripts and configurations in these cases will do nothing at all. If you want to prove me wrong, please, provide data, not feelings; I would like to see it.
At this stage, I firmly believe most gamers are just changing things for the sake of changing things, and on many more occasions than they would like to admit, it's their lack of better gaming skills that makes it "feel slow".
When testing dscpclassify in the beginning i marked my packets with ef and then i was wondering why they appeared as cs6. First i thought there was an issue with my config but then I had a closer look at the code and found out that with option wmm ef gets remarked with cs6 so I disabled it. I mean in the end it doesn’t really make a difference with diffserv4 if its cs6 or ef as it ends in the same tin but for new users i think this could be a bit misleading so i also recommended it to other users who got confused. I think @Dopam-IT_1987 wanted to mark packets with cs3 and it got remapped to cs4 (what actually would make a difference with cake) because of option wmm. I think wmm should by default be disabled to not confuse new users but this i just my personal opinion.
You can just download the the new files from github as instructed in the github readme. Probably the easiest way…
or
You can also build your own firmware image (that’s how i do it) which is well documented in the OpenWrt docs. Just clone the dscpclassify github repo into your packages folder in your build root. If then there is a change within dscpclassify you only have to „git pull“ to get the changes and build a new image. At least that’s how i do
config rule
option name 'DNS'
list proto 'tcp'
list proto 'udp'
list dest_port '53'
list dest_port '853'
list dest_port '5353'
option class 'cs2'
I would like to prioritize the tcp games also in cs4
but not to include the tcp port 1935 I thought of doing like this
config rule
option name 'ps5 consoles'
option proto 'tcp'
list src_ip '192.168.2.160'
list dest_port '!1935'
option class 'cs4'
option family 'ipv4'
option counter '1'
I would like the 1935 port to remain in cs3 because I apply cake sqm in diffserv4
why I do this because some games on pc play in tcp like WoW or LoL I think
This is arguable, also I would propose that on OpenWrt the way to align WiFI ACs with desired priority tiers is to adjust the qos_map instead of manipulating DSCPs, but I accept that this might be a matter of personal taste (and of layering, in a mostly nftable solution it seems attractive to solve this inside nftables as well, compared to dragging in changes to external config files....)
On the wan interface you should see egress DSCPs set by qosify but not ingress DSCPs (you will instead see whatever DSCPs come in from your ISP, these might or might not make sense for your own network, likely the latter).
On the lan interface(s) like br-lan you will see ingress DSCPÜs set by qosify but not egress DSCPs (instead you will see whatever DSCPs were set by the hosts in your internal network, these often can be made to make sense... but you need to use qosify's '+' notation so these are honored)...
