From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Subject: Re: [patch net-next v6 00/11] net: sched: allow qdiscs to share
 filter block instances
Date: Mon, 8 Jan 2018 15:20:19 -0200
Message-ID: <20180108172019.GK725@localhost.localdomain>
References: <20180105230929.5645-1-jiri@resnulli.us>
 <20180108152306.GJ725@localhost.localdomain>
 <20180108154203.GF14494@nanopsycho>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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, dsahern@gmail.com
To: Jiri Pirko <jiri@resnulli.us>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:46346 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751783AbeAHRU0 (ORCPT <rfc822;netdev@vger.kernel.org>);
        Mon, 8 Jan 2018 12:20:26 -0500
Content-Disposition: inline
In-Reply-To: <20180108154203.GF14494@nanopsycho>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Mon, Jan 08, 2018 at 04:42:03PM +0100, Jiri Pirko wrote:
> Mon, Jan 08, 2018 at 04:23:06PM CET, marcelo.leitner@gmail.com wrote:
> >On Sat, Jan 06, 2018 at 12:09:18AM +0100, Jiri Pirko wrote:
> >...
> >> Note we cannot use the qdisc for filter manipulations for shared blocks:
> >> 
> >> $ tc filter add dev ens8 ingress protocol ip pref 1 flower dst_ip 192.168.100.2 action drop
> >> Error: Cannot work with shared block, please use block index.
> >> 
> >> 
> >> We will see the same output if we list filters for ingress qdisc of
> >> ens7 and ens8, also for the block 22:
> >> 
> >> $ tc filter show block 22
> >> filter block 22 protocol ip pref 25 flower chain 0
> >> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
> >> ...
> >> 
> >> $ tc filter show dev ens7 ingress
> >> filter block 22 protocol ip pref 25 flower chain 0
> >> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
> >> ...
> >> 
> >> $ tc filter show dev ens8 ingress
> >> filter block 22 protocol ip pref 25 flower chain 0
> >> filter block 22 protocol ip pref 25 flower chain 0 handle 0x1
> >> ...
> >
> >If changing a rule on an interface and reflecting it on the other
> >is considered confusing, what about getting the stats including the
> >stats from the other interface? AFAICT that's what would happen in the
> >3 show commands above, they would show the same values.
> 
> Yes. Same block, same values.
> 
> 
> >
> >Seems it can get confusing to the user: to check an interface, see
> >some hits on it, but they actually happened on the other interface.
> 
> Okay, what do you suggest?

Only one idea so far: highlight somehow that 'block X' is shared in
there.

> Note that "filter show" uses dumpit.

Yes.

> Also note that each filter listed under qdisc ens7 ingress and
> dev ens8 ingress is very clearly marked with "block 22".

Yes but one listing the rules on ens7 doesn't know that "block 22"
is shared with other interface(s).

> 
> Why is it confusing?

Pretty much the same reasoning as changing rules on it IMO, but:
- they may show hits that didn't happen on this interface
- they won't ever amount to the stats reported by the interface
  itself, even if the user has some catch-all rule.