[Cake] Announce - possible new feature - DSCP cleaning

[Cake] Announce - possible new feature - DSCP cleaning

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

Greetings :-)

A bit of a blast from the past this one, but one Sebastian Moeller of
this list fame wrote a while ago "

Just played a bit with the shiny new squash option. For my limited testing it seems to work. I do wonder whether the automatic default to besteffort is the ideal behavior though. For example on egress it would be nice to be able to use the internal set DSCP markings but clean them from the outgoing packets as not to leak “information” to the ISP, similarly but more contrived the same could be agued for ingress  "

Well Mr Moeller, today is your lucky day because I've just pushed 'squash' branches to both cake & tc-adv that separate the 'DSCP squashing' behaviour from diffserv behaviour.  Specifying 'squash' sets diffserv mode to 'besteffort' (ie 1 tin only) and squashes DSCP as before, however if you specify something like 'diffserv4 squash' then DSCP codings are noted at qdisc enqueue so tins/bandwidths are used as marked, then the DSCP marking is squashed so on dequeue DSCP has been removed.

The active bit of the change is (diff):

        /* extract the Diffserv Precedence field, if it exists */
-       if (q->tin_mode != CAKE_MODE_SQUASH) {
+       if (q->tin_mode != CAKE_MODE_BESTEFFORT) {
                tin = q->tin_index[cake_get_diffserv(skb)];
                if (unlikely(tin >= q->tin_cnt))
                        tin = 0;
        } else {
-               cake_squash_diffserv(skb);
                tin = 0;
        }
 
+       /* now clear DSCP bits if squashing */
+       if (q->squash)
+               cake_squash_diffserv(skb);


https://github.com/dtaht/sch_cake/tree/squash  &  https://github.com/dtaht/tc-adv/tree/squash

Needs testing (I've not managed to break it yet) and *thought before merging*




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]

Does anyone have any feedback on this?  Good idea/bad idea?  Good/bad
implementation?

Any reason why 'squash' branches of both sch-cake & tc-adv shouldn't be
merged?

On 10/11/15 15:00, Kevin Darbyshire-Bryant wrote:
> Greetings :-)
>
> A bit of a blast from the past this one, but one Sebastian Moeller of
> this list fame wrote a while ago "
>
> Just played a bit with the shiny new squash option. For my limited testing it seems to work. I do wonder whether the automatic default to besteffort is the ideal behavior though. For example on egress it would be nice to be able to use the internal set DSCP markings but clean them from the outgoing packets as not to leak “information” to the ISP, similarly but more contrived the same could be agued for ingress  "
>
> Well Mr Moeller, today is your lucky day because I've just pushed 'squash' branches to both cake & tc-adv that separate the 'DSCP squashing' behaviour from diffserv behaviour.  Specifying 'squash' sets diffserv mode to 'besteffort' (ie 1 tin only) and squashes DSCP as before, however if you specify something like 'diffserv4 squash' then DSCP codings are noted at qdisc enqueue so tins/bandwidths are used as marked, then the DSCP marking is squashed so on dequeue DSCP has been removed.
>
> The active bit of the change is (diff):
>
>         /* extract the Diffserv Precedence field, if it exists */
> -       if (q->tin_mode != CAKE_MODE_SQUASH) {
> +       if (q->tin_mode != CAKE_MODE_BESTEFFORT) {
>                 tin = q->tin_index[cake_get_diffserv(skb)];
>                 if (unlikely(tin >= q->tin_cnt))
>                         tin = 0;
>         } else {
> -               cake_squash_diffserv(skb);
>                 tin = 0;
>         }
>  
> +       /* now clear DSCP bits if squashing */
> +       if (q->squash)
> +               cake_squash_diffserv(skb);
>
>
> https://github.com/dtaht/sch_cake/tree/squash  &  https://github.com/dtaht/tc-adv/tree/squash
>
> Needs testing (I've not managed to break it yet) and *thought before merging*
>
>
>
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Dave Taht]

I have not been doing any active development until... tomorrow.

A goal I have for today is to actually build a version of openwrt +
all this stuff for the linksys ac1200.

I was not particularly huge on using another field (q->squash) to
trigger squashing, and I cannot come up with a use case that makes
sense to me.

Under what circumstances do you think separating these two functions
to be useful?

Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Mon, Nov 16, 2015 at 3:59 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
> Does anyone have any feedback on this?  Good idea/bad idea?  Good/bad
> implementation?
>
> Any reason why 'squash' branches of both sch-cake & tc-adv shouldn't be
> merged?
>
> On 10/11/15 15:00, Kevin Darbyshire-Bryant wrote:
>> Greetings :-)
>>
>> A bit of a blast from the past this one, but one Sebastian Moeller of
>> this list fame wrote a while ago "
>>
>> Just played a bit with the shiny new squash option. For my limited testing it seems to work. I do wonder whether the automatic default to besteffort is the ideal behavior though. For example on egress it would be nice to be able to use the internal set DSCP markings but clean them from the outgoing packets as not to leak “information” to the ISP, similarly but more contrived the same could be agued for ingress  "
>>
>> Well Mr Moeller, today is your lucky day because I've just pushed 'squash' branches to both cake & tc-adv that separate the 'DSCP squashing' behaviour from diffserv behaviour.  Specifying 'squash' sets diffserv mode to 'besteffort' (ie 1 tin only) and squashes DSCP as before, however if you specify something like 'diffserv4 squash' then DSCP codings are noted at qdisc enqueue so tins/bandwidths are used as marked, then the DSCP marking is squashed so on dequeue DSCP has been removed.
>>
>> The active bit of the change is (diff):
>>
>>         /* extract the Diffserv Precedence field, if it exists */
>> -       if (q->tin_mode != CAKE_MODE_SQUASH) {
>> +       if (q->tin_mode != CAKE_MODE_BESTEFFORT) {
>>                 tin = q->tin_index[cake_get_diffserv(skb)];
>>                 if (unlikely(tin >= q->tin_cnt))
>>                         tin = 0;
>>         } else {
>> -               cake_squash_diffserv(skb);
>>                 tin = 0;
>>         }
>>
>> +       /* now clear DSCP bits if squashing */
>> +       if (q->squash)
>> +               cake_squash_diffserv(skb);
>>
>>
>> https://github.com/dtaht/sch_cake/tree/squash  &  https://github.com/dtaht/tc-adv/tree/squash
>>
>> Needs testing (I've not managed to break it yet) and *thought before merging*
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]



On 16/11/15 15:03, Dave Taht wrote:
> I have not been doing any active development until... tomorrow.
>
> A goal I have for today is to actually build a version of openwrt +
> all this stuff for the linksys ac1200.
>
> I was not particularly huge on using another field (q->squash) to
> trigger squashing, and I cannot come up with a use case that makes
> sense to me.
>
> Under what circumstances do you think separating these two functions
> to be useful?

I wanted to be able to use diffserv marking for internal bandwidth
policing purposes whilst clearing those bits by the time they hit the
ISP.  On ingress it makes no sense, on egress I can see a use.




[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Sebastian Moeller]

Hi Dave,

On Nov 16, 2015, at 16:03 , Dave Taht <dave.taht@gmail.com> wrote:

> I have not been doing any active development until... tomorrow.
> 
> A goal I have for today is to actually build a version of openwrt +
> all this stuff for the linksys ac1200.
> 
> I was not particularly huge on using another field (q->squash) to
> trigger squashing, and I cannot come up with a use case that makes
> sense to me.
> 
> Under what circumstances do you think separating these two functions
> to be useful?

	Well, if I want to use DSCP values internally on my egress interface, but do not want to leak them out to my ISP. Totally contrived example, I might want to keep bit torrent at CS1/BK internally but do not want to make it easier for the ISP to differentially restrict my bit torrent traffic (I neither use bit torrent enough nor do know whether ISPs actually still throttle). More realistically it would be nice to separate the 6 DSCP bits into two groups of 3, one for sender intent and one for current network usage, and then copy the intent bits to the local bits on egress or remap local bits to zero, but I digress.
	And similarly on ingress I might want to use DSCP markings but remap them to zero on ingress so that no internal AP does the VO/VI/BE/BK qos thing on air (there are certainly better ways to assure such behavior).

Best Regards
	Sebastian

> 
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
> 
> 
> On Mon, Nov 16, 2015 at 3:59 PM, Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> wrote:
>> Does anyone have any feedback on this?  Good idea/bad idea?  Good/bad
>> implementation?
>> 
>> Any reason why 'squash' branches of both sch-cake & tc-adv shouldn't be
>> merged?
>> 
>> On 10/11/15 15:00, Kevin Darbyshire-Bryant wrote:
>>> Greetings :-)
>>> 
>>> A bit of a blast from the past this one, but one Sebastian Moeller of
>>> this list fame wrote a while ago "
>>> 
>>> Just played a bit with the shiny new squash option. For my limited testing it seems to work. I do wonder whether the automatic default to besteffort is the ideal behavior though. For example on egress it would be nice to be able to use the internal set DSCP markings but clean them from the outgoing packets as not to leak “information” to the ISP, similarly but more contrived the same could be agued for ingress  "
>>> 
>>> Well Mr Moeller, today is your lucky day because I've just pushed 'squash' branches to both cake & tc-adv that separate the 'DSCP squashing' behaviour from diffserv behaviour.  Specifying 'squash' sets diffserv mode to 'besteffort' (ie 1 tin only) and squashes DSCP as before, however if you specify something like 'diffserv4 squash' then DSCP codings are noted at qdisc enqueue so tins/bandwidths are used as marked, then the DSCP marking is squashed so on dequeue DSCP has been removed.
>>> 
>>> The active bit of the change is (diff):
>>> 
>>>        /* extract the Diffserv Precedence field, if it exists */
>>> -       if (q->tin_mode != CAKE_MODE_SQUASH) {
>>> +       if (q->tin_mode != CAKE_MODE_BESTEFFORT) {
>>>                tin = q->tin_index[cake_get_diffserv(skb)];
>>>                if (unlikely(tin >= q->tin_cnt))
>>>                        tin = 0;
>>>        } else {
>>> -               cake_squash_diffserv(skb);
>>>                tin = 0;
>>>        }
>>> 
>>> +       /* now clear DSCP bits if squashing */
>>> +       if (q->squash)
>>> +               cake_squash_diffserv(skb);
>>> 
>>> 
>>> https://github.com/dtaht/sch_cake/tree/squash  &  https://github.com/dtaht/tc-adv/tree/squash
>>> 
>>> Needs testing (I've not managed to break it yet) and *thought before merging*
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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 mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Dave Taht]

isn't there some other boolean variable somewhere ?

Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Mon, Nov 16, 2015 at 4:20 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
>
>
> On 16/11/15 15:03, Dave Taht wrote:
>> I have not been doing any active development until... tomorrow.
>>
>> A goal I have for today is to actually build a version of openwrt +
>> all this stuff for the linksys ac1200.
>>
>> I was not particularly huge on using another field (q->squash) to
>> trigger squashing, and I cannot come up with a use case that makes
>> sense to me.
>>
>> Under what circumstances do you think separating these two functions
>> to be useful?
>
> I wanted to be able to use diffserv marking for internal bandwidth
> policing purposes whilst clearing those bits by the time they hit the
> ISP.  On ingress it makes no sense, on egress I can see a use.
>
>
>

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]



