> -----Original Message----- > From: Yuval Mintz > Sent: Friday, January 12, 2018 10:47 AM > To: Jakub Kicinski <kubak...@wp.pl> > Cc: Jiri Pirko <j...@resnulli.us>; netdev@vger.kernel.org; Nogah Frankel > <nog...@mellanox.com>; da...@davemloft.net; Ido Schimmel > <ido...@mellanox.com>; mlxsw <ml...@mellanox.com>; j...@mojatatu.com; > xiyou.wangc...@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. > > > > > > This is meant exactly for the scenario where qdisc didn't get > > > destroyed yet is no longer offloaded; E.g., if number of bands > > > increased beyond What we can offload. So we can't reset the > > > statistics in this case. [Although I might be the one to > > > misunderstand you, as the 'not destroyed' was explicitly mentioned > > > twice above] > > > > I was trying to take some liberty with handling of destroy but your > > approach may actually end up being simpler. I will withdraw my series > > for now and reuse your new callback once this series lands. > > > > Do you have any objections to changing RED to behave more like prio > > (and other qdiscs) in principle? On the contrary, I think it is great. > > From statistics' perspective? None.
