From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Pete Heist <pete@heistp.net>, Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Cake on openwrt - falling behind
Date: Mon, 2 Jul 2018 16:59:36 +0000 [thread overview]
Message-ID: <33E764EB-8BB5-4ADA-B598-E6ECD4A7FFCD@darbyshire-bryant.me.uk> (raw)
In-Reply-To: <87fu11ipir.fsf@toke.dk>
[-- Attachment #1: Type: text/plain, Size: 4663 bytes --]
> On 2 Jul 2018, at 17:14, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Pete Heist <pete@heistp.net> writes:
>
>>> On Jul 2, 2018, at 2:03 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>
>>> Pete Heist <pete@heistp.net> writes:
>>>
>>>> But, um, I find it curious that tb[TCA_PAD] has valid looking values
>>>> in it, and if I just go:
>>>>
>>>> tb[TCA_STATS2] = tb[TCA_PAD]
>>>>
>>>> right after parse_rtattr is called, I start getting tin stats printed
>>>> that look valid. There should be zeroes or invalid values at
>>>> tb[TCA_PAD], as that’s just supposed to be padding, right?
>>>
>>> Hmm, that's interesting. Sounds like you are on the right track. What
>>> are the numerical values of TCA_STATS2 and TCA_PAD in the kernel and
>>> iproute2, respectively?
>>
>> I never would’ve guessed they could be different when compiled at once
>> :) but true, there are at least five different versions of rtnetlink.h
>> under build_dir based on their md5sums, and I see one belongs to
>> iproute2-full. In all of those, it looks in the source like
>> TCA_STATS2=7 and TCA_PAD=9.
>
> Aha! I think I figured out what is going on:
>
> The gen_stats facility will add an nlattr header at the beginning of the
> qdisc stats, which is the toplevel TLV that contains all stats (and that
> we put our stats inside). It stores a reference to this header, and when
> all the per-qdisc callbacks have finished adding their stats, it goes
> back and fixes up the length of the containing header.
>
> The problem is that on architectures that need padding, the padding TLV
> is added *first*, which means that the nlattr pointer that is stored
> before the callbacks are performed points to the padding TLV and not the
> stats TLV. And so, when the header is fixed up, the result (from the
> parser's perspective) is just a very big padding TLV.
>
> The options TLV is before the stats TLV, so the bug only occurs if the
> options happen to have a length that means the stats will need padding.
> Which is why messing with the number of options "fixes" the bug.
>
> Could you try applying the patch below (to the kernel) and see if that
> resolves the issue, please?
>
> -Toke
>
>
> @@ -77,8 +77,12 @@ gnet_stats_start_copy_compat(struct sk_buff *skb, int type, int tc_stats_type,
> d->lock = lock;
> spin_lock_bh(lock);
> }
> - if (d->tail)
> - return gnet_stats_copy(d, type, NULL, 0, padattr);
> + if (d->tail) {
> + int ret = gnet_stats_copy(d, type, NULL, 0, padattr);
> + if (!ret)
> + d->tail = ((struct nlattr *)skb_tail_pointer(skb)) - 1;
> + return ret;
> + }
>
> return 0;
> }
I do believe Sir you have cracked it. Without my u32 hack on a MIPS34kc arch that previously required my hack…..
tc -s qdisc show dev ifb4pppoa-wan
qdisc cake 800b: root refcnt 2 bandwidth 2027Kbit diffserv3 dual-dsthost nat ingress split-gso rtt 100.0ms raw overhead 0
tca_stats 2011972452 tca_stats2 2011971788 tca_xstats 0
calling print_tcstats_attr()
print_tcstats_attr()
got stats2
Sent 144 bytes 3 pkt (dropped 0, overlimits 0 requeues 0)
xstats 2145834940 tca_stats_app 2011971792
backlog 0b 0p requeues 0
got xstats 2011971792 tca_stats 2011972452 tca_stats2 2011971788 tca_xstats 0
memory used: 2464b of 4Mb
capacity estimate: 2027Kbit
min/max network layer size: 48 / 48
min/max overhead-adjusted size: 48 / 48
average network hdr offset: 0
Bulk Best Effort Voice
thresh 126680bit 2027Kbit 506744bit
target 143.4ms 9.0ms 35.9ms
interval 286.8ms 104.0ms 130.9ms
pk_delay 0us 17us 0us
av_delay 0us 0us 0us
sp_delay 0us 0us 0us
backlog 0b 0b 0b
pkts 0 3 0
bytes 0 144 0
way_inds 0 0 0
way_miss 0 1 0
way_cols 0 0 0
drops 0 0 0
marks 0 0 0
ack_drop 0 0 0
sp_flows 0 1 0
bk_flows 0 0 0
un_flows 0 0 0
max_len 0 48 0
quantum 300 300 300
Cheers,
Kevin D-B
012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-07-02 16:59 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.381.1530347349.3512.cake@lists.bufferbloat.net>
2018-06-30 16:37 ` Georgios Amanakis
2018-06-30 17:26 ` Pete Heist
2018-06-30 18:09 ` Georgios Amanakis
2018-06-30 18:55 ` Kevin Darbyshire-Bryant
2018-06-30 19:57 ` Pete Heist
2018-06-30 20:58 ` Georgios Amanakis
2018-06-30 21:37 ` Pete Heist
2018-06-30 22:43 ` Pete Heist
2018-06-30 23:20 ` Pete Heist
[not found] ` <CACvFP_gkdAPKSEO7j9+cMPqTa-fJYd8XFEEBD6ZzLuVvaNwsvg@mail.gmail.com>
2018-07-01 2:37 ` [Cake] Fwd: " Georgios Amanakis
2018-07-01 7:18 ` [Cake] " Pete Heist
2018-07-01 13:48 ` Pete Heist
2018-07-01 14:02 ` Dave Taht
2018-07-01 15:30 ` Pete Heist
2018-07-01 14:38 ` Kevin Darbyshire-Bryant
2018-07-01 16:54 ` Pete Heist
2018-07-01 19:41 ` Kevin Darbyshire-Bryant
2018-07-02 10:19 ` Pete Heist
2018-07-02 11:38 ` Pete Heist
2018-07-02 11:59 ` Kevin Darbyshire-Bryant
2018-07-02 14:01 ` Pete Heist
2018-07-02 12:03 ` Toke Høiland-Jørgensen
2018-07-02 14:51 ` Pete Heist
2018-07-02 16:14 ` Toke Høiland-Jørgensen
2018-07-02 16:59 ` Kevin Darbyshire-Bryant [this message]
2018-07-02 17:04 ` Pete Heist
2018-07-02 17:12 ` Kevin Darbyshire-Bryant
2018-07-02 18:24 ` Pete Heist
2018-07-02 19:31 ` Toke Høiland-Jørgensen
2018-07-02 20:09 ` Pete Heist
2018-07-02 20:11 ` Toke Høiland-Jørgensen
2018-07-02 20:46 ` Pete Heist
[not found] ` <mailman.407.1530550780.3512.cake@lists.bufferbloat.net>
2018-07-02 17:50 ` Kevin Darbyshire-Bryant
2018-07-02 19:33 ` Toke Høiland-Jørgensen
2018-07-02 19:36 ` Kevin Darbyshire-Bryant
2018-07-02 19:39 ` Toke Høiland-Jørgensen
2018-07-02 20:03 ` [Cake] cake at 60gbit Dave Taht
2018-07-02 20:09 ` Toke Høiland-Jørgensen
2018-07-02 21:16 ` Pete Heist
2018-07-02 21:35 ` Toke Høiland-Jørgensen
2018-07-02 22:07 ` Georgios Amanakis
2018-07-02 22:12 ` Dave Taht
2018-07-02 23:48 ` Georgios Amanakis
2018-07-02 22:23 ` Toke Høiland-Jørgensen
2018-07-03 7:35 ` Pete Heist
2018-07-03 9:18 ` Jonathan Morton
2018-07-03 9:57 ` Pete Heist
2018-07-03 10:27 ` Toke Høiland-Jørgensen
2018-07-03 10:41 ` Pete Heist
2018-07-05 22:31 ` Toke Høiland-Jørgensen
2018-07-05 23:48 ` Georgios Amanakis
2018-07-06 1:21 ` Dave Taht
2018-07-06 2:55 ` George Amanakis
2018-07-06 3:06 ` George Amanakis
2018-07-06 9:22 ` Toke Høiland-Jørgensen
2018-07-06 9:21 ` Toke Høiland-Jørgensen
2018-07-06 8:55 ` Pete Heist
2018-07-06 9:29 ` Toke Høiland-Jørgensen
2018-07-06 10:00 ` Pete Heist
2018-07-06 10:46 ` Toke Høiland-Jørgensen
2018-07-06 11:33 ` Toke Høiland-Jørgensen
2018-07-06 11:43 ` Jonathan Morton
2018-07-06 11:48 ` Toke Høiland-Jørgensen
2018-07-06 11:58 ` Pete Heist
2018-07-06 12:04 ` Toke Høiland-Jørgensen
2018-07-02 18:39 ` [Cake] Cake on openwrt - falling behind Dave Taht
2018-07-02 19:11 ` Kevin Darbyshire-Bryant
2018-07-02 19:23 ` Toke Høiland-Jørgensen
2018-07-02 19:27 ` Dave Taht
2018-07-02 19:38 ` Toke Høiland-Jørgensen
2018-07-02 20:05 ` Toke Høiland-Jørgensen
2018-07-02 19:31 ` Pete Heist
[not found] ` <mailman.397.1530474091.3512.cake@lists.bufferbloat.net>
2018-07-01 23:55 ` Dave Taht
2018-07-02 0:05 ` Dave Taht
[not found] ` <mailman.392.1530455913.3512.cake@lists.bufferbloat.net>
2018-07-01 15:17 ` Jonathan Morton
[not found] ` <mailman.384.1530384918.3512.cake@lists.bufferbloat.net>
2018-07-01 9:46 ` Magnus Olsson
2018-07-01 12:34 ` Kevin Darbyshire-Bryant
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=33E764EB-8BB5-4ADA-B598-E6ECD4A7FFCD@darbyshire-bryant.me.uk \
--to=kevin@darbyshire-bryant.me.uk \
--cc=cake@lists.bufferbloat.net \
--cc=pete@heistp.net \
--cc=toke@toke.dk \
/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