Re: RFC: Proposed fix for tc linklayer calc broken after commit 56b765b79 (htb: improved accuracy at high rates)
From: Eric Dumazet <hidden>
Date: 2013-06-06 14:28:08
On Thu, 2013-06-06 at 15:55 +0200, Jesper Dangaard Brouer wrote:
quoted hunk ↗ jump to hunk
Requesting comments. So, bacically commit 56b765b79 (htb: improved accuracy at high rates), broke the "linklayer atm" handling. As it didn't update the iproute tc util. Treating this as a regression fix, this is the smallest and least intrusive solution I could come up with. I'm basically restoring the "linklayer atm" handling, by using the __reserved field in struct tc_ratespec, to convey the chosen linklayer option. KERNEL patch: ============= [PATCH RFC] net_sched: restore "linklayer atm" handling From: Jesper Dangaard Brouer <redacted> commit 56b765b79 ("htb: improved accuracy at high rates") broke the "linklayer atm" handling. tc class add ... htb rate X ceil Y linklayer atm This patch restores the "linklayer atm" handling, by using the __reserved field in struct tc_ratespec, to convey the choosen linklayer option. This requires a corrosponding iproute2 tc fix, that updates this field. Older tc binaries can be detected by the kernel, as the field would be zero. Request-For-Comments-by: Jesper Dangaard Brouer [off-list ref] --- include/net/sch_generic.h | 8 +++++++- include/uapi/linux/pkt_sched.h | 11 ++++++++++- net/sched/sch_generic.c | 4 ++++ 3 files changed, 21 insertions(+), 2 deletions(-)diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h index e7f4e21..c9916b1 100644 --- a/include/net/sch_generic.h +++ b/include/net/sch_generic.h@@ -682,13 +682,18 @@ struct psched_ratecfg { u64 rate_bps; u32 mult; u16 overhead; + u8 linklayer; u8 shift; }; static inline u64 psched_l2t_ns(const struct psched_ratecfg *r, unsigned int len) { - return ((u64)(len + r->overhead) * r->mult) >> r->shift; + u64 pkt_len = len + r->overhead; + + if (r->linklayer == TC_LINKLAYER_ATM) + pkt_len = DIV_ROUND_UP(pkt_len,48)*53;
Is this working on 32bit kernel ?
+ return (pkt_len * r->mult) >> r->shift; }
I have no idea why you include so many people on your mails. This looks like ATM link have real rate of 48/53 of the rate. Since we have to distribute a new tc version, why not doing "tc ... rate rate X ceil Y linklayer atm" -> "tc ... rate X*48/53 Y*48/53" It avoids hard coded values in the kernel. Or make it use STAB if people really want to count bits/cells instead of bytes. Lets try to keep this overhead out of the fast path.