From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Pirko Subject: Re: [patch net-next v2 0/9] net: sched: introduce chain templates support with offloading to mlxsw Date: Thu, 28 Jun 2018 17:37:52 +0200 Message-ID: <20180628153752.GF2177@nanopsycho.orion> References: <20180628130907.951-1-jiri@resnulli.us> <3660d513-1f0c-fa7a-0ac2-9f89aec89389@gmail.com> <20180628142909.GE2177@nanopsycho.orion> <1dbc630d-2da3-afbe-18ba-e9dfc893bf04@gmail.com> 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, jakub.kicinski@netronome.com, simon.horman@netronome.com, john.hurley@netronome.com, mlxsw@mellanox.com, sridhar.samudrala@intel.com To: David Ahern Return-path: Received: from mail-wm0-f66.google.com ([74.125.82.66]:51248 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934359AbeF1PjW (ORCPT ); Thu, 28 Jun 2018 11:39:22 -0400 Received: by mail-wm0-f66.google.com with SMTP id w137-v6so10251711wmw.1 for ; Thu, 28 Jun 2018 08:39:22 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1dbc630d-2da3-afbe-18ba-e9dfc893bf04@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: Thu, Jun 28, 2018 at 05:10:45PM CEST, dsahern@gmail.com wrote: >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. But why? The same restriction would be in all drivers. I believe it is better to have in in tc in single place. Drivers can then depend on it. Do you have a usecase where you need to remove template for non-empty chain?