On 16/11/15 15:57, Dave Taht wrote:
> isn't there some other boolean variable somewhere ?
>
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
>

Well there's something called 'rate_flags', currently enumerated:


enum {
        CAKE_FLAG_ATM = 0x0001,
        CAKE_FLAG_AUTORATE_INGRESS = 0x0010
};

I could add 'CAKE_FLAG_SQUASH = 0x0100' or even '0x0020' - I don't know
why the gap between ATM and AUTORATE_INGRESS.

When I created 'squash' I did at least reduce the size of tin_cnt so I
didn't screw up the alignment (or change the size of the structure)  I'm
learning, slowly.  Also (and this is ancient) my previous assembler
knowledge is that checking a byte for non zero is quicker than checking
a bit in a byte, so that probably erroneously biased me toward a byte
rather than a bit  :-)


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

Does this
https://github.com/dtaht/sch_cake/commit/d05cf7e003d9c13d8382c881655807bda7ab3616
improve your happiness factor?

Kevin

On 16/11/15 15:57, Dave Taht wrote:
> isn't there some other boolean variable somewhere ?
>
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
>
>
> On Mon, Nov 16, 2015 at 4:20 PM, Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> wrote:
>>
>> On 16/11/15 15:03, Dave Taht wrote:
>>> I have not been doing any active development until... tomorrow.
>>>
>>> A goal I have for today is to actually build a version of openwrt +
>>> all this stuff for the linksys ac1200.
>>>
>>> I was not particularly huge on using another field (q->squash) to
>>> trigger squashing, and I cannot come up with a use case that makes
>>> sense to me.
>>>
>>> Under what circumstances do you think separating these two functions
>>> to be useful?
>> I wanted to be able to use diffserv marking for internal bandwidth
>> policing purposes whilst clearing those bits by the time they hit the
>> ISP.  On ingress it makes no sense, on egress I can see a use.
>>
>>
>>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Dave Taht]

yes and nooo..... I thought tin_cnt needed to be a 10 bit number at
least.... (did it become an 8 bitter somewhere?)


but I have not looked at the code in quite some time. Tomorrow I hope
to finally have a fresh head.

Right now I'm merely wrestling with getting a build to complete.
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Mon, Nov 16, 2015 at 6:47 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
> Does this
> https://github.com/dtaht/sch_cake/commit/d05cf7e003d9c13d8382c881655807bda7ab3616
> improve your happiness factor?
>
> Kevin
>
> On 16/11/15 15:57, Dave Taht wrote:
>> isn't there some other boolean variable somewhere ?
>>
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> https://www.gofundme.com/savewifi
>>
>>
>> On Mon, Nov 16, 2015 at 4:20 PM, Kevin Darbyshire-Bryant
>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>
>>> On 16/11/15 15:03, Dave Taht wrote:
>>>> I have not been doing any active development until... tomorrow.
>>>>
>>>> A goal I have for today is to actually build a version of openwrt +
>>>> all this stuff for the linksys ac1200.
>>>>
>>>> I was not particularly huge on using another field (q->squash) to
>>>> trigger squashing, and I cannot come up with a use case that makes
>>>> sense to me.
>>>>
>>>> Under what circumstances do you think separating these two functions
>>>> to be useful?
>>> I wanted to be able to use diffserv marking for internal bandwidth
>>> policing purposes whilst clearing those bits by the time they hit the
>>> ISP.  On ingress it makes no sense, on egress I can see a use.
>>>
>>>
>>>
>
>

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

tin_cnt *is* u16, in fact struct cake_sched_data has been restored to
the same state as it was before I introduced 'u8 squash'.

