From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Ahern Subject: Re: [patch net-next v2 0/9] net: sched: introduce chain templates support with offloading to mlxsw Date: Thu, 28 Jun 2018 09:10:45 -0600 Message-ID: <1dbc630d-2da3-afbe-18ba-e9dfc893bf04@gmail.com> References: <20180628130907.951-1-jiri@resnulli.us> <3660d513-1f0c-fa7a-0ac2-9f89aec89389@gmail.com> <20180628142909.GE2177@nanopsycho.orion> 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, jakub.kicinski@netronome.com, simon.horman@netronome.com, john.hurley@netronome.com, mlxsw@mellanox.com, sridhar.samudrala@intel.com To: Jiri Pirko Return-path: Received: from mail-pl0-f68.google.com ([209.85.160.68]:33991 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932522AbeF1PKs (ORCPT ); Thu, 28 Jun 2018 11:10:48 -0400 Received: by mail-pl0-f68.google.com with SMTP id z9-v6so2926652plo.1 for ; Thu, 28 Jun 2018 08:10:48 -0700 (PDT) In-Reply-To: <20180628142909.GE2177@nanopsycho.orion> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 6/28/18 8:29 AM, Jiri Pirko wrote: > Thu, Jun 28, 2018 at 04:18:47PM CEST, dsahern@gmail.com wrote: >> On 6/28/18 7:08 AM, Jiri Pirko wrote: >>> Create dummy device with clsact first: >>> # ip link add type dummy >>> # tc qdisc add dev dummy0 clsact >>> >>> There is no template assigned by default: >>> # tc chaintemplate show dev dummy0 ingress >>> >>> Add a template of type flower allowing to insert rules matching on last >>> 2 bytes of destination mac address: >>> # tc chaintemplate add dev dummy0 ingress proto ip flower dst_mac 00:00:00:00:00:00/00:00:00:00:FF:FF >>> >>> The template is now showed in the list: >>> # tc chaintemplate show dev dummy0 ingress >>> chaintemplate flower chain 0 >>> dst_mac 00:00:00:00:00:00/00:00:00:00:ff:ff >>> eth_type ipv4 >>> >>> Add another template, this time for chain number 22: >>> # tc chaintemplate add dev dummy0 ingress proto ip chain 22 flower dst_ip 0.0.0.0/16 >>> # tc chaintemplate show dev dummy0 ingress >>> chaintemplate flower chain 0 >>> dst_mac 00:00:00:00:00:00/00:00:00:00:ff:ff >>> eth_type ipv4 >>> chaintemplate flower chain 22 >>> eth_type ipv4 >>> dst_ip 0.0.0.0/16 >>> >>> Add a filter that fits the template: >>> # tc filter add dev dummy0 ingress proto ip flower dst_mac aa:bb:cc:dd:ee:ff/00:00:00:00:00:0F action drop >>> >>> Addition of filters that does not fit the template would fail: >>> # tc filter add dev dummy0 ingress proto ip flower dst_mac aa:11:22:33:44:55/00:00:00:FF:00:00 action drop >>> Error: Mask does not fit the template. >>> We have an error talking to the kernel, -1 >>> # tc filter add dev dummy0 ingress proto ip flower dst_ip 10.0.0.1 action drop >>> Error: Mask does not fit the template. >>> We have an error talking to the kernel, -1 >>> >>> Additions of filters to chain 22: >>> # tc filter add dev dummy0 ingress proto ip chain 22 flower dst_ip 10.0.0.1/8 action drop >>> # tc filter add dev dummy0 ingress proto ip chain 22 flower dst_ip 10.0.0.1 action drop >>> Error: Mask does not fit the template. >>> We have an error talking to the kernel, -1 >>> # tc filter add dev dummy0 ingress proto ip chain 22 flower dst_ip 10.0.0.1/24 action drop >>> Error: Mask does not fit the template. >>> We have an error talking to the kernel, -1 >>> >>> Removal of a template from non-empty chain would fail: >>> # tc chaintemplate del dev dummy0 ingress >>> Error: The chain is not empty, unable to delete template. >>> We have an error talking to the kernel, -1 >> >> Why this restriction? It's a template, so why can't it be removed >> regardless of whether there are filters? > > That means you could start to insert filters that does not match the > original template. I wanted to avoid it. The chain is utilized in hw for > the original template, the filter insertion would have to be sanitized > in driver. With this restriction, drivers can depend on filters always > be fitting. > Then the hardware driver should have that restriction not the core tc code.