From: Patrick McHardy <kaber@trash.net>
To: Juliusz Chroboczek <jch@pps.jussieu.fr>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 1/2] Stochastic Fair Blue queue discipline, take two
Date: Sat, 24 May 2008 21:37:44 +0200 [thread overview]
Message-ID: <48386E88.2010104@trash.net> (raw)
In-Reply-To: <87tzgojx0o.fsf@pirx.pps.jussieu.fr>
Juliusz Chroboczek wrote:
> On 9 April 2008, I wrote
>
>>> The following is a second take on the sfb qdisc...
Great.
> There are quite a few things in Patrick's message that I don't understand.
>
>>> +struct tc_sfb_qopt {
> ...
>> I'd suggest to use nested attributes, even if you currently don't
>> have plans to add new members. The uglyness necessary to do this
>> later on is not really worth the small saving in netlink bandwidth.
>
> Could you please clarify what you mean? Perhaps by pointing me to
> some code?
You can either use put a struct inside the netlink attribute,
as you did, or nest other attributes below it and put the
data there. Look at hfsc_change_class() for one of many examples.
>>> + int i;
>
>> Please use unsigned types where possible.
>
> Is that a hard requirement? (I happen to prefer int, which I find
> more readable.)
unsigned has some advantages. You know it will never be negative
just by looking at the type, its more logical for things like a packet
length and in some cases the compiler can generate better code.
Hard requirement - sounds too extreme, I hope these arguments are
enough to convince you.
>>> + u16 minqlen = (u16)(~0);
>
>> Unnecessary cast and unnecessary parens.
>
> I realise that, but I dislike having non-trivial operations
> (truncation) being done by the assignment operation. Is that a hard
> requirement?
No, but I bet someone will send a cleanup patch to change
it anyways.
>>> + child = sfb_create_dflt(sch, limit);
>>> + if (child == NULL)
>>> + return -ENOMEM;
>>> +
>>> + sch_tree_lock(sch);
>>> + if (child) {
>
>> child == NULL is impossible ehere since its checked above. Replacing
>> the inner qdisc shouldn't be done unconditionally though, the default
>> should only be a default for the initial qdisc.
>
> Please clarify. This is code that was copied verbatim from sch_red,
> and I do not understand it.
You return -ENOMEM when child == NULL just three lines above.
So the check is obviously superfluous.
> Perhaps it'd be better if you made the needed changes to sch_red first?
red needs the check because the child may be NULL.
>>> + q->qdisc = &noop_qdisc;
>
>> The noop_qdisc assignment looks unnecessary, its replaced unconditionally.
>
> Again, this is code copied verbatim from sch_red. Please make the
> changes there first, I'm a little nervous about modifying code I don't
> understand.
You should be nervous about copying code you don't understand :)
red doesn't unconditionally assign q->qdisc in red_change(),
so it really needs this assigment.
>>> + struct tc_sfb_qopt opt = { .rehash_interval = q->rehash_interval,
>>> + .db_interval = q->db_interval,
>>> + .hash_type = q->hash_type,
>>> + .limit = q->limit,
>>> + .max = q->max,
>>> + .target = q->target,
>>> + .increment = q->increment,
>>> + .decrement = q->decrement,
>>> + .penalty_rate = q->penalty_rate,
>>> + .penalty_burst = q->penalty_burst,
>>> + };
>
>> Please reindent this correctly by using two tabs (same for other
>> C99 initializers).
>
> Please clarify, and point me to a suitable example. I'm just
> following the style in sch_red.
You don't, red uses proper intendation, which would look like this:
struct tc_sfb_qopt opt = {
.rehash_interval = ...,
.hash_type = ...
^ one level deeper than struct
prev parent reply other threads:[~2008-05-24 19:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-09 19:50 [PATCH 1/2] Stochastic Fair Blue queue discipline, take two Juliusz Chroboczek
2008-04-13 7:25 ` Patrick McHardy
2008-04-16 16:04 ` Juliusz Chroboczek
2008-05-24 1:44 ` Juliusz Chroboczek
2008-05-24 19:37 ` Patrick McHardy [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48386E88.2010104@trash.net \
--to=kaber@trash.net \
--cc=jch@pps.jussieu.fr \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).