[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d075c0f5-c2b5-6ea8-f09a-7af5ba4ce05b@gmail.com>
Date: Tue, 26 Feb 2019 16:56:49 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: John Fastabend <john.fastabend@...il.com>,
Networking <netdev@...r.kernel.org>,
Jamal Hadi Salim <jhs@...atatu.com>,
Jiri Pirko <jiri@...nulli.us>
Subject: Re: [BUG] net/sched : qlen can not really be per cpu ?
On 02/26/2019 03:51 PM, Cong Wang wrote:
> On Tue, Feb 26, 2019 at 3:19 PM Eric Dumazet <eric.dumazet@...il.com> wrote:
>>
>>
>>
>> On 02/25/2019 10:42 PM, Eric Dumazet wrote:
>>> HTB + pfifo_fast as a leaf qdisc hits badly the following warning in htb_activate() :
>>>
>>> WARN_ON(cl->level || !cl->leaf.q || !cl->leaf.q->q.qlen);
>>>
>>> This is because pfifo_fast does not update sch->q.qlen, but per cpu counters.
>>> So cl->leaf.q->q.qlen is zero.
>>>
>>> HFSC, CBQ, DRR, QFQ have the same problem.
>>>
>>> Any ideas how we can fix this ?
>>
>> What about something simple for stable ?
>> ( I yet have to boot/test this )
>
> Is merely updating qlen sufficient for fixing it?
>
> I thought it is because of the lack of qdisc_tree_reduce_backlog()
> in pfifo_fast.
It does not seem to be the qdisc_tree_reduce_backlog() thing.
HTB, HFSC, CBQ, DRR, QFQ only peek at their children 'qlen' to decide if there
is at least one packet in them.
The backlog is only reported for dumps, but the actual backlog value is not used in data path.
Powered by blists - more mailing lists