From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [patch net-next v4 00/10] net: sched: allow qdiscs to share filter block instances Date: Sun, 24 Dec 2017 10:25:41 -0600 Message-ID: <780a80d0-9384-ae34-4cab-3070b004b64e@gmail.com> References: <20171223155436.9014-1-jiri@resnulli.us> <20171224071956.GA1883@nanopsycho> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, davem@davemloft.net, jhs@mojatatu.com, xiyou.wangcong@gmail.com, mlxsw@mellanox.com, andrew@lunn.ch, vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com, michael.chan@broadcom.com, ganeshgr@chelsio.com, saeedm@mellanox.com, matanb@mellanox.com, leonro@mellanox.com, idosch@mellanox.com, jakub.kicinski@netronome.com, simon.horman@netronome.com, pieter.jansenvanvuuren@netronome.com, john.hurley@netronome.com, alexander.h.duyck@intel.com, ogerlitz@mellanox.com, john.fastabend@gmail.com, daniel@iogearbox.net To: Jiri Pirko Return-path: Received: from mail-io0-f196.google.com ([209.85.223.196]:33830 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751399AbdLXQZs (ORCPT ); Sun, 24 Dec 2017 11:25:48 -0500 Received: by mail-io0-f196.google.com with SMTP id q188so4842236iod.1 for ; Sun, 24 Dec 2017 08:25:47 -0800 (PST) In-Reply-To: <20171224071956.GA1883@nanopsycho> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 12/24/17 1:19 AM, Jiri Pirko wrote: > Sun, Dec 24, 2017 at 02:54:47AM CET, dsahern@gmail.com wrote: >> On 12/23/17 9:54 AM, Jiri Pirko wrote: >>> So back to the example. First, we create 2 qdiscs. Both will share >>> block number 22. "22" is just an identification. If we don't pass any >>> block number, a new one will be generated by kernel: >>> >>> $ tc qdisc add dev ens7 ingress block 22 >>> ^^^^^^^^ >>> $ tc qdisc add dev ens8 ingress block 22 >>> ^^^^^^^^ >>> >>> Now if we list the qdiscs, we will see the block index in the output: >>> >>> $ tc qdisc >>> qdisc ingress ffff: dev ens7 parent ffff:fff1 block 22 >>> qdisc ingress ffff: dev ens8 parent ffff:fff1 block 22 >>> >>> To make is more visual, the situation looks like this: >>> >>> ens7 ingress qdisc ens7 ingress qdisc >>> | | >>> | | >>> +----------> block 22 <----------+ >>> >>> Unlimited number of qdiscs may share the same block. >>> >>> Now we can add filter to any of qdiscs sharing the same block: >>> >>> $ tc filter add dev ens7 ingress protocol ip pref 25 flower dst_ip 192.168.0.0/16 action drop >> >> >> Allowing config of a shared block through any qdisc that references it >> is akin to me allowing nexthop objects to be manipulated by any route >> that references it -- sure, it could be done but causes a lot surprises >> to the user. >> >> You are adding a new tc object -- a shared block. Why the resistance to >> creating a proper API for managing it? > > Again, no resistance, I said many times it would be done as a follow-up. > But as an api already exists, it has to continue to work. Or do you > suggest it should stop working? That, I don't agree with. > That is exactly what I am saying - principle of least surprise. The new object brings its own API and can only be modified using the new API. The scheme above can and will surprise users. You are thinking like a tc developer, someone intimately familiar with the code, and not like an ordinary user of this new feature.