From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF3D4C282CE for ; Mon, 8 Apr 2019 08:54:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A79C920883 for ; Mon, 8 Apr 2019 08:54:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726559AbfDHIyl (ORCPT ); Mon, 8 Apr 2019 04:54:41 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:43625 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726189AbfDHIyl (ORCPT ); Mon, 8 Apr 2019 04:54:41 -0400 Received: by mail-ed1-f67.google.com with SMTP id w3so1723076edu.10 for ; Mon, 08 Apr 2019 01:54:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=z6yfHpkAQrO40/3V1Q7/l5KcPJmjY6FNOSmQWpIYVQI=; b=kckP++EMRcYLQqcuy9s9pqBz7gSIFnHMxFMHpl/dHWhBrng2ACoyDvDFeUOxSR/UEw JETPEceRTI0MOK0hrg2UWEntZ1S+YChIhlZJ+8r9NjFddWhUgWTi4pyLw2mzqoGoWgfw AFZDmC2O1KchCCl8z5B6/IMAVS8lS5wq/CU1cT/2GxuOBO0xj6c5/vYB2zHh7CWbfC9y HZqlBZ+1IWUGIKmFn30Ib43PdjB+rr5MJcs8hdJ6p+7h/9pxMIB6Wa/YzITW0hLIOMAg A0Qfv/THRd5Qf0QFDQEwGpON/PNMXMSFAXA2lB0BlwpvhSfNbaieQAdlZlv+x+lqzR8E z0ow== X-Gm-Message-State: APjAAAWibpFJRNw9SUZGleXR4D3xP3vLFkDdrtFhTnNnOLpWBjX1Sx5h Lqn3gKhQfVlCdVAOj1qUbtUqNw== X-Google-Smtp-Source: APXvYqw6EVZvpNBaR9DSbwlxYTFBW5cYxBQ/Fngmqp13x+EPP8nIVCqB3fuzC7DArYusaNqoNpzvJg== X-Received: by 2002:aa7:d44d:: with SMTP id q13mr18278666edr.230.1554713679653; Mon, 08 Apr 2019 01:54:39 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (alrua-x1.vpn.toke.dk. [2a00:7660:6da:10::2]) by smtp.gmail.com with ESMTPSA id a48sm8242447edd.30.2019.04.08.01.54.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Apr 2019 01:54:38 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 061061804A4; Mon, 8 Apr 2019 10:54:38 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Gautam Ramakrishnan Cc: Jamal Hadi Salim , davem@davemloft.net, netdev@vger.kernel.org, "Mohit P . Tahiliani" , "Sachin D . Patil" , Mohit Bhasi , "V . Saicharan" , Leslie Monis , Dave Taht Subject: Re: [RFC net-next 2/2] net: sched: fq_pie: Flow Queue PIE AQM In-Reply-To: References: <20190331174005.5841-1-gautamramk@gmail.com> <20190331174005.5841-3-gautamramk@gmail.com> <87bm1optqu.fsf@toke.dk> <87k1gcnwt6.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 08 Apr 2019 10:54:37 +0200 Message-ID: <87tvf8zxki.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Gautam Ramakrishnan writes: > I was trying to refactor the code and I ran into some issues. > 1. I moved some of the parameters such as flows_cnt into a new struct > called fq_pie_params, instead of keeping them in fq_pie_sched_data. > Should I move those parameters back into fq_pie_sched_data? Hmm, this is getting into taste here, but I think I would just put them directly into fq_pie_sched_data; after all, you are not reusing them in multiple places, and things like 'q->params.p_params.target' is a bit much for my taste :) > 2. fq_codel maintains the backlog variable as a list in the > fq_codel_sched_data, whereas I maintain a backlog in the struct > fq_pie_flow. What approach should I follow? The reason fq_codel does this is to keep that memory contiguous, so that when it loops through it all (in fq_codel_drop()), it is less memory that has to be loaded into cache. Since you're not doing that in fq_pie, it's not strictly necessary to mirror this (admittedly, somewhat confusing) aspect of fq_codel :) > 3. Would maintaining a per flow pie_stats be useful in the future? I > do not use the per flow stats anywhere in the code. Hard to know what is useful in the future. Is it useful now? It's easier to add new features later on than to remove them once they are there... So if you don't have an immediate use case for it, my suggestion would be to remove it, and add it back if someone really ends up needing it :) -Toke