From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [patch net-next 5/5] mlxsw: spectrum: qdiscs: Support stats for PRIO qdisc Date: Fri, 12 Jan 2018 01:40:09 -0800 Message-ID: <20180112014009.09524ba4@laptop> References: <20180111102102.4310-1-jiri@resnulli.us> <20180111102102.4310-6-jiri@resnulli.us> <20180111160726.57a7ae5b@cakuba.netronome.com> <20180112003230.2f00e36a@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Yuval Mintz , Jiri Pirko , "netdev@vger.kernel.org" , "davem@davemloft.net" , "Ido Schimmel" , mlxsw , "jhs@mojatatu.com" , "xiyou.wangcong@gmail.com" To: Nogah Frankel Return-path: Received: from mx4.wp.pl ([212.77.101.11]:12937 "EHLO mx4.wp.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754419AbeALJkS (ORCPT ); Fri, 12 Jan 2018 04:40:18 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Fri, 12 Jan 2018 09:29:22 +0000 Nogah Frankel wrote: > > -----Original Message----- > > From: Yuval Mintz > > Sent: Friday, January 12, 2018 10:47 AM > > To: Jakub Kicinski > > Cc: Jiri Pirko ; netdev@vger.kernel.org; Nogah > > Frankel ; davem@davemloft.net; Ido Schimmel > > ; mlxsw ; jhs@mojatatu.com; > > xiyou.wangcong@gmail.com > > Subject: RE: [patch net-next 5/5] mlxsw: spectrum: qdiscs: Support > > stats for PRIO qdisc > > > > > Hm. You you need this just because you didn't add the backlog > > > > > pointer to destroy? AFAIK on destroy we are free to reset > > > > > stats as well, thus simplifying your driver... Let me know > > > > > if I misunderstand. > > The problem of doing it in destroy is when one qdisc is replacing > another. I want to be able to destroy the old qdisc to "make room" > for the new one before I get the destroy command for the old qdisc > (that will come just after the replace command for the new qdisc). > If I am saying that the destroy changes the stats, I need to save > some data about the old qdisc till I get the destroy command for it. Agreed, maintaining a coherent destroy behavior would be problematic when successful replace with a new qdisc (e.g. different handle) is involved :( Besides the momentary stats seem to be reset before destroy so not touching them may be in fact more correct. I need to look into the propagation done in qdisc_tree_reduce_backlog(), it worries me. If we start stacking the qdiscs (e.g. red on top of prio) it could mess with the root's backlog...