From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [patch net-next v4 00/10] net: sched: allow qdiscs to share filter block instances Date: Fri, 5 Jan 2018 11:38:13 +0100 Message-ID: <20180105103813.GA2215@nanopsycho> References: <20180104065702.GH2067@nanopsycho.orion> <20180103230658.595eac7d@cakuba.netronome.com> <20180104101257.GA2213@nanopsycho> <20180104.103348.607053530850783354.davem@davemloft.net> <20180104155115.GG2213@nanopsycho> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kubakici@wp.pl, dsahern@gmail.com, netdev@vger.kernel.org, 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, 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: David Miller Return-path: Received: from mail-wr0-f195.google.com ([209.85.128.195]:35307 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750992AbeAEKiQ (ORCPT ); Fri, 5 Jan 2018 05:38:16 -0500 Received: by mail-wr0-f195.google.com with SMTP id l19so3982573wrc.2 for ; Fri, 05 Jan 2018 02:38:15 -0800 (PST) Content-Disposition: inline In-Reply-To: <20180104155115.GG2213@nanopsycho> Sender: netdev-owner@vger.kernel.org List-ID: Thu, Jan 04, 2018 at 04:51:15PM CET, jiri@resnulli.us wrote: >Thu, Jan 04, 2018 at 04:33:48PM CET, davem@davemloft.net wrote: >>From: Jiri Pirko >>Date: Thu, 4 Jan 2018 11:12:57 +0100 >> >>> No magic. ens8 and ens7 share the same block. >> >>No Jiri, the fact that they share the same block _IS MAGIC_. >> >>It is unexpected behavior to modify a rule and have it propagate >>to devices not mentioned in the command line. >> >>This is totally going to break things and upset people. >> >>Saying it shows up in some tc dump command is not an argument >>for this behavior being "expected". NO way. >> >>I completely agree with David and others, you _MUST_ make an >>explicit API and set of operations to make changes to rules >>contained in shared blocks. > >Okay. So you say that when I create a qdisc and its block is created, I >can never share it. > >I have to always explicitly create block to share and only then to bind >it to some qdisc/s? I think I have the idea. It can work as usual until the block gets to be shared, then only the block-specific things would work. The exisint filter add and filter should would error out (with extack message why). Ok, I'm on it. Thanks.