On 16/11/15 17:59, Dave Taht wrote:
> yes and nooo..... I thought tin_cnt needed to be a 10 bit number at
> least.... (did it become an 8 bitter somewhere?)
>
>
> but I have not looked at the code in quite some time. Tomorrow I hope
> to finally have a fresh head.
>
> Right now I'm merely wrestling with getting a build to complete.
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
>
>
> On Mon, Nov 16, 2015 at 6:47 PM, Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> wrote:
>> Does this
>> https://github.com/dtaht/sch_cake/commit/d05cf7e003d9c13d8382c881655807bda7ab3616
>> improve your happiness factor?
>>
>> Kevin
>>
>> On 16/11/15 15:57, Dave Taht wrote:
>>> isn't there some other boolean variable somewhere ?
>>>
>>> Dave Täht
>>> Let's go make home routers and wifi faster! With better software!
>>> https://www.gofundme.com/savewifi
>>>
>>>
>>> On Mon, Nov 16, 2015 at 4:20 PM, Kevin Darbyshire-Bryant
>>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>> On 16/11/15 15:03, Dave Taht wrote:
>>>>> I have not been doing any active development until... tomorrow.
>>>>>
>>>>> A goal I have for today is to actually build a version of openwrt +
>>>>> all this stuff for the linksys ac1200.
>>>>>
>>>>> I was not particularly huge on using another field (q->squash) to
>>>>> trigger squashing, and I cannot come up with a use case that makes
>>>>> sense to me.
>>>>>
>>>>> Under what circumstances do you think separating these two functions
>>>>> to be useful?
>>>> I wanted to be able to use diffserv marking for internal bandwidth
>>>> policing purposes whilst clearing those bits by the time they hit the
>>>> ISP.  On ingress it makes no sense, on egress I can see a use.
>>>>
>>>>
>>>>
>>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Dave Taht]

I grok...

short rate_overhead;// kind of stands out. s16 is the equivalent....

so the intent here is to have the rate flags get twiddled by userspace
to enable squashing
separately? one "feature" of squashing the old way was we did not need
to allocate more than
one tin...
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Mon, Nov 16, 2015 at 7:11 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
> tin_cnt *is* u16, in fact struct cake_sched_data has been restored to
> the same state as it was before I introduced 'u8 squash'.
>
> On 16/11/15 17:59, Dave Taht wrote:
>> yes and nooo..... I thought tin_cnt needed to be a 10 bit number at
>> least.... (did it become an 8 bitter somewhere?)
>>
>>
>> but I have not looked at the code in quite some time. Tomorrow I hope
>> to finally have a fresh head.
>>
>> Right now I'm merely wrestling with getting a build to complete.
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> https://www.gofundme.com/savewifi
>>
>>
>> On Mon, Nov 16, 2015 at 6:47 PM, Kevin Darbyshire-Bryant
>> <kevin@darbyshire-bryant.me.uk> wrote:
>>> Does this
>>> https://github.com/dtaht/sch_cake/commit/d05cf7e003d9c13d8382c881655807bda7ab3616
>>> improve your happiness factor?
>>>
>>> Kevin
>>>
>>> On 16/11/15 15:57, Dave Taht wrote:
>>>> isn't there some other boolean variable somewhere ?
>>>>
>>>> Dave Täht
>>>> Let's go make home routers and wifi faster! With better software!
>>>> https://www.gofundme.com/savewifi
>>>>
>>>>
>>>> On Mon, Nov 16, 2015 at 4:20 PM, Kevin Darbyshire-Bryant
>>>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>>> On 16/11/15 15:03, Dave Taht wrote:
>>>>>> I have not been doing any active development until... tomorrow.
>>>>>>
>>>>>> A goal I have for today is to actually build a version of openwrt +
>>>>>> all this stuff for the linksys ac1200.
>>>>>>
>>>>>> I was not particularly huge on using another field (q->squash) to
>>>>>> trigger squashing, and I cannot come up with a use case that makes
>>>>>> sense to me.
>>>>>>
>>>>>> Under what circumstances do you think separating these two functions
>>>>>> to be useful?
>>>>> I wanted to be able to use diffserv marking for internal bandwidth
>>>>> policing purposes whilst clearing those bits by the time they hit the
>>>>> ISP.  On ingress it makes no sense, on egress I can see a use.
>>>>>
>>>>>
>>>>>
>>>
>
>

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Sebastian Moeller]

Hi Dave,


On Nov 16, 2015, at 19:25 , Dave Taht <dave.taht@gmail.com> wrote:

> I grok...
> 
> short rate_overhead;// kind of stands out. s16 is the equivalent....
> 
> so the intent here is to have the rate flags get twiddled by userspace
> to enable squashing
> separately? one "feature" of squashing the old way was we did not need
> to allocate more than
> one tin…

	But you still do not need to squash, I believe defaults to the besteffort 1tin setup, only if the user requests "squash diffserv4" or so she will get what she asked for ;). While I have not tested that, I believe that is how Kevin explained it, and this looks in line with cake’s (extended) rationale of making the defaults sane and efficient (and the crazy possible ;) not sure whether there is consensus yet on this extension…)
 

Best Regards
	Sebastian

> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
> 
> 
> On Mon, Nov 16, 2015 at 7:11 PM, Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> wrote:
>> tin_cnt *is* u16, in fact struct cake_sched_data has been restored to
>> the same state as it was before I introduced 'u8 squash'.
>> 
>> On 16/11/15 17:59, Dave Taht wrote:
>>> yes and nooo..... I thought tin_cnt needed to be a 10 bit number at
>>> least.... (did it become an 8 bitter somewhere?)
>>> 
>>> 
>>> but I have not looked at the code in quite some time. Tomorrow I hope
>>> to finally have a fresh head.
>>> 
>>> Right now I'm merely wrestling with getting a build to complete.
>>> Dave Täht
>>> Let's go make home routers and wifi faster! With better software!
>>> https://www.gofundme.com/savewifi
>>> 
>>> 
>>> On Mon, Nov 16, 2015 at 6:47 PM, Kevin Darbyshire-Bryant
>>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>> Does this
>>>> https://github.com/dtaht/sch_cake/commit/d05cf7e003d9c13d8382c881655807bda7ab3616
>>>> improve your happiness factor?
>>>> 
>>>> Kevin
>>>> 
>>>> On 16/11/15 15:57, Dave Taht wrote:
>>>>> isn't there some other boolean variable somewhere ?
>>>>> 
>>>>> Dave Täht
>>>>> Let's go make home routers and wifi faster! With better software!
>>>>> https://www.gofundme.com/savewifi
>>>>> 
>>>>> 
>>>>> On Mon, Nov 16, 2015 at 4:20 PM, Kevin Darbyshire-Bryant
>>>>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>>>> On 16/11/15 15:03, Dave Taht wrote:
>>>>>>> I have not been doing any active development until... tomorrow.
>>>>>>> 
>>>>>>> A goal I have for today is to actually build a version of openwrt +
>>>>>>> all this stuff for the linksys ac1200.
>>>>>>> 
>>>>>>> I was not particularly huge on using another field (q->squash) to
>>>>>>> trigger squashing, and I cannot come up with a use case that makes
>>>>>>> sense to me.
>>>>>>> 
>>>>>>> Under what circumstances do you think separating these two functions
>>>>>>> to be useful?
>>>>>> I wanted to be able to use diffserv marking for internal bandwidth
>>>>>> policing purposes whilst clearing those bits by the time they hit the
>>>>>> ISP.  On ingress it makes no sense, on egress I can see a use.
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>> 
>> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Dave Taht]

switch (q->tin_mode) { case CAKE_MODE_SQUASH: case
CAKE_MODE_BESTEFFORT: default: cake_config_besteffort(sch); break;

?
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Mon, Nov 16, 2015 at 7:32 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
>
> On Nov 16, 2015, at 19:25 , Dave Taht <dave.taht@gmail.com> wrote:
>
>> I grok...
>>
>> short rate_overhead;// kind of stands out. s16 is the equivalent....
>>
>> so the intent here is to have the rate flags get twiddled by userspace
>> to enable squashing
>> separately? one "feature" of squashing the old way was we did not need
>> to allocate more than
>> one tin…
>
>         But you still do not need to squash, I believe defaults to the besteffort 1tin setup, only if the user requests "squash diffserv4" or so she will get what she asked for ;). While I have not tested that, I believe that is how Kevin explained it, and this looks in line with cake’s (extended) rationale of making the defaults sane and efficient (and the crazy possible ;) not sure whether there is consensus yet on this extension…)
>
>
> Best Regards
>         Sebastian
>
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> https://www.gofundme.com/savewifi
>>
>>
>> On Mon, Nov 16, 2015 at 7:11 PM, Kevin Darbyshire-Bryant
>> <kevin@darbyshire-bryant.me.uk> wrote:
>>> tin_cnt *is* u16, in fact struct cake_sched_data has been restored to
>>> the same state as it was before I introduced 'u8 squash'.
>>>
>>> On 16/11/15 17:59, Dave Taht wrote:
>>>> yes and nooo..... I thought tin_cnt needed to be a 10 bit number at
>>>> least.... (did it become an 8 bitter somewhere?)
>>>>
>>>>
>>>> but I have not looked at the code in quite some time. Tomorrow I hope
>>>> to finally have a fresh head.
>>>>
>>>> Right now I'm merely wrestling with getting a build to complete.
>>>> Dave Täht
>>>> Let's go make home routers and wifi faster! With better software!
>>>> https://www.gofundme.com/savewifi
>>>>
>>>>
>>>> On Mon, Nov 16, 2015 at 6:47 PM, Kevin Darbyshire-Bryant
>>>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>>> Does this
>>>>> https://github.com/dtaht/sch_cake/commit/d05cf7e003d9c13d8382c881655807bda7ab3616
>>>>> improve your happiness factor?
>>>>>
>>>>> Kevin
>>>>>
>>>>> On 16/11/15 15:57, Dave Taht wrote:
>>>>>> isn't there some other boolean variable somewhere ?
>>>>>>
>>>>>> Dave Täht
>>>>>> Let's go make home routers and wifi faster! With better software!
>>>>>> https://www.gofundme.com/savewifi
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 16, 2015 at 4:20 PM, Kevin Darbyshire-Bryant
>>>>>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>>>>> On 16/11/15 15:03, Dave Taht wrote:
>>>>>>>> I have not been doing any active development until... tomorrow.
>>>>>>>>
>>>>>>>> A goal I have for today is to actually build a version of openwrt +
>>>>>>>> all this stuff for the linksys ac1200.
>>>>>>>>
>>>>>>>> I was not particularly huge on using another field (q->squash) to
>>>>>>>> trigger squashing, and I cannot come up with a use case that makes
>>>>>>>> sense to me.
>>>>>>>>
>>>>>>>> Under what circumstances do you think separating these two functions
>>>>>>>> to be useful?
>>>>>>> I wanted to be able to use diffserv marking for internal bandwidth
>>>>>>> policing purposes whilst clearing those bits by the time they hit the
>>>>>>> ISP.  On ingress it makes no sense, on egress I can see a use.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]



