Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752170AbcDOMmx (ORCPT ); Fri, 15 Apr 2016 08:42:53 -0400 Received: from mail-ig0-f172.google.com ([209.85.213.172]:37902 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751104AbcDOMmv (ORCPT ); Fri, 15 Apr 2016 08:42:51 -0400 Subject: Re: Deleting child qdisc doesn't reset parent to default qdisc? To: Eric Dumazet , Jiri Kosina References: <1460646099.10638.44.camel@edumazet-glaptop3.roam.corp.google.com> <20160414151813.GE3715@orbyte.nwl.cc> <1460656170.10638.61.camel@edumazet-glaptop3.roam.corp.google.com> Cc: Phil Sutter , netdev@vger.kernel.org, linux-kernel@vger.kernel.org From: Jamal Hadi Salim Message-ID: <5710E1C1.2090209@mojatatu.com> Date: Fri, 15 Apr 2016 08:42:41 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1460656170.10638.61.camel@edumazet-glaptop3.roam.corp.google.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1293 Lines: 37 On 16-04-14 01:49 PM, Eric Dumazet wrote: > And what would be the chosen behavior ? > TBF is probably a bad example because it started life as a classless qdisc. There was only one built-in fifo queue that was shaped. Then someone made it classful and changed this behavior. To me it sounds reasonable to have the default behavior restored. At minimal consistency. > Relying on TBF installing a bfifo for you at delete would be hazardous. > > For example CBQ got it differently than HFSC > > If qdisc_create_dflt() fails in CBQ, we fail the 'delete', while HFSC > falls back to noop_qdisc, without warning the user :( > > At least always using noop_qdisc is consistent. No magic there. > > Doing 'unification' right now would break existing scripts. > > This is too late, I am afraid. Sigh. So rant: IMO, we should let any new APIs and API updates stay longer in discussion. Or better mark them as unstable for sometime. The excuse that "it is out in the wild therefore cant be changed" is harmful because the timeline is "forever" whereas patches are applied after a short period of posting and discussions and sometimes not involving the right people. It is like having a jury issuing a death sentence after 1 week of deliberation. You cant take it back after execution. cheers, jamal