From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: Yang Yingliang <yangyingliang@huawei.com>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>, <davem@davemloft.net>,
<netdev@vger.kernel.org>, <eric.dumazet@gmail.com>,
<jpirko@redhat.com>
Subject: Re: [PATCH net v3 1/2] net: sched: tbf: fix calculation of max_size
Date: Wed, 20 Nov 2013 11:04:48 +0100 [thread overview]
Message-ID: <20131120110448.50b68d23@redhat.com> (raw)
In-Reply-To: <528C1B13.5090701@huawei.com>
On Wed, 20 Nov 2013 10:14:43 +0800
Yang Yingliang <yangyingliang@huawei.com> wrote:
> On 2013/11/19 17:38, Jesper Dangaard Brouer wrote:
> > On Tue, 19 Nov 2013 15:25:38 +0800
> > Yang Yingliang <yangyingliang@huawei.com> wrote:
> >
[...]
> >
> >> diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
> >> index 68f9859..c194129 100644
> >> --- a/net/sched/sch_tbf.c
> >> +++ b/net/sched/sch_tbf.c
> > [...]
> >> @@ -339,30 +326,46 @@ static int tbf_change(struct Qdisc *sch, struct nlattr *opt)
> > [...]
> >> + for (n = 0; n < 65536; n++)
> >> + if (psched_l2t_ns(&q->rate, n) > q->buffer)
> >> + break;
> >> + max_size = min_t(u32, n, (256ULL << qopt->rate.cell_log) - 1);
> >
> > I'm a little uncertain about, if using the 65536 constant is okay, or
> > considered "bad style".
>
> I'll use a MACRO to instead of this constant in v4.
I'm not saying you have to use a macro for this. I'm fine with using
65536 here, some other developers might have stronger opinions on this?
> > I'm still a little confused/uncertain why we need the "qopt->rate.cell_log".
> >
>
> Because we need max_size be smaller than mtu(user input in bytes).
> E.g. if user inputs like this "... burst 100KB rate 100mbit mtu 4095",
> without this patch, max_size is 4095.
> But with this patch, if don't use cell_log, max_size is 102400.
> I think it's not correct, so I used cell_log here.
Hmmmm... so you are using cell_log to approximate the MTU size, because
struct tc_ratespec, does not contain the a mtu parameter. You do
realize this is only an approximation. (This also smells like a bad
transition away from the userspace rate tables)
What about the p->mtu parameter from struct tc_tbf_qopt. I know it is
in a "time" format... but hey, you are already using this parameter
requoting your patch:
On Tue, 19 Nov 2013 15:25:38 +0800
Yang Yingliang <yangyingliang@huawei.com> wrote:
> diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
> index 68f9859..c194129 100644
> --- a/net/sched/sch_tbf.c
> +++ b/net/sched/sch_tbf.c
[... cut ...]
> @@ -339,30 +326,46 @@ static int tbf_change(struct Qdisc *sch, struct nlattr *opt)
> }
> q->limit = qopt->limit;
> q->mtu = PSCHED_TICKS2NS(qopt->mtu);
> - q->max_size = max_size;
> q->buffer = PSCHED_TICKS2NS(qopt->buffer);
> q->tokens = q->buffer;
> q->ptokens = q->mtu;
>
> if (tb[TCA_TBF_RATE64])
> rate64 = nla_get_u64(tb[TCA_TBF_RATE64]);
> - psched_ratecfg_precompute(&q->rate, &rtab->rate, rate64);
> - if (ptab) {
> + psched_ratecfg_precompute(&q->rate, &qopt->rate, rate64);
> + if (!q->rate.rate_bytes_ps)
> + goto unlock_done;
> + for (n = 0; n < 65536; n++)
> + if (psched_l2t_ns(&q->rate, n) > q->buffer)
> + break;
> + max_size = min_t(u32, n, (256ULL << qopt->rate.cell_log) - 1);
> +
> + if (qopt->peakrate.rate) {
> + int size = 0;
> if (tb[TCA_TBF_PRATE64])
> prate64 = nla_get_u64(tb[TCA_TBF_PRATE64]);
> - psched_ratecfg_precompute(&q->peak, &ptab->rate, prate64);
> + psched_ratecfg_precompute(&q->peak, &qopt->peakrate, prate64);
> + for (n = 0; n < 65536; n++)
> + if (psched_l2t_ns(&q->peak, n) > q->mtu)
You are using q->mtu here, BUT why are you only doing this, when there
is a qopt->peakrate.rate, set??? (I might have missed something)
> + break;
> + size = min_t(u32, n, (256ULL << qopt->rate.cell_log) - 1);
> + max_size = min_t(u32, max_size, size);
> q->peak_present = true;
> } else {
> q->peak_present = false;
> }
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
For easy reference
------------------
(include/uapi/linux/pkt_sched.h)
struct tc_ratespec {
unsigned char cell_log;
__u8 linklayer; /* lower 4 bits */
unsigned short overhead;
short cell_align;
unsigned short mpu;
__u32 rate;
};
struct tc_tbf_qopt {
struct tc_ratespec rate;
struct tc_ratespec peakrate;
__u32 limit;
__u32 buffer;
__u32 mtu;
};
next prev parent reply other threads:[~2013-11-20 10:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-19 7:25 [PATCH net v3 0/2] net: sched: fix some issues Yang Yingliang
2013-11-19 7:25 ` [PATCH net v3 1/2] net: sched: tbf: fix calculation of max_size Yang Yingliang
2013-11-19 9:38 ` Jesper Dangaard Brouer
2013-11-20 2:14 ` Yang Yingliang
2013-11-20 10:04 ` Jesper Dangaard Brouer [this message]
2013-11-20 12:50 ` Yang Yingliang
2013-11-23 19:06 ` Eric Dumazet
2013-11-24 7:28 ` Yang Yingliang
2013-11-24 18:40 ` Eric Dumazet
2013-11-25 3:43 ` Yang Yingliang
2013-11-25 12:04 ` [PATCH] " Yang Yingliang
2013-11-25 12:22 ` David Laight
2013-11-26 1:28 ` Yang Yingliang
2013-11-26 2:35 ` Yang Yingliang
2013-12-02 1:11 ` David Miller
2013-12-02 10:29 ` David Laight
2013-12-02 16:45 ` David Miller
2013-12-03 0:59 ` Yang Yingliang
2013-11-19 7:25 ` [PATCH net v3 2/2] net: sched: htb: fix calculation of quantum Yang Yingliang
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=20131120110448.50b68d23@redhat.com \
--to=jbrouer@redhat.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=jpirko@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=yangyingliang@huawei.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;
as well as URLs for NNTP newsgroup(s).