On 16/11/15 18:35, Dave Taht wrote:
> switch (q->tin_mode) { case CAKE_MODE_SQUASH: case
> CAKE_MODE_BESTEFFORT: default: cake_config_besteffort(sch); break;
>
> ?
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
>

Are you sure you're looking at the 'squash' branch Dave?  The 'smarts'
of automatically selecting 'besteffort' in the presence of 'squash' has
been put into 'tc'.  Thus 'squash' on its own behaves as it always did
for backwards compatibility.  'squash' in combination with
'diffserv4/precedence' etc also works as expected.

There's also a 'nosquash' option to disable squashing on a 'tc change'
if required.  That code now looks like:

        switch (q->tin_mode) {
        case CAKE_MODE_BESTEFFORT:
        default:
                cake_config_besteffort(sch);
                break;
........







[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Dave Taht]

push it then.
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Mon, Nov 16, 2015 at 7:43 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
>
>
> On 16/11/15 18:35, Dave Taht wrote:
>> switch (q->tin_mode) { case CAKE_MODE_SQUASH: case
>> CAKE_MODE_BESTEFFORT: default: cake_config_besteffort(sch); break;
>>
>> ?
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> https://www.gofundme.com/savewifi
>>
>
> Are you sure you're looking at the 'squash' branch Dave?  The 'smarts'
> of automatically selecting 'besteffort' in the presence of 'squash' has
> been put into 'tc'.  Thus 'squash' on its own behaves as it always did
> for backwards compatibility.  'squash' in combination with
> 'diffserv4/precedence' etc also works as expected.
>
> There's also a 'nosquash' option to disable squashing on a 'tc change'
> if required.  That code now looks like:
>
>         switch (q->tin_mode) {
>         case CAKE_MODE_BESTEFFORT:
>         default:
>                 cake_config_besteffort(sch);
>                 break;
> ........
>
>
>
>
>
>

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

It is pushed but in a 'squash' branch for review purposes before it gets
merged into master.

Let me ask things in a different way, and as I've had time to think
about the implications of these changes:  By changing how 'squash' is
enabled I've currently broken backwards compatibility between 'new
squash' cake and 'old squash' tc.  Now, bearing in mind that this isn't
upstream yet...how concerned are we/should I be for 'new cake' vs 'old
tc' compatibility?  Again having thought about it more, I'm pretty sure
I can make 'new cake' and 'old tc' work....is it worth the bother?

Kevin

On 16/11/15 18:47, Dave Taht wrote:
> push it then.
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> https://www.gofundme.com/savewifi
>
>
> On Mon, Nov 16, 2015 at 7:43 PM, Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> wrote:
>>
>> On 16/11/15 18:35, Dave Taht wrote:
>>> switch (q->tin_mode) { case CAKE_MODE_SQUASH: case
>>> CAKE_MODE_BESTEFFORT: default: cake_config_besteffort(sch); break;
>>>
>>> ?
>>> Dave Täht
>>> Let's go make home routers and wifi faster! With better software!
>>> https://www.gofundme.com/savewifi
>>>
>> Are you sure you're looking at the 'squash' branch Dave?  The 'smarts'
>> of automatically selecting 'besteffort' in the presence of 'squash' has
>> been put into 'tc'.  Thus 'squash' on its own behaves as it always did
>> for backwards compatibility.  'squash' in combination with
>> 'diffserv4/precedence' etc also works as expected.
>>
>> There's also a 'nosquash' option to disable squashing on a 'tc change'
>> if required.  That code now looks like:
>>
>>         switch (q->tin_mode) {
>>         case CAKE_MODE_BESTEFFORT:
>>         default:
>>                 cake_config_besteffort(sch);
>>                 break;
>> ........
>>
>>
>>
>>
>>
>>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Dave Taht]

we can break anything until it goes upstream. I'm not satisified with
the api (or wasn't 2 months back)....
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Mon, Nov 16, 2015 at 9:09 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
> It is pushed but in a 'squash' branch for review purposes before it gets
> merged into master.
>
> Let me ask things in a different way, and as I've had time to think
> about the implications of these changes:  By changing how 'squash' is
> enabled I've currently broken backwards compatibility between 'new
> squash' cake and 'old squash' tc.  Now, bearing in mind that this isn't
> upstream yet...how concerned are we/should I be for 'new cake' vs 'old
> tc' compatibility?  Again having thought about it more, I'm pretty sure
> I can make 'new cake' and 'old tc' work....is it worth the bother?
>
> Kevin
>
> On 16/11/15 18:47, Dave Taht wrote:
>> push it then.
>> Dave Täht
>> Let's go make home routers and wifi faster! With better software!
>> https://www.gofundme.com/savewifi
>>
>>
>> On Mon, Nov 16, 2015 at 7:43 PM, Kevin Darbyshire-Bryant
>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>
>>> On 16/11/15 18:35, Dave Taht wrote:
>>>> switch (q->tin_mode) { case CAKE_MODE_SQUASH: case
>>>> CAKE_MODE_BESTEFFORT: default: cake_config_besteffort(sch); break;
>>>>
>>>> ?
>>>> Dave Täht
>>>> Let's go make home routers and wifi faster! With better software!
>>>> https://www.gofundme.com/savewifi
>>>>
>>> Are you sure you're looking at the 'squash' branch Dave?  The 'smarts'
>>> of automatically selecting 'besteffort' in the presence of 'squash' has
>>> been put into 'tc'.  Thus 'squash' on its own behaves as it always did
>>> for backwards compatibility.  'squash' in combination with
>>> 'diffserv4/precedence' etc also works as expected.
>>>
>>> There's also a 'nosquash' option to disable squashing on a 'tc change'
>>> if required.  That code now looks like:
>>>
>>>         switch (q->tin_mode) {
>>>         case CAKE_MODE_BESTEFFORT:
>>>         default:
>>>                 cake_config_besteffort(sch);
>>>                 break;
>>> ........
>>>
>>>
>>>
>>>
>>>
>>>
>
>

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]



On 17/11/15 10:12, Dave Taht wrote:
> we can break anything until it goes upstream. I'm not satisified with
> the api (or wasn't 2 months back)....

Could you elucidate on what is wrong with the API?  My understanding of
the present code is that additional options can be transferred between
kernel space & user space (tc) with 'ease' via the netlink API.  Indeed
the 'squash' enable/disable option is passed as a new option via this
API.  Also look at how easy the recently implented rtt, target & memory
options were to introduce without backward/forward compatibility issues.

Where it falls down is where one passed option is used to control more
than one thing - that's not an API thing really, it's how we use the
API. For example and in my opinion, squash should not have been passed
as a 'diffserv mode' as this limits how combinations of diffserv mode &
squash may be implemented.  That's precisely why I took the step to
split out the diffserv mode and squash mode (like for example 'atm'
compensation or not)  Because 'squash' was previously regarded as a
diffserv mode it does cause a compatibility issue (it won't blow up, but
it may not go into quite the mode expected, or the reporting of mode via
tc may not quite match'

Personally, i'd say break it now while we can and get what I consider a
better implementation out there.  I'm not the only person out here, on
this list, I may be wrong.







[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]



On 18/11/15 11:57, Toke Høiland-Jørgensen wrote:
> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
>
>> The jury hasn't even been assembled, let alone sat as to whether these
>> (potentially) increasing targets/intervals on 'slow' links is a good
>> thing(tm) or not.
> I think I was leaning towards 'no' last time around on this.
That may be, and my gut & head goes with 'no' as well.  Unfortunately I
failed spectacularly to produce a suitable test.  Also I got somewhat
fed up with recompiling, flashing, rebooting, copying modules with
different tweaks in them, testing again, forgetting where I was etc
etc.  To that end I'm working on a way to pass 'copy target', 'copy
interval' etc type flags so that with a simple tc command I can turn the
copying of parameters from tin[0] across...or not.

The task of producing a suitable test will still remain!


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Toke Høiland-Jørgensen]

Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:

> The jury hasn't even been assembled, let alone sat as to whether these
> (potentially) increasing targets/intervals on 'slow' links is a good
> thing(tm) or not.

I think I was leaning towards 'no' last time around on this.

>> memory used: 612600b of 15140Kb # not huge on parsing this
>> capacity estimate: 724522Kbit # not huge on parsing this
>
> That's a function of the sprint_size(), sprint_time(), sprint_rate()
> (and matching get_*() ) helpers provided by tc.  Similar 'playing with'
> units can be seen in the threshold values for each tin.  A 'classic'
> example demonstrating both A) and unit playing:

I think we should prioritise human readability in tc output. If we want
to have a mode that is easy to parse, make it a separate one (was
looking for a 'machine-readable' switch to tc, but there doesn't seem to
be one).

Would it be viable to get a patch into iproute that makes it sprout csv
or json, do you think?

Besides, as far as being a pain to parse, the 'tin table' is way worse,
as far as I'm concerned.

-Toke

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 3616 bytes --]



On 17/11/15 19:05, Dave Taht wrote:
> I have had about .01% braincells on cake for 2 months, and only
> causually was reading the list. It is my hope that this time - as the
> test results are looking quite good - we can at least get an RFC patch
> upstream for further review.
>
> A) One big debate I remember going by was about accuracy of various
> settings, where one value would be weirdly rounded to another when
> read back.
Can, opener, worms all over the place!  I suspect you're referring to
tin target values (and intervals) drifting away from the defaults of
5ms/100ms.  This is because cake_set_rate() calculates how long a
MTU*1.5 packet will take to send and if it's longer than the supplied
target value it'll use the calculated value instead.  Interval is sanity
checked to be at least 'used_target' * 8.  This is most obviously
observed in a rate specified & diffserv config where tin++ gets reduced
bandwidth (reduced rate) so the likelihood of MTU*1.5 duration exceeding
specified target increases.  This looks like weird rounding.  The jury
hasn't even been assembled, let alone sat as to whether these
(potentially) increasing targets/intervals on 'slow' links is a good
thing(tm) or not.

> I do not have a problem with a pure 64 bit interface between userspace
> and kernelspace, if that will alleviate the problems. The cost of
> doing that, now, is trivial.
Again, I think what you're seeing/thinking of is evidence of an internal
calculation process rather than insufficient bits between kernel/user
space.  Although it does only speak in microsecond (not millisecond or
nanosecond) resolution.
> Try to cast yourself into a future - 20 years ahead - with a 10240
> cpus embedded in your head,  when the onboard network-to-brain
> interfaces have 8ns latency each, and think upon how someone would
> curse us for not having forbearance enough to understand how much
> different the brain-cell dscp had to be to get multicast to all the
> neurons.... (or something like that. :))
>
> Another way to help spur visualization like that, is think 20 years
> past - to 1995 - and where networking stood then.
>
> B) Also, I think, but am not sure, that most parsers of tc -s qdisc
> output will break unless the root of the qdisc has 0 indentation and
> the rest, at least 2.
>
> C) And I kind of expect netdev to want all those stats in some sysfs
> thing rather than tc, but will defer to stephen/jesper - guys, will
> this sort of tc output go upstream?
>
> d@snapon:~/git/tc-adv/tc$ ./tc -s qdisc show dev eno1
> qdisc cake 8002: root refcnt 2 unlimited diffserv4 flows rtt 100.0ms raw
>  Sent 6079713916 bytes 5489146 pkt (dropped 0, overlimits 0 requeues 28656)
>  backlog 0b 0p requeues 28656
> memory used: 612600b of 15140Kb # not huge on parsing this
> capacity estimate: 724522Kbit # not huge on parsing this

That's a function of the sprint_size(), sprint_time(), sprint_rate()
(and matching get_*() ) helpers provided by tc.  Similar 'playing with'
units can be seen in the threshold values for each tin.  A 'classic'
example demonstrating both A) and unit playing:

qdisc cake 8005: dev eth0 root refcnt 6 bandwidth 1Mbit diffserv4 flows rtt 100.0ms raw 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
capacity estimate: 1Mbit
             Tin 0       Tin 1       Tin 2       Tin 3  
  thresh       1Mbit   937504bit     750Kbit     250Kbit  <-tin 1
  target      18.2ms      19.4ms      24.2ms      72.7ms
interval     145.3ms     155.0ms     193.8ms     581.4ms





[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4816 bytes --]

Re: [Cake] Announce - possible new feature - DSCP cleaning

[Dave Taht]

I have had about .01% braincells on cake for 2 months, and only
causually was reading the list. It is my hope that this time - as the
test results are looking quite good - we can at least get an RFC patch
upstream for further review.

A) One big debate I remember going by was about accuracy of various
settings, where one value would be weirdly rounded to another when
read back.

I do not have a problem with a pure 64 bit interface between userspace
and kernelspace, if that will alleviate the problems. The cost of
doing that, now, is trivial.

Try to cast yourself into a future - 20 years ahead - with a 10240
cpus embedded in your head,  when the onboard network-to-brain
interfaces have 8ns latency each, and think upon how someone would
curse us for not having forbearance enough to understand how much
different the brain-cell dscp had to be to get multicast to all the
neurons.... (or something like that. :))

Another way to help spur visualization like that, is think 20 years
past - to 1995 - and where networking stood then.

B) Also, I think, but am not sure, that most parsers of tc -s qdisc
output will break unless the root of the qdisc has 0 indentation and
the rest, at least 2.

C) And I kind of expect netdev to want all those stats in some sysfs
thing rather than tc, but will defer to stephen/jesper - guys, will
this sort of tc output go upstream?

d@snapon:~/git/tc-adv/tc$ ./tc -s qdisc show dev eno1
qdisc cake 8002: root refcnt 2 unlimited diffserv4 flows rtt 100.0ms raw
 Sent 6079713916 bytes 5489146 pkt (dropped 0, overlimits 0 requeues 28656)
 backlog 0b 0p requeues 28656
memory used: 612600b of 15140Kb # not huge on parsing this
capacity estimate: 724522Kbit # not huge on parsing this
             Tin 0       Tin 1       Tin 2       Tin 3
  thresh        0bit        0bit        0bit        0bit
  target       5.0ms       5.0ms       5.0ms       5.0ms
