Re: [Cake] act_conndscp
On Tue, 2 Apr 2019 at 00:37, Kevin Darbyshire-Bryant wrote: > > > > > On 23 Mar 2019, at 18:35, Kevin Darbyshire-Bryant > > wrote: > > > > > > > >> On 22 Mar 2019, at 21:24, Kevin Darbyshire-Bryant > >> wrote: > >> > >> It looks like act_conndscp has been shot down by the kernel people, at > >> least in its current form. Setting a conntrack mark from tc is regarded > >> as “not sure if it is a good idea”. The other way (conntrack to skb) is > >> fine. That’s sort of good news in that ingress is the hard bit as it’s > >> problematic with iptables. > >> > >> egress is within iptables coverage - ‘just’ need a way to store a DSCP & > >> flag to conntrack mark. > > > > Never give in, never surrender. > > > > Given in. Surrendered. :( FWIW I've applied an updated patch with your iptables 'abomination' and it's been working without issue. ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] act_conndscp
> On 23 Mar 2019, at 18:35, Kevin Darbyshire-Bryant > wrote: > > > >> On 22 Mar 2019, at 21:24, Kevin Darbyshire-Bryant >> wrote: >> >> It looks like act_conndscp has been shot down by the kernel people, at least >> in its current form. Setting a conntrack mark from tc is regarded as “not >> sure if it is a good idea”. The other way (conntrack to skb) is fine. >> That’s sort of good news in that ingress is the hard bit as it’s problematic >> with iptables. >> >> egress is within iptables coverage - ‘just’ need a way to store a DSCP & >> flag to conntrack mark. > > Never give in, never surrender. > Given in. Surrendered. ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] act_conndscp
> On 22 Mar 2019, at 21:24, Kevin Darbyshire-Bryant > wrote: > > It looks like act_conndscp has been shot down by the kernel people, at least > in its current form. Setting a conntrack mark from tc is regarded as “not > sure if it is a good idea”. The other way (conntrack to skb) is fine. > That’s sort of good news in that ingress is the hard bit as it’s problematic > with iptables. > > egress is within iptables coverage - ‘just’ need a way to store a DSCP & flag > to conntrack mark. Never give in, never surrender. Hacked together an iptables connmark extension that saves the DSCP (and optional status bit/s) to the conntrack mark ready for the ’set’ part of the tc conndscp action. So we have the two parts of the operation happening across two different subsystems (iptables for the DSCP->connmark - tc action for the connmark -> DSCP) Two patches - one kernel space and possibly tolerable. One user space which is an iptables copy abomination but it *does* work on my openwrt router. And yet another version of ‘my_layer_cake’ showing how I use it. Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A 0001-xt_connmark-savedscp.patch Description: 0001-xt_connmark-savedscp.patch 0001-savedscp.patch Description: 0001-savedscp.patch my_layer_cake.qos Description: my_layer_cake.qos ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] act_conndscp
It looks like act_conndscp has been shot down by the kernel people, at least in its current form. Setting a conntrack mark from tc is regarded as “not sure if it is a good idea”. The other way (conntrack to skb) is fine. That’s sort of good news in that ingress is the hard bit as it’s problematic with iptables. egress is within iptables coverage - ‘just’ need a way to store a DSCP & flag to conntrack mark. 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
Re: [Cake] act_conndscp
> On 20 Mar 2019, at 09:54, Sebastian Moeller wrote:
>
> Hi Kevin,
>
> thanks for the information!
>
>> On Mar 20, 2019, at 10:01, Kevin Darbyshire-Bryant
>> wrote:
>>
>>
>>
>>> On 20 Mar 2019, at 08:38, Sebastian Moeller 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.
>
> Ah, but why is that necessary, why not simply keep the DSCP on the
> packet as is? Do you want to make sure that packet-captures on wan will show
> the effective DSCP in case that differs from the application set DSCP?
Because if you don’t do that then you have to send every egress packet through
the DSCP marking chain. It is a compromise between dynamic DSCP and having to
go through a (possibly) complicated iptables mangle chain vs a ‘one shot DSCP
set’ and not hitting iptables chains as much.
You can do ‘dynamic’ dscp if you like - use a statemask of ‘0’, that way every
DSCP capable packet is stored into the mark and the last value would be
restored.
>
>
>>
>> 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.
>
> Much simpler, was/am puzzeled about lines like:
> iptables -t mangle -A QOS_MARK_${IFACE} -p tcp -s 192.168.219.5 -m comment
> --comment "Skybox DSCP CS1 Bulk" -j DSCP --set-dscp-class CS1
>
> in the ingress section. with -s (source?) 192.168.219.5 this looks like it
> is processed post-cake (due to ifb preceding iptables), so the packet looks
> like it already is in the internal network, as if you would override the DSCP
> mark just set by conndscp. That surely seems like a wrng interpretation, so I
> would appreciate if you could walk me through the subtleties here. Thank you
> very much in advance! Or am I just daft and this truly is intended
Re: [Cake] act_conndscp
Hi Kevin,
thanks for the information!
> On Mar 20, 2019, at 10:01, Kevin Darbyshire-Bryant
> wrote:
>
>
>
>> On 20 Mar 2019, at 08:38, Sebastian Moeller 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.
Ah, but why is that necessary, why not simply keep the DSCP on the
packet as is? Do you want to make sure that packet-captures on wan will show
the effective DSCP in case that differs from the application set DSCP?
>
> 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.
Much simpler, was/am puzzeled about lines like:
iptables -t mangle -A QOS_MARK_${IFACE} -p tcp -s 192.168.219.5 -m comment
--comment "Skybox DSCP CS1 Bulk" -j DSCP --set-dscp-class CS1
in the ingress section. with -s (source?) 192.168.219.5 this looks like it is
processed post-cake (due to ifb preceding iptables), so the packet looks like
it already is in the internal network, as if you would override the DSCP mark
just set by conndscp. That surely seems like a wrng interpretation, so I would
appreciate if you could walk me through the subtleties here. Thank you very
much in advance! Or am I just daft and this truly is intended to mark outgoing
packets and simply kives inside the ingress() function because it does not
really amtter as long as both shapers are set to rates >0?
>
> Does that help?
Yes, just not all the way, as I said half a brain ATM (aka a cold).
Best Regards
Sebastian
>
>
> 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
Re: [Cake] act_conndscp
And another - sorry! - some stats/info overlimits counts the number of packets that have had their DSCP overwritten/restored/set requeues counts the number of times the ’statemask’ bit has been SET. root@Router:~# tc -s filter show dev eth0 filter parent cacf: protocol all pref 10 u32 chain 0 filter parent cacf: protocol all pref 10 u32 chain 0 fh 800: ht divisor 1 filter parent cacf: protocol all pref 10 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 not_in_hw match / at 0 action order 1: conndscp zone 0 pipe index 1 ref 1 bind 1 mask 0xfc00 statemask 0x0100 mode both installed 218013 sec used 0 sec Action statistics: Sent 1048008900 bytes 7586620 pkt (dropped 0, overlimits 5263898 requeues 87634) backlog 0b 0p requeues 87634 So the above shows that 5263898 packets had their DSCP values set based on a stored DSCP value and thus avoided going through the iptables rules. 87634 packets set that stored value. root@Router:~# tc -s filter show dev eth0 ingress filter parent : protocol all pref 10 u32 chain 0 filter parent : protocol all pref 10 u32 chain 0 fh 800: ht divisor 1 filter parent : protocol all pref 10 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 not_in_hw match / at 0 action order 1: conndscp zone 0 pipe index 2 ref 1 bind 1 mask 0xfc00 statemask 0x0100 mode set installed 218027 sec used 0 sec Action statistics: Sent 7942289574 bytes 9601486 pkt (dropped 0, overlimits 6153697 requeues 0) backlog 0b 0p requeues 0 action order 2: mirred (Egress Redirect to device ifb4eth0) stolen index 1 ref 1 bind 1 installed 218027 sec used 0 sec Action statistics: Sent 7942289574 bytes 9601486 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 The above shows that 6153697 packets had their DSCP values restored from the stored mark value. Note DSCPs are only restored if they’re actually different from the current stored value, so a default DSCP of 0 on an egress path is unlikely to generate a whole load of unnecessary DSCP overwriting on the ingress path. Does any of this help? Kevin > On 20 Mar 2019, at 09:06, Kevin Darbyshire-Bryant > wrote: > > Addendum: If not obvious. There are two separate instances of ‘conndscp’, > one on the egress path (in ‘both’ mode) and one on the ingress path (in ’set’ > mode) > > 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 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
Re: [Cake] act_conndscp
Addendum: If not obvious. There are two separate instances of ‘conndscp’, one on the egress path (in ‘both’ mode) and one on the ingress path (in ’set’ mode) 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
Re: [Cake] act_conndscp
> On 20 Mar 2019, at 08:38, Sebastian Moeller 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
Re: [Cake] act_conndscp
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 On March 20, 2019 9:25:31 AM GMT+01:00, Kevin Darbyshire-Bryant wrote: > > >> On 20 Mar 2019, at 03:31, Ryan Mounce wrote: >> >> On Wed, 20 Mar 2019 at 07:57, Kevin Darbyshire-Bryant >> wrote: >>> >>> >>> On 19 Mar 2019, at 21:24, Ryan Mounce wrote: Hi Kevin, I've finally applied your patches, compiled, and flashed on my >router. Could you share your tc filter action for conndscp to get me >started? >>> >>> Ahh! Ooops yes knew I forgot something - here’s my hacked up >sqm-scripts/my_layer_cake.qos >> >> Okay... I've just spent far longer than I'd like to admit relearning >> the basics of tc filter in order to minify my scripts, but everything >> is working now. See attached for my usage. I'm back to using the >> Turris Omnia which has more than enough grunt to handle my 100/40 >> link, so I haven't put much thought into optimisation. >> >> The only gotcha I ran into with your patch is the explanation >> >>> MODE get (typically ingress) set (typically egress) >> >> This is backwards, but it's confusing anyway. 'get' also sets bits in >> the connmark while 'set' also gets bits from the connmark. > >Dammit! And yes it shows how confusing and how easy it is to get >confused with the get/set terminology. > >> >> I'd suggest changing 'get' to 'save', and 'set' to 'restore'. >> > >Fortunately the patch was sent as an RFC to netdev and I’m sure they’ll >have other things to fix/clarify at the same time. > >Thanks for putting your router/s in the testing firing line. So that’s >at least two of us doing fun DSCP shenanigans on our routers :-) > > > >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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] act_conndscp
> On 20 Mar 2019, at 03:31, Ryan Mounce wrote: > > On Wed, 20 Mar 2019 at 07:57, Kevin Darbyshire-Bryant > wrote: >> >> >> >>> On 19 Mar 2019, at 21:24, Ryan Mounce wrote: >>> >>> Hi Kevin, >>> >>> I've finally applied your patches, compiled, and flashed on my router. >>> Could you share your tc filter action for conndscp to get me started? >> >> Ahh! Ooops yes knew I forgot something - here’s my hacked up >> sqm-scripts/my_layer_cake.qos > > Okay... I've just spent far longer than I'd like to admit relearning > the basics of tc filter in order to minify my scripts, but everything > is working now. See attached for my usage. I'm back to using the > Turris Omnia which has more than enough grunt to handle my 100/40 > link, so I haven't put much thought into optimisation. > > The only gotcha I ran into with your patch is the explanation > >> MODE get (typically ingress) set (typically egress) > > This is backwards, but it's confusing anyway. 'get' also sets bits in > the connmark while 'set' also gets bits from the connmark. Dammit! And yes it shows how confusing and how easy it is to get confused with the get/set terminology. > > I'd suggest changing 'get' to 'save', and 'set' to 'restore'. > Fortunately the patch was sent as an RFC to netdev and I’m sure they’ll have other things to fix/clarify at the same time. Thanks for putting your router/s in the testing firing line. So that’s at least two of us doing fun DSCP shenanigans on our routers :-) 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
Re: [Cake] act_conndscp
On Wed, 20 Mar 2019 at 07:57, Kevin Darbyshire-Bryant wrote: > > > > > On 19 Mar 2019, at 21:24, Ryan Mounce wrote: > > > > Hi Kevin, > > > > I've finally applied your patches, compiled, and flashed on my router. > > Could you share your tc filter action for conndscp to get me started? > > Ahh! Ooops yes knew I forgot something - here’s my hacked up > sqm-scripts/my_layer_cake.qos Okay... I've just spent far longer than I'd like to admit relearning the basics of tc filter in order to minify my scripts, but everything is working now. See attached for my usage. I'm back to using the Turris Omnia which has more than enough grunt to handle my 100/40 link, so I haven't put much thought into optimisation. The only gotcha I ran into with your patch is the explanation > MODE get (typically ingress) set (typically egress) This is backwards, but it's confusing anyway. 'get' also sets bits in the connmark while 'set' also gets bits from the connmark. I'd suggest changing 'get' to 'save', and 'set' to 'restore'. # /etc/rc.local # EGRESS tc qdisc del dev eth2 root tc qdisc replace dev eth2 root handle : cake \ dual-srchost nat fwmark 0x03 wash ack-filter oceanic mpu 64 overhead 26 bandwidth 40Mbit tc -s qdisc show dev eth2 tc filter del dev eth2 parent : tc filter replace dev eth2 parent : matchall action \ conndscp mask 0xfc00 statemask 0x0100 mode get tc -s filter show dev eth2 parent : # INGRESS ip link add name ibe2 type ifb ip link set dev ibe2 up tc qdisc del dev ibe2 root tc qdisc replace dev ibe2 root cake \ ingress dual-dsthost nat fwmark 0x03 ack-filter oceanic mpu 64 overhead 26 bandwidth 99Mbit tc -s qdisc show dev ibe2 tc qdisc del dev eth2 ingress tc qdisc replace dev eth2 ingress handle : tc filter del dev eth2 parent : tc filter replace dev eth2 parent : matchall action \ connmark \ conndscp mask 0xfc00 statemask 0x0100 mode set \ mirred egress redirect dev ibe2 tc -s filter show dev eth2 parent : # /etc/firewall.user iptables -t mangle -N mangle_forward_eth2 ip6tables -t mangle -N mangle_forward_eth2 iptables -t mangle -A mangle_forward_eth2 -j CONNMARK --restore-mark --ctmask 0x03 ip6tables -t mangle -A mangle_forward_eth2 -j CONNMARK --restore-mark --ctmask 0x03 iptables -t mangle -A mangle_forward_eth2 -m mark ! --mark 0 -j RETURN ip6tables -t mangle -A mangle_forward_eth2 -m mark ! --mark 0 -j RETURN # Put all traffic to/from this host in cake's bulk tin iptables -t mangle -A mangle_forward_eth2 -m mac --mac-source 01:23:45:67:89:ab -j MARK --set-mark 1 ip6tables -t mangle -A mangle_forward_eth2 -m mac --mac-source 01:23:45:67:89:ab -j MARK --set-mark 1 iptables -t mangle -A mangle_forward_eth2 -m mark --mark 0 -j RETURN ip6tables -t mangle -A mangle_forward_eth2 -m mark --mark 0 -j RETURN iptables -t mangle -A mangle_forward_eth2 -j CONNMARK --save-mark --ctmask 0x03 --nfmask 0x03 ip6tables -t mangle -A mangle_forward_eth2 -j CONNMARK --save-mark --ctmask 0x03 --nfmask 0x03 iptables -t mangle -A FORWARD -o eth2 -j mangle_forward_eth2 ip6tables -t mangle -A FORWARD -o eth2 -j mangle_forward_eth2 ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] act_conndscp
Kevin Darbyshire-Bryant writes: >> On 19 Mar 2019, at 21:41, Toke Høiland-Jørgensen wrote: >> >> Kevin Darbyshire-Bryant writes: >> On 19 Mar 2019, at 21:24, Ryan Mounce wrote: Hi Kevin, I've finally applied your patches, compiled, and flashed on my router. Could you share your tc filter action for conndscp to get me started? >>> >>> Ahh! Ooops yes knew I forgot something - here’s my hacked up >>> sqm-scripts/my_layer_cake.qos >> >> So this only works with your patched version of CAKE that interprets the >> fwmark as a DSCP value, right? >> > > No. It is completely qdisc agnostic/independent. > > The tc conndscp action stores/restores DSCP to/from the conntrack > mark. CAKE is completely unmodified and looking at DSCP for tin > selection. Ohh, right, silly me... It also goes the other way; of course :) -Toke ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] act_conndscp
> On 19 Mar 2019, at 21:41, Toke Høiland-Jørgensen wrote: > > Kevin Darbyshire-Bryant writes: > >>> On 19 Mar 2019, at 21:24, Ryan Mounce wrote: >>> >>> Hi Kevin, >>> >>> I've finally applied your patches, compiled, and flashed on my router. >>> Could you share your tc filter action for conndscp to get me started? >> >> Ahh! Ooops yes knew I forgot something - here’s my hacked up >> sqm-scripts/my_layer_cake.qos > > So this only works with your patched version of CAKE that interprets the > fwmark as a DSCP value, right? > No. It is completely qdisc agnostic/independent. The tc conndscp action stores/restores DSCP to/from the conntrack mark. CAKE is completely unmodified and looking at DSCP for tin selection. 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
Re: [Cake] act_conndscp
Kevin Darbyshire-Bryant writes: >> On 19 Mar 2019, at 21:24, Ryan Mounce wrote: >> >> Hi Kevin, >> >> I've finally applied your patches, compiled, and flashed on my router. >> Could you share your tc filter action for conndscp to get me started? > > Ahh! Ooops yes knew I forgot something - here’s my hacked up > sqm-scripts/my_layer_cake.qos So this only works with your patched version of CAKE that interprets the fwmark as a DSCP value, right? -Toke ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] act_conndscp
> On 19 Mar 2019, at 21:24, Ryan Mounce wrote: > > Hi Kevin, > > I've finally applied your patches, compiled, and flashed on my router. > Could you share your tc filter action for conndscp to get me started? Ahh! Ooops yes knew I forgot something - here’s my hacked up sqm-scripts/my_layer_cake.qos Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A my_layer_cake.qos Description: my_layer_cake.qos ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] act_conndscp
Hi Kevin, I've finally applied your patches, compiled, and flashed on my router. Could you share your tc filter action for conndscp to get me started? -Ryan On Wed, 20 Mar 2019 at 06:39, Kevin Darbyshire-Bryant wrote: > > I’m not looking forward to the response/s from upstream but we shall see :-) > > Here are the patches for a new tc action conndscp - both the kernel module > and tc’s control of it. > > > > > 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 ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
[Cake] act_conndscp
I’m not looking forward to the response/s from upstream but we shall see :-) Here are the patches for a new tc action conndscp - both the kernel module and tc’s control of it. Cheers, Kevin D-B gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A 0001-initial-experimental-support-for-act_conndscp.patch Description: 0001-initial-experimental-support-for-act_conndscp.patch 0001-net-sched-Introduce-conndscp-action-5.0.patch Description: 0001-net-sched-Introduce-conndscp-action-5.0.patch 0001-net-sched-Introduce-conndscp-action-14.4.patch Description: 0001-net-sched-Introduce-conndscp-action-14.4.patch ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
