> On 4 Mar 2019, at 21:33, Toke Høiland-Jørgensen wrote:
>> I think so too though I think the mechanism of copying the DSCP bits
>> and adding a ‘I did this’ flag bit should be retained so that other
>> user space tools (iptables etc) can detect when a connmark based DSCP
>> has been
Toke Høiland-Jørgensen writes:
> Kevin Darbyshire-Bryant writes:
>
>>> On 4 Mar 2019, at 17:36, Toke Høiland-Jørgensen wrote:
>>> < snips >
>>>
>>> Or act_dscp with 'get' and 'set' options :)
>>>
As I said earlier I couldn't work out how m_conntrack did… anything at
all to be
Kevin Darbyshire-Bryant writes:
>> On 4 Mar 2019, at 17:36, Toke Høiland-Jørgensen wrote:
>> < snips >
>>
>> Or act_dscp with 'get' and 'set' options :)
>>
>>> As I said earlier I couldn't work out how m_conntrack did… anything at
>>> all to be honest!
>>
>> act_connmark is pretty straight
> On 4 Mar 2019, at 17:36, Toke Høiland-Jørgensen wrote:
> < snips >
>
> Or act_dscp with 'get' and 'set' options :)
>
>> As I said earlier I couldn't work out how m_conntrack did… anything at
>> all to be honest!
>
> act_connmark is pretty straight forward:
>
Kevin Darbyshire-Bryant writes:
>> On 4 Mar 2019, at 16:39, Toke Høiland-Jørgensen wrote:
>>
>> Kevin Darbyshire-Bryant writes:
>>
>> [ ... snipping a bit of context here ... ]
>>
>>> +void cake_update_ct_mark(struct sk_buff *skb, u8 dscp)
>>> +{
>>> + enum
> On 4 Mar 2019, at 16:39, Toke Høiland-Jørgensen wrote:
>
> Kevin Darbyshire-Bryant writes:
>
> [ ... snipping a bit of context here ... ]
>
>> +void cake_update_ct_mark(struct sk_buff *skb, u8 dscp)
>> +{
>> +enum ip_conntrack_info ctinfo;
>> +struct
Kevin Darbyshire-Bryant writes:
[ ... snipping a bit of context here ... ]
> +void cake_update_ct_mark(struct sk_buff *skb, u8 dscp)
> +{
> + enum ip_conntrack_info ctinfo;
> + struct nf_conn *ct;
> +
> + ct = nf_ct_get(skb, );
> + if (!ct)
> + return;
> On 4 Mar 2019, at 12:44, Toke Høiland-Jørgensen wrote:
>
> Kevin Darbyshire-Bryant writes:
>
>>> On 4 Mar 2019, at 11:17, Toke Høiland-Jørgensen wrote:
>>>
>>> Kevin Darbyshire-Bryant writes:
>>>
> On 4 Mar 2019, at 08:39, Pete Heist wrote:
>
>
>> On Mar 3, 2019, at
Kevin Darbyshire-Bryant writes:
>> On 4 Mar 2019, at 11:17, Toke Høiland-Jørgensen wrote:
>>
>> Kevin Darbyshire-Bryant writes:
>>
On 4 Mar 2019, at 08:39, Pete Heist wrote:
> On Mar 3, 2019, at 12:52 PM, Kevin Darbyshire-Bryant
> wrote:
>
> The very bad
> On 4 Mar 2019, at 11:17, Toke Høiland-Jørgensen wrote:
>
> Kevin Darbyshire-Bryant writes:
>
>>> On 4 Mar 2019, at 08:39, Pete Heist wrote:
>>>
>>>
On Mar 3, 2019, at 12:52 PM, Kevin Darbyshire-Bryant
wrote:
The very bad idea:
And it’s bad ‘cos it’s
Let action connmark continue to do that. You still need mirred anyway.
John
On 4 March 2019 11:04:39 GMT, "Toke Høiland-Jørgensen" wrote:
>Kevin Darbyshire-Bryant writes:
>
>>> On 3 Mar 2019, at 12:22, John Sager wrote:
>>>
>>> If you are going to do that, I would suggest using a few of the
Kevin Darbyshire-Bryant writes:
>> On 4 Mar 2019, at 08:39, Pete Heist wrote:
>>
>>
>>> On Mar 3, 2019, at 12:52 PM, Kevin Darbyshire-Bryant
>>> wrote:
>>>
>>> The very bad idea:
>>>
>>> And it’s bad ‘cos it’s sort of incompatible with the existing fwmark
>>> implementation as described
Kevin Darbyshire-Bryant writes:
>> On 3 Mar 2019, at 12:22, John Sager wrote:
>>
>> If you are going to do that, I would suggest using a few of the upper bits
>> of the 32-bit fwmark/connmark space available, rather than the lowest bits.
>> Then that would allow to use fwmarks other purposes,
> On 4 Mar 2019, at 08:39, Pete Heist wrote:
>
>
>> On Mar 3, 2019, at 12:52 PM, Kevin Darbyshire-Bryant
>> wrote:
>>
>> The very bad idea:
>>
>> And it’s bad ‘cos it’s sort of incompatible with the existing fwmark
>> implementation as described above. So an awful lot of our shenanigans
> On Mar 3, 2019, at 12:52 PM, Kevin Darbyshire-Bryant
> wrote:
>
> The very bad idea:
>
> And it’s bad ‘cos it’s sort of incompatible with the existing fwmark
> implementation as described above. So an awful lot of our shenanigans above
> is due to DSCP not traversing the internet
On Sun, Mar 3, 2019 at 10:37 PM Ryan Mounce wrote:
>
> On Mon, 4 Mar 2019 at 17:01, Jonathan Morton wrote:
> > …icing?
>
> Perfect! And to me, this functionality truly is the icing on (the)
> cake that makes it the complete bufferbloat/QoS system I've been
> dreaming of for ingress.
>
On Mon, 4 Mar 2019 at 17:01, Jonathan Morton wrote:
> …icing?
Perfect! And to me, this functionality truly is the icing on (the)
cake that makes it the complete bufferbloat/QoS system I've been
dreaming of for ingress.
___
Cake mailing list
> On 4 Mar, 2019, at 7:37 am, Ryan Mounce wrote:
>
> The overwriting of the DSCP bits from fwmark could be called
> 'staining', as opposed to DSCP 'bleaching'. But this doesn't sound
> very appealing when we're baking delicious CAKE - we're in the kitchen
> not the laundry! So how about dyeing,
On Sun, 3 Mar 2019 at 22:22, Kevin Darbyshire-Bryant
wrote:
>
> Be afraid, be very afraid.
>
> I’ve woken up with two ideas in my head, one is bad, the other is very bad.
> The bad one is already implemented and lurking in the mine branch of my cake
> git tree:
>
> The bad idea:
>
> An
> On 3 Mar 2019, at 12:22, John Sager wrote:
>
> If you are going to do that, I would suggest using a few of the upper bits
> of the 32-bit fwmark/connmark space available, rather than the lowest bits.
> Then that would allow to use fwmarks other purposes, and to use the lowest
> bits, as well
Kevin Darbyshire-Bryant writes:
>> On 28 Feb 2019, at 09:54, Toke Høiland-Jørgensen wrote:
>>
>>> I also equally aware that this is ‘creeping featuritis’ and doing
>>> nothing to speed cake up…
>>
>> Yeah, this is the crux of the issue, really: it's a tradeoff between
>> ease of use and
> On 28 Feb 2019, at 09:54, Toke Høiland-Jørgensen wrote:
>
>> I also equally aware that this is ‘creeping featuritis’ and doing
>> nothing to speed cake up…
>
> Yeah, this is the crux of the issue, really: it's a tradeoff between
> ease of use and featuritis. Now in this case the actual
> I also equally aware that this is ‘creeping featuritis’ and doing
> nothing to speed cake up…
Yeah, this is the crux of the issue, really: it's a tradeoff between
ease of use and featuritis. Now in this case the actual impact is a
single check it might actually be acceptable
> actually I may
> On 27 Feb 2019, at 15:14, Toke Høiland-Jørgensen wrote:
>
> Kevin Darbyshire-Bryant writes:
>
>> How unpopular would the idea of having cake look at skb->mark directly be?
>>
>> https://github.com/ldir-EDB0/sch_cake/commit/64d0e6ac9368a271221db888ab91a367fcd37ae1
>>
>>
I think it's much simpler to use than tc-filter, BPF or even DSCP bits.
Manipulating DSCP bits seems the simplest of the currently available mechanisms
to classify traffic. Even in this case, fwmarks are essentially simpler.
E.g. if you want to classify outgoing traffic on the LAN interface:
with
> How unpopular would the idea of having cake look at skb->mark directly be?
loving it
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
Kevin Darbyshire-Bryant writes:
> How unpopular would the idea of having cake look at skb->mark directly be?
>
> https://github.com/ldir-EDB0/sch_cake/commit/64d0e6ac9368a271221db888ab91a367fcd37ae1
>
> https://github.com/ldir-EDB0/tc-adv/commit/4f16ae5d588d44f8a5c83fe2f2b7dcad97843cbc
Hmm, not
How unpopular would the idea of having cake look at skb->mark directly be?
https://github.com/ldir-EDB0/sch_cake/commit/64d0e6ac9368a271221db888ab91a367fcd37ae1
https://github.com/ldir-EDB0/tc-adv/commit/4f16ae5d588d44f8a5c83fe2f2b7dcad97843cbc
I did the equivalent in eBPF here
28 matches
Mail list logo
