From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] [PATCH net-next v8 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc
Date: Mon, 07 May 2018 20:37:01 +0200 [thread overview]
Message-ID: <87in7zmhwy.fsf@toke.dk> (raw)
In-Reply-To: <CAM_iQpV4qThp2+_sKC7ZBgUCUu0BSZvOkT0tvf2ATdMFgu+YPg@mail.gmail.com>
Cong Wang <xiyou.wangcong@gmail.com> writes:
> On Fri, May 4, 2018 at 12:10 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> Thank you for the review! A few comments below, I'll fix the rest.
>>
>>> [...]
>>>
>>> So sch_cake doesn't accept normal tc filters? Is this intentional?
>>> If so, why?
>>
>> For two reasons:
>>
>> - The two-level scheduling used in CAKE (tins / diffserv classes, and
>> flow hashing) does not map in an obvious way to the classification
>> index of tc filters.
>
> Sounds like you need to extend struct tcf_result?
Well, the obvious way to support filters would be to have skb->priority
override the diffserv mapping if set, and have the filter classification
result select the queue within that tier. That would probably be doable,
but see below.
>> - No one has asked for it. We have done our best to accommodate the
>> features people want in a home router qdisc directly in CAKE, and the
>> ability to integrate tc filters has never been requested.
>
> It is not hard to integrate, basically you need to call
> tcf_classify(). Although it is not mandatory, it is odd to merge a
> qdisc doesn't work with existing tc filters (and actions too).
I looked at the fq_codel code to do this. Is it possible to support
filtering without implementing Qdisc_class_ops? If so, I'll give it a
shot; but implementing the class ops is more than I can commit to...
>>>> +static int cake_init(struct Qdisc *sch, struct nlattr *opt,
>>>> + struct netlink_ext_ack *extack)
>>>> +{
>>>> + struct cake_sched_data *q = qdisc_priv(sch);
>>>> + int i, j;
>>>> +
>>>> + sch->limit = 10240;
>>>> + q->tin_mode = CAKE_DIFFSERV_BESTEFFORT;
>>>> + q->flow_mode = CAKE_FLOW_TRIPLE;
>>>> +
>>>> + q->rate_bps = 0; /* unlimited by default */
>>>> +
>>>> + q->interval = 100000; /* 100ms default */
>>>> + q->target = 5000; /* 5ms: codel RFC argues
>>>> + * for 5 to 10% of interval
>>>> + */
>>>> +
>>>> + q->cur_tin = 0;
>>>> + q->cur_flow = 0;
>>>> +
>>>> + if (opt) {
>>>> + int err = cake_change(sch, opt, extack);
>>>> +
>>>> + if (err)
>>>> + return err;
>>>
>>>
>>> Not sure if you really want to reallocate q->tines below for this
>>> case.
>>
>> I'm not sure what you mean here? If there's an error we return it and
>> the qdisc is not created. If there's not, we allocate and on subsequent
>> changes cake_change() will be called directly, or? Can the init function
>> ever be called again during the lifetime of the qdisc?
>>
>
> In non-error case, you call cake_change() first and then allocate
> ->tins with kvzalloc() below. For me it looks like you don't need to
> allocate it again when ->tins!=NULL.
No, we definitely don't. It's just not clear to me how cake_init() could
ever be called with q->tins already allocated?
I can add a check in any case, though, I see that there is one in
fq_codel as well...
-Toke
next prev parent reply other threads:[~2018-05-07 18:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-04 14:02 [Cake] [PATCH net-next v8 0/7] " Toke Høiland-Jørgensen
2018-05-04 14:02 ` [Cake] [PATCH net-next v8 7/7] sch_cake: Conditionally split GSO segments Toke Høiland-Jørgensen
2018-05-04 14:02 ` [Cake] [PATCH net-next v8 5/7] sch_cake: Add DiffServ handling Toke Høiland-Jørgensen
2018-05-04 14:02 ` [Cake] [PATCH net-next v8 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc Toke Høiland-Jørgensen
2018-05-04 17:57 ` Cong Wang
2018-05-04 19:10 ` Toke Høiland-Jørgensen
2018-05-07 16:35 ` Cong Wang
2018-05-07 18:37 ` Toke Høiland-Jørgensen [this message]
2018-05-08 4:11 ` Cong Wang
2018-05-04 14:02 ` [Cake] [PATCH net-next v8 3/7] sch_cake: Add optional ACK filter Toke Høiland-Jørgensen
2018-05-04 14:02 ` [Cake] [PATCH net-next v8 4/7] sch_cake: Add NAT awareness to packet classifier Toke Høiland-Jørgensen
2018-05-04 14:02 ` [Cake] [PATCH net-next v8 6/7] sch_cake: Add overhead compensation support to the rate shaper Toke Høiland-Jørgensen
2018-05-04 14:02 ` [Cake] [PATCH net-next v8 2/7] sch_cake: Add ingress mode 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=87in7zmhwy.fsf@toke.dk \
--to=toke@toke.dk \
--cc=cake@lists.bufferbloat.net \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/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