> On 20 Mar 2019, at 08:38, Sebastian Moeller <moell...@gmx.de> wrote: > > Hi Kevin, > > Impressive! I had a look at your_layer_cake.qos, and with half the brain at > my disposal currently, I am confused. I had thought the idea is to set dscp > marks on internal hosts or the LAN interface ofva router and copy those to > incoming packets of the same flow, but you seem to set dscps in ingress. What > am missing? > I ask because I fully bought your cool-aid ;) I want a "mode" for sqm scripts > where easy to set and control egress dscp from internal hosts is also used > for ingress packets of the same flows. I also bought your argument to > preferably only do that once per flow hook line and sinker. > > AFAICT this is one feature that would solve a lot of issues regarding dscps > in home networks. Especially in the light of how easy it turned out to dscp > mark packets on windows10, and a lot of the potential dscp users come from > the gaming crowd and need something that works on Windows. Sidenote, I really > like how easy win10 makes it to dscp marks all egress packets of a given > binary, I wish I knew a similarly straightforward way to do this in Linux and > macosx.... > > Thanks for this cool feature….
Ha, ok, probably not helped by my commit message having get & set swapped with regards to the typical usage comments. I’ll try to go through it in context of my layer cake script. Egress is packet leaving router on wan interface to ‘Internet’ Ingress is packet arriving at router on wan interface from ‘Internet’ Egress packet goes through iptables mangle table, postrouting. It doesn’t have ’statemask’ bit set so is sent to the DSCP mangling rule where it may have had the DSCP changed..it doesn’t matter. Then it will hit conndscp running in ‘both’ mode. Internally conndscp will go through the ’set’ check first, where it will do nothing because the ’statemask’ bit is unset. Then it will go through the ‘get’ check, which it will go through, storing the DSCP into the mark and setting the ’statemask’ bit. This is then passed to cake as before which uses the DSCP to do tin selection. The ‘reply’ packet will come in on the ingress path. There it will hit conndscp which will find the conntrack entry and hence the mark. Conndscp is in ’set’ mode, so it will look at the ’statemask’ bit which is set and restore the mark stored DSCP into the diffserv field on the packet. The packet is passed on to the cake which uses the now restored DSCP to do tin selection. Subsequent egress packets will take this path: It goes through iptables mangle table, postrouting but this time the conntrack mark has the ’statemask’ bit set, so it is NOT sent to the DSCP mangling rules. Then it will hit conndscp running in ‘both’ mode. As before internally it look at the ’set’ code first and because the ’statemask’ bit is now set, it will restore the DSCP contained in the mark to the egress packet. The get action won’t run because the statemask bit is set. The packet is passed on to cake which will use the (restored) DSCP to do tin selection. The ingress path is exactly the same as before. I suspect the subtlety is the ‘both’ action and its internal order of set -> get which allows the ‘one off’/’set forget’ type operation. Does that help? Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
