From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Cc: Pete Heist <pete@heistp.net>,
"cake\@lists.bufferbloat.net" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Using firewall connmarks as tin selectors
Date: Mon, 04 Mar 2019 18:36:09 +0100 [thread overview]
Message-ID: <87lg1u35km.fsf@toke.dk> (raw)
In-Reply-To: <05095212-7204-4490-97DF-8A7A39B6584C@darbyshire-bryant.me.uk>
Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
>> On 4 Mar 2019, at 16:39, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> 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, &ctinfo);
>>>>>>> + if (!ct)
>>>>>>> + return;
>>>>>>> +
>>>>>>> + ct->mark &= 0x80ffffff;
>>>>>>> + ct->mark |= (0x40 | dscp) << 24;
>>>>>>
>>>>>> Right, so we *might* have an argument that putting the *tin* into the
>>>>>> fwmark is CAKE's business, but copying over the dscp mark is not
>>>>>> something a qdisc should be doing…
>>>>>
>>>>> Why ever not? It’s not the DSCP, it’s a lookup value into the cake
>>>>> priority table, it just happens to look like the DSCP ;-)
>>>>
>>>> If it quacks like a duck…
>>>
>>> I honestly don’t know where to go from here. I’m clearly trying to do
>>> something that the kernel doesn’t want to do.
>>
>> I'm not disputing that what you're trying to do (moving DSCP field into
>> connmark) is useful. I'm just questioning whether CAKE is the right
>> place to do this. I think it would fit better in a TC action; either
>> modify act_connmark, or create a new action to sync fwmarks and DSCP
>> marks…
>
> Interesting. Thinks out loud - Two actions - ‘act_storedscp’,
> ‘act_restoredscp'
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:
https://elixir.bootlin.com/linux/latest/source/net/sched/act_connmark.c#L34
>>> @@ -1661,13 +1695,14 @@ static struct cake_tin_data *cake_select_tin(struct Qdisc *sch,
>>> tin = 0;
>>>
>>> else if (q->rate_flags & CAKE_FLAG_FWMARK && /* use fw mark */
>>> - skb->mark &&
>>> - skb->mark <= q->tin_cnt)
>>> - tin = q->tin_order[skb->mark - 1];
>>> -
>>> - else if (TC_H_MAJ(skb->priority) == sch->handle &&
>>> - TC_H_MIN(skb->priority) > 0 &&
>>> - TC_H_MIN(skb->priority) <= q->tin_cnt)
>>> + skb->mark & 0x40000000) {
>>
>> I think there's something odd with this mask? There's only one bit set
>> in it…
>
> I use the single bit as a flag to indicate cake has stored the DSCP
> in the lower 6 bits of the byte. Otherwise with a DSCP of 0 (the
> default) it’s rather difficult to know if a connection has been
> through the cake ’save dscp to fwmark’ process or not. That also
> indicates to user space whether it should consider mangling packets or
> not e.g.
Ah, right. But that breaks the previous use case where someone just
wants to set fwmarks that get turned into CAKE tins?
I think this definitely is leaning towards decoupling the
fw-mark-to-DSCP settings to an action. And probably making the shift and
mask configurable rather than hard-coding something...
-Toke
next prev parent reply other threads:[~2019-03-04 17:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-27 21:12 Felix Resch
2019-02-28 3:24 ` gamanakis
2019-03-03 11:52 ` Kevin Darbyshire-Bryant
2019-03-03 12:22 ` John Sager
2019-03-03 16:25 ` Kevin Darbyshire-Bryant
2019-03-04 11:04 ` Toke Høiland-Jørgensen
2019-03-04 11:39 ` John Sager
2019-03-04 5:37 ` Ryan Mounce
2019-03-04 6:31 ` Jonathan Morton
2019-03-04 6:37 ` Ryan Mounce
2019-03-04 7:15 ` Dave Taht
2019-03-04 8:39 ` Pete Heist
2019-03-04 11:01 ` Kevin Darbyshire-Bryant
2019-03-04 11:17 ` Toke Høiland-Jørgensen
2019-03-04 11:55 ` Kevin Darbyshire-Bryant
2019-03-04 12:44 ` Toke Høiland-Jørgensen
2019-03-04 15:50 ` Kevin Darbyshire-Bryant
2019-03-04 16:39 ` Toke Høiland-Jørgensen
2019-03-04 17:19 ` Kevin Darbyshire-Bryant
2019-03-04 17:36 ` Toke Høiland-Jørgensen [this message]
2019-03-04 20:58 ` Kevin Darbyshire-Bryant
2019-03-04 21:33 ` Toke Høiland-Jørgensen
2019-03-04 21:42 ` Toke Høiland-Jørgensen
2019-03-05 14:06 ` Kevin Darbyshire-Bryant
-- strict thread matches above, loose matches on Subject: below --
2019-02-27 14:52 Kevin Darbyshire-Bryant
2019-02-27 15:14 ` Toke Høiland-Jørgensen
2019-02-28 8:32 ` Kevin Darbyshire-Bryant
2019-02-28 9:54 ` Toke Høiland-Jørgensen
2019-02-28 11:00 ` Kevin Darbyshire-Bryant
2019-02-28 11:13 ` Toke Høiland-Jørgensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lg1u35km.fsf@toke.dk \
--to=toke@redhat.com \
--cc=cake@lists.bufferbloat.net \
--cc=kevin@darbyshire-bryant.me.uk \
--cc=pete@heistp.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox