From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [patch net-next v3 00/10] net: sched: allow qdiscs to share filter block instances Date: Wed, 13 Dec 2017 10:18:04 -0700 Message-ID: <90bf2450-a21c-9f70-2dc3-b147d0c40740@gmail.com> References: <20171213151038.29665-1-jiri@resnulli.us> <04bcfa37-a74e-9e2f-3ac1-7ed8e63e13df@gmail.com> <20171213170757.GJ2031@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-pf0-f173.google.com ([209.85.192.173]:45441 "EHLO mail-pf0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753041AbdLMRSQ (ORCPT ); Wed, 13 Dec 2017 12:18:16 -0500 Received: by mail-pf0-f173.google.com with SMTP id u19so1582799pfa.12 for ; Wed, 13 Dec 2017 09:18:15 -0800 (PST) In-Reply-To: <20171213170757.GJ2031@nanopsycho> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 12/13/17 10:07 AM, Jiri Pirko wrote: > Wed, Dec 13, 2017 at 05:54:35PM CET, dsahern@gmail.com wrote: >> On 12/13/17 8:10 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 >> >> I still say this is very odd user semantic - making changes to device M >> and the changes magically affect device N. Operating on the shared block >> as a separate object makes it is much more direct and clear. > > I plan to do it as a follow-up patch. But this is how things are done > now and have to continue to work. Why is that? You are introducing the notion of a shared block with this patch set. What is the legacy "how things are done now" you are referring to? > Also changes done on dev block X for dev A has to appear in block X > for dev B. Block X is share between A and B. > Certainly - that's the definition of a shared block and you are referring to display and datapath. For admin, it is more direct and apparent in terms of what is happening to require changes (filter add and deletes) to be done by specifying the shared block as the primary object.