... I get motion sickness. 
After 4 minutes of watching the game just remembered why I don't play FPS.
What do you mean? How to change their priority? If so, you'll find how to do it using iptables and ctinfo in the forum, search for it. You can't do it with Qosify, to my knowledge.
ok this is my understanding based on my experience:
this is a typical architecture usually we have
[[ pc (client) --- lan --- owrt ]] --- wan --- isp modem --- isp network --- other isp networks --- wan --- isp modem -- server router --- lan ...
using my previous tcpdump as example
# tcpdump -i eth1 -n -v 'host 8.8.8.8 and port 53'
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
21:30:52.017370 IP (tos 0xb8, ttl 64, id 24059, offset 0, flags [DF], proto UDP (17), length 71)
x.x.x.x.53333 > 8.8.8.8.53: 13116+ A? www.elhorrindeclaudia.com. (43)
21:30:52.017427 IP (tos 0xb8, ttl 64, id 24060, offset 0, flags [DF], proto UDP (17), length 71)
x.x.x.x.53333 > 8.8.8.8.53: 16104+ AAAA? www.elhorrindeclaudia.com. (43)
21:30:52.064501 IP (tos 0x0, ttl 122, id 10850, offset 0, flags [none], proto UDP (17), length 119)
8.8.8.8.53 > x.x.x.x.53333: 13116 3/0/0 www.elhorrindeclaudia.com. A 172.67.71.33, www.elhorrindeclaudia.com. A 104.26.4.54, www.elhorrindeclaudia.com. A 104.26.5.54 (91)
21:30:52.083051 IP (tos 0x0, ttl 122, id 23645, offset 0, flags [none], proto UDP (17), length 155)
8.8.8.8.53 > x.x.x.x.53333: 16104 3/0/0 www.elhorrindeclaudia.com. AAAA 2606:4700:20
which means the followings:
using the example above let's check what happens:
1st line tells that from my x.x.x.x (which is my public IP given be my ISP) assigned to my wan interface, so from the wan interface i am sending an outgoing udp packet to destination ip 8.8.8.8 and destination port 53. so my source ip is x.x.x.x, src port is 53333, and dst ip=8.8.8.8 and dst port=53. and i request A records (ipv4) from 8.8.8.8 (google.dns).
2nd line tells similar as 1st line but requesting AAAA records (ipv6)
3rd line tells that google.dns from src ip=8.8.8.8 and src port=53 answering to dst ip=my public ip and dst port=53333 with the requested A records.
4th line tells similar to 3rd line but with AAAA records.
now, back to point 2) - any prioritization tool qosify, sqm will mark outgoing traffic. so any config line in qosify such as
udp:53 voice
ip:x.x.x.x besteffort
dns:*googledrive* bulk
just means that any traffic from your lan to destination on wan with dst port=53 will be marked as voice (in my example TOS=0xb8=DSCP=0x22=EF). or any traffic from your lan to destination wan ip=x.x.x.x will be marked as besteffort. or any traffic to destination on wan to the resolved ips corresponding to a dns query including the specified phrase will be marked as bulk.
so specifying your local listening port 3074 in qosify does not make sense at all!
back to point 3) - as a beauty spot you can do ingress prioritization too which may, i emphasize again may help but thumb rule is: you cannot control in which order the remote end sends traffic to you.
qosify is great in handling this aspect in a very simple way: any traffic you send and classify as outgoing traffic according to a rule, for example via udp:53 voice rule then the reply traffic which is originating from wan from src port 53 will be automatically classified as voice. for example in my case traffic from 8.8.8.8:53 to x.x.x.x:53333 as reply traffic will be classified also [if someone uses option ingress 1] because i have an outgoing rule udp:53 voice.
another misconception regarding marking values: check https://man7.org/linux/man-pages/man8/tc-cake.8.html. diffserv4 defines 4 tins (=queues) called bulk, besteffort, video, voice assigning various set of DSCP values as the base of classification.
diffserv4
Provides a general-purpose Diffserv implementation with four
tins:
Bulk (CS1, LE in kernel v5.9+), 6.25% threshold,
generally low priority.
Best Effort (general), 100% threshold.
Video (AF4x, AF3x, CS3, AF2x, CS2, TOS4, TOS1), 50%
threshold.
Voice (CS7, CS6, EF, VA, CS5, CS4), 25% threshold.
this means a packet marked with CS7 or CS6 or EF or VA or CS5 or CS4, does not matter which but any of this set, will be processed in the voice tin. similarly, a packet marked with AF41 or AF32 or CS2 will be equally handled and processed in the video tin. so when you create your qosify class config i think it is better to pick distinguished values for each class belong to a tin. imho better to define only four classes and pick DSCP values accordingly. the best is to leave the default settings on, and just modify the rule set.
and lastly, i started this post as this is my experience for a reason. because something may work for me but not for you. i may have different preference, i want priority on different kind of traffic than you. i have different internet access than you with different bandwidth, different ISP rules, different load pattern than you. so any config you see here may not fit for your environment. so better to treat any "best config ever" with salt of grain.
and don't forget: you can prioritize a kind of traffic on a cost of other types will be slowed.
Slight elaboration, if you use download/ingress traffic shaping as recommended, you will have moved the bottleneck where a queue builds up to your own router, at which point the remote end will not queue traffic at all* so the packet order will be the order in which they where sent by the traffic sources and potentially being re-ordered and multiplexed along the way (which is the same situation for egress shaping, it is just that inside one's LAN the possibility to re-order things is considerably smaller than over the internet). Inside the traffic shapers queue (if one develops at all) the traffic scheduler can and will pick the next eligible packet based on some consideration, and cake in one of the diffserv modes will look at priority tin first and then maintain flow fairness. So ingress shaping/prioritization works just as well as egress prioritization, except as so often all delay already incurred over the internet, can not be removed, so if packets arrive wildly out-of-order or delayed, cake will not be able to fix that significantly.
*) In reality there will be the occasional "back-spill" event when so much packets rush in, that the remote (oversized and undermanaged) buffers will fill up, but let's assume these events are rare enough to gloss over here ;).
And to your whole post -and your patient for explaining it once more for everyone here:
https://www.youtube.com/watch?v=k3oiXn1iTxE
@moeller0, take your share too. Guys, what an exemplary patient you have to educate people. 
And this is a real complement, non sarcasm involved.
you caught me: am guilty in simplifying things! 
but you are right, thanks for addition.
okay it's good to know that for xato it works do you have a better gaming experience now?
If you want see my connection actually look this video
0 connection hit i down in 1 second
I haven't been able to test how the game feels yet. The only thing I know now is if I have control of the ports that I need. qosify is not working as it should and no matter how many configurations are shared it will not work in order to improve call of duty or whatever game it is as long as I only control the ports of origin and from what I see it does not control the dns of the server. I say all this without having much knowledge either, but little by little I am beginning to understand things and I am going to give openwrt a chance.
ok i see is very hard to install ct_info i have search in forum but don't found ?
is integrate to sqm is right
config queue 'eth1'
option qdisc 'cake'
option ingress_ecn 'ECN'
option egress_ecn 'ECN'
option itarget 'auto'
option etarget 'auto'
option enabled '1'
option interface 'wan'
option download '56000'
option upload '16000'
option debug_logging '0'
option verbosity '5'
option qdisc_advanced '1'
option squash_dscp '1'
option qdisc_really_really_advanced '1'
option linklayer 'ethernet'
option overhead '26'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option tcMPU '0'
option iqdisc_opts 'diffserv4'
option eqdisc_opts 'diffserv4'
option linklayer_adaptation_mechanism 'cake'
option script 'layer_cake_ct.qos'
option squash_ingress '1'
@xato_coslada @amteza when you speak source port you speak like this screen normaly is CS5 is right mine is CS0 ??
ok tell me if are ameliored but while the test can you make your ping is high compared to mine yoru basic connexion is slow after than see is very strange
How do I tell Qosify to use all the cores on my router?
Not sure about the eBPF component, but cake itself is not able to be spread over multiple CPUs, at best you can separate the ingress and egress cake instances to different CPUs
but would it have any improvement or would it be the same?
If you are running out of CPU shaping traffic, it will help.
and how do i activate it?
Quick note, over in another thread it seems port based marking can work in a very simple qosify configuration: https://forum.openwrt.org/t/sqm-cable-docsis-3-1-settings-packet-prioritization/126790/80?u=moeller0
Could it be that the port based marking is simply over-ruled/overwritten by a rule executed later?
so this is my qosify config:
Did i do something wrong or are there any optimizations for my config ? I´m on a 1000/50 cable connection and i just want my gaming traffic to be prioritized so what i need would be some method that can port match and listen to ports and prioritize the ingress and egress packets. Is there some way to do that ?
I had attempted to create a priority list of the different options a while back. Not sure it is still accurate, or if it ever was accurate.
Thanks. In that list has 1 higher or lower priority than 2.?
1 is higher priority than 2.
Thanks, than priority is not the cause why port rules sometimes do not seem to work....
