From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5B4783F169 for ; Mon, 14 May 2018 14:31:10 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1526322668; bh=BXdt7UPIonMqSweYExpaikW6Qmqm5Lh03PWALL+TCMw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=r7zxLcgvXSXhK5H5V33N0Z3jZ8apmRmlSAAhibaXLobW965MbILpBg8yVZr/thgfs xj40ekpjJtrbxCuf7w1iMEcaV2r5isxBG7VvDwYznrZIVkBv+taVkBGj4wWAScNJBZ SKuhrJ846H3uCJ+OkSQplVlJ2WrVjMR/btHsp7+q0xYV6DXNz/tzU8AOR5duQ6042T zRPtEcS/kU2gaW4suReVBUhojkuviPW9LOJr5Z5o3wO82hxO9QmvaENhuRFB5oNwnT 1lCoasGvjECQn0cXpySquFhfxh1SNVsWzhQlZtTLmpsvx2rLefXpIrdnl3kUgJqVTX XSTH6/xwhXlgg== To: David Miller Cc: netdev@vger.kernel.org, cake@lists.bufferbloat.net In-Reply-To: <20180514.110558.392362320880673775.davem@davemloft.net> References: <152579005972.4805.2514975750552805066.stgit@alrua-kau> <20180513.200948.1658763899383204062.davem@davemloft.net> <87h8nawqnn.fsf@toke.dk> <20180514.110558.392362320880673775.davem@davemloft.net> Date: Mon, 14 May 2018 20:31:02 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87efiew0m1.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] [PATCH net-next v9 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 18:31:10 -0000 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