From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Subject: Re: [PATCH net-next v9 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc Date: Mon, 14 May 2018 20:31:02 +0200 Message-ID: <87efiew0m1.fsf@toke.dk> References: <152579005972.4805.2514975750552805066.stgit@alrua-kau> <20180513.200948.1658763899383204062.davem@davemloft.net> <87h8nawqnn.fsf@toke.dk> <20180514.110558.392362320880673775.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: netdev@vger.kernel.org, cake@lists.bufferbloat.net To: David Miller Return-path: Received: from mail.toke.dk ([52.28.52.200]:33239 "EHLO mail.toke.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751498AbeENSbJ (ORCPT ); Mon, 14 May 2018 14:31:09 -0400 In-Reply-To: <20180514.110558.392362320880673775.davem@davemloft.net> Sender: netdev-owner@vger.kernel.org List-ID: David Miller writes: > From: Toke H=C3=B8iland-J=C3=B8rgensen > Date: Mon, 14 May 2018 11:08:28 +0200 > >> David Miller writes: >>=20 >>> From: Toke H=C3=B8iland-J=C3=B8rgensen >>> Date: Tue, 08 May 2018 16:34:19 +0200 >>> >>>> +struct cake_flow { >>>> + /* this stuff is all needed per-flow at dequeue time */ >>>> + struct sk_buff *head; >>>> + struct sk_buff *tail; >>> >>> Please do not invent your own SKB list handling mechanism. >>=20 >> We didn't invent it, we inherited it from fq_codel. I was actually about >> to fix that, but then I noticed it was still around in fq_codel, and so >> let it be. I can certainly fix it anyway, but, erm, why is it acceptable >> in fq_codel but not in cake? struct sk_buff_head is not that new, is it? > > I guess one argument has to do with the amount of memory consumed by this > per-flow or per-queue information, right? Because the skb queue head has > a qlen and a spinlock regardless of whether they are used or not. > > Furthermore, if you use the __skb_insert() et al. helpers, even though it > won't use the lock it will adjust the qlen counter. And that's useless > work since you have no use for the qlen value. I think the useless work issue is larger than the memory usage. When running this (or FQ-CoDel) on small memory-constrained routers, we've mostly had issues with OOM because of the packet data, which dwarfs the per-queue overhead. > Taken together, it seems that what you and fq_codel are doing is not > such a bad idea after all. So please leave it alone. OK. I'll just resend with prettier Christmas trees, then :) > On-and-off again, I've looked into converting skbs to using list_head > but it's a non-trivial set of work. All over the tree the different > layers use the next/prev pointers in different ways. Some use it for a > doubly linked list. Some use it for a singly linked list. Some encode > state in the prev pointer. You name it, it's out there. > > I'll try to get back to that task because obviously it'll be useful to > have code like cake and fq_codel use common helpers instead of custom > stuff. Yup, I agree. From a code readability point of view, I also prefer the helpers. -Toke