interval     100.0ms     100.0ms     100.0ms     100.0ms
Pk-delay       4.6ms       924us         0us       1.1ms
Av-delay       1.2ms       598us         0us       454us
Sp-delay       312us         0us         0us       179us
  pkts         43938      104843           0      468916
  bytes     63945533   154488126           0   708247426
way-inds           0           2           0         333
way-miss           6         528           0          10
way-cols           0           0           0           0
  drops            0           0           0           0
  marks           17           2           0           0
Sp-flows           0           1           0           0
Bk-flows           1          13           0           1
last-len       28766          66           0       68130
max-len        68130       68130           0       68130






On Tue, Nov 17, 2015 at 7:52 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
>
>
> On 17/11/15 10:12, Dave Taht wrote:
>> we can break anything until it goes upstream. I'm not satisified with
>> the api (or wasn't 2 months back)....
>
> Could you elucidate on what is wrong with the API?  My understanding of
> the present code is that additional options can be transferred between
> kernel space & user space (tc) with 'ease' via the netlink API.  Indeed
> the 'squash' enable/disable option is passed as a new option via this
> API.  Also look at how easy the recently implented rtt, target & memory
> options were to introduce without backward/forward compatibility issues.
>
> Where it falls down is where one passed option is used to control more
> than one thing - that's not an API thing really, it's how we use the
> API. For example and in my opinion, squash should not have been passed
> as a 'diffserv mode' as this limits how combinations of diffserv mode &
> squash may be implemented.  That's precisely why I took the step to
> split out the diffserv mode and squash mode (like for example 'atm'
> compensation or not)  Because 'squash' was previously regarded as a
> diffserv mode it does cause a compatibility issue (it won't blow up, but
> it may not go into quite the mode expected, or the reporting of mode via
> tc may not quite match'
>
> Personally, i'd say break it now while we can and get what I consider a
> better implementation out there.  I'm not the only person out here, on
> this list, I may be wrong.
>
>
>
>
>
>