From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: Re: [patch net-next v3 00/10] net: sched: allow qdiscs to share
 filter block instances
Date: Wed, 13 Dec 2017 16:46:52 -0800
Message-ID: <20171213164652.5e5dfa2b@cakuba.netronome.com>
References: <20171213151038.29665-1-jiri@resnulli.us>
        <04bcfa37-a74e-9e2f-3ac1-7ed8e63e13df@gmail.com>
        <20171213170757.GJ2031@nanopsycho>
        <90bf2450-a21c-9f70-2dc3-b147d0c40740@gmail.com>
        <20171213173948.GK2031@nanopsycho>
        <3d3f57ae-23b7-6389-7276-3019f57dce01@gmail.com>
        <20171213184241.GL2031@nanopsycho>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
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, 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 <jiri@resnulli.us>, David Ahern <dsahern@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-qt0-f193.google.com ([209.85.216.193]:40119 "EHLO
        mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751090AbdLNAq5 (ORCPT
        <rfc822;netdev@vger.kernel.org>); Wed, 13 Dec 2017 19:46:57 -0500
Received: by mail-qt0-f193.google.com with SMTP id u42so6050713qte.7
        for <netdev@vger.kernel.org>; Wed, 13 Dec 2017 16:46:57 -0800 (PST)
In-Reply-To: <20171213184241.GL2031@nanopsycho>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Wed, 13 Dec 2017 19:42:41 +0100, Jiri Pirko wrote:
> >>>> 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?  
> >> 
> >> Well, the filter add/del should just work no matter if the block behind is
> >> shared or not.  
> >
> >My argument is that modifying a shared block instance via a dev should
> >not be allowed. Those changes should only be allowed via the shared
> >block. So if a user puts adds a shared block to the device and then
> >attempts to add a filter via the device it should not be allowed.  
> 
> I don't see why. The handle is the qdisc here.

If you look at it from Linux perspective that makes sense.  For people
coming from switching world the fact that we use qdiscs as a handle for
ACL blocks is an implementation detail..  is that the argument here?