From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamal Hadi Salim Subject: Re: [patch net-next v4 00/10] net: sched: allow qdiscs to share filter block instances Date: Thu, 4 Jan 2018 08:30:54 -0500 Message-ID: <3d98834d-c02f-3209-a9d8-67603372cd60@mojatatu.com> References: <20180102194944.GG2051@nanopsycho.orion> <20180103094025.GA2067@nanopsycho.orion> <20180103172209.GD2067@nanopsycho.orion> <20180103155152.7e94a295@cakuba.netronome.com> <20180104065702.GH2067@nanopsycho.orion> <20180103230658.595eac7d@cakuba.netronome.com> <20180104101257.GA2213@nanopsycho> <20180104130044.GC2213@nanopsycho> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jakub Kicinski , David Ahern , netdev@vger.kernel.org, davem@davemloft.net, 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: Jiri Pirko Return-path: Received: from mail-it0-f66.google.com ([209.85.214.66]:46423 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752372AbeADNa6 (ORCPT ); Thu, 4 Jan 2018 08:30:58 -0500 Received: by mail-it0-f66.google.com with SMTP id c16so2294703itc.5 for ; Thu, 04 Jan 2018 05:30:58 -0800 (PST) In-Reply-To: <20180104130044.GC2213@nanopsycho> Content-Language: en-GB Sender: netdev-owner@vger.kernel.org List-ID: On 18-01-04 08:00 AM, Jiri Pirko wrote: > Thu, Jan 04, 2018 at 01:41:54PM CET, jhs@mojatatu.com wrote: >> >> And that a simple "tc qdisc add dev ens7 ingress" should >> either not be able to create a block (or we can say creates >> block id 0 - owned by the netdev - for consistency). > > This allocates a new block - as it needs it internally anyway - and tc > core will assign unused block id. You can see this id in the list then. > Later you can use this block id for other created qdiscs. > > Block ids are per-ns. > Hrm. I was thinking more that there is a block that cannot be shared and is only owned by the netdev i.e current behavior. But what you describe should work (and let the user decide if they want to share). >> >> Maybe what we need is another knob to control this new functionality? >> Either a kernel config option or an extra parameter when creating >> the qdisc or a system wide boolean per netdev (which of course >> contradicts the "less is more" principle). If this knob was set >> then you reject addition of filters via a port/qdisc which is sharing. > > I don't like this knob idea. It just adds confusion for no good reason > what so ever. I dont like it either but i see it as a knob to choose between improved usability/manageability (which new interface provides) vs least suprise - which is to keep the old syntax around. If i was an admin and turned on this knob - I am prepared to deal with fallout of some user script which tries to add filters via the device instead of the block. cheers, jamal