Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1451795ybb; Sun, 29 Mar 2020 05:10:11 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvsNLpjKNbQoF6GzZR5JX/vllxCd0FBcgroCu6m/3Fij4Q0ew1O9scQtwFg8fk2pHNL3sln X-Received: by 2002:a05:6830:168b:: with SMTP id k11mr5873813otr.156.1585483810929; Sun, 29 Mar 2020 05:10:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585483810; cv=none; d=google.com; s=arc-20160816; b=LXJwkuQ8haD0SAZA5BHcXV07alrsMF/eZq9FCPUJC/M/taDYhrm43gSEElW9Hnrmnx IY3IqgjjcCvuq3hEkMOoLc+CDVCgsWl18JFQ8VAjvAHT4bv/F1/0ayAF1uE3nHQefWy2 Dlhspk9EP/l/Z6bPciLyPVbyilobqSLY+Wqdn5A3PS92AIauLdjZqIuqm4WWLz1Lje/4 TvNvuglySTmuopjt7GANKkUDb+j1d117yh3xjo/N1vDjdkdfsAdTKD6dvGWZHQlbHHCU OCYlu8W3YeU4ePqcxcA2aw27ZiwbH75xn0AddRGytI6T2nI4CdM1pwzxoD9XBfvPzlw+ rb2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=kWqBhqN9W4UoJNuckL4CJb3lLsiw0Kie1I4t1l/WfLc=; b=QNJkhOLhg0JXBFhLtSn8P57T3Ofr8tgPFVpG3zHG/kvWeXj/xqnofvo39J7hKjkGRi 2mwJDTr6XkNWDNaKLcXjZYqvyEqjQXWnXoJbNGZ1bCmq8okeQgIJ9MrWrDsGc9Hswbe0 cQKseEkooAOSDFR3JDGKOtw5dc2xT8DYODAyF6yIt+zI8AEMeyMZ6yctFPOEWy/DZZtJ FJx/UejcT9rv7a/istoHlRgFOkD8ThV0RuuJ21hjOWnfcQtqtbMqNtpdgSOSkQ1J3Iqv dJvtWHk6yfEMIgVmR+tAHh4uXqOhvnItLS8IHFd0IZzCDvzT2ez5JdT/sACCmzbtzKd9 BoFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hvjEbv9B; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r7si4381347oij.4.2020.03.29.05.09.47; Sun, 29 Mar 2020 05:10:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hvjEbv9B; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728075AbgC2Lqa (ORCPT + 99 others); Sun, 29 Mar 2020 07:46:30 -0400 Received: from mail-ed1-f67.google.com ([209.85.208.67]:43049 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727772AbgC2Lqa (ORCPT ); Sun, 29 Mar 2020 07:46:30 -0400 Received: by mail-ed1-f67.google.com with SMTP id bd14so17343384edb.10; Sun, 29 Mar 2020 04:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kWqBhqN9W4UoJNuckL4CJb3lLsiw0Kie1I4t1l/WfLc=; b=hvjEbv9B4eBj4Hq4xeNNYSLh5YGTKm3/Rab7Q0VkqbssGbIel0QLt1BJXvASEfnPUp OCRL0U12jYDfseKnSYHf95bcOrnMlvzz1DqUGHriKWnKgMUbxqkmX5EIi2FHhyrIQceJ 6avqa7Bw9iEbpWFxEaQmI8GRV9wSW8nm5AKURKXbSnfAKS1w8gwYUlK9xUhfNmoDdKZO uyZcqKG6Nm4jPHft+X5su/2GVREbIuvBKXBrXFlBuDLPJNv44rMQmHuseJdsVmlHDgGV 0T8TOi5eXr/+Y2Qe+0s0SNTLufDoL5xc1W2qkIY9KB9afaqU3V1kE8/qLqjpX4Tc31eX AyUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kWqBhqN9W4UoJNuckL4CJb3lLsiw0Kie1I4t1l/WfLc=; b=PFx6gUYydBZT8X5CIJ5umGtZ7rLEwgTj4cLoP4dd0CvaTgiANZ07WzHVFd48ajPM1h CxaByvm/u/8gSOYjJ3yW6j2B2uwk6L5t0OWaG/8G22ZgohZrSjJXHOyDpeA4d8SbVoqu M58lrA+eVIU3bukPHP9RkexETFjef3+ECwrx7YPezzl9kg7lfcENioezsED62nLBEmLz zUP4VA2Bn/kwqwe3SJMPS8JTtE97m0D8grdmXu1gZ3jcP+qi5vd+jxw7qfghx+Geu7cW 6F0wavOSBsXc8Xr/j8o5UeSkb0kU3ih8CTPjFYeniW6J9iFpR335/nf8f0DNh9WCLT2T O75A== X-Gm-Message-State: ANhLgQ10iA+5rzCmuZQEb+aQGVU2k0RFm24ZN9Hu7cIzTRcpaWhQnYzt s4FM7aJeKrLUFvjJ6ym/P4fzm6SqihLCxPjyxrw= X-Received: by 2002:a17:906:449:: with SMTP id e9mr6569538eja.239.1585482387103; Sun, 29 Mar 2020 04:46:27 -0700 (PDT) MIME-Version: 1.0 References: <20200329005202.17926-1-olteanv@gmail.com> <20200329005202.17926-7-olteanv@gmail.com> <20200329095712.GA2188467@splinter> In-Reply-To: From: Vladimir Oltean Date: Sun, 29 Mar 2020 14:46:16 +0300 Message-ID: Subject: Re: [PATCH net-next 6/6] net: dsa: sja1105: add broadcast and per-traffic class policers To: Ido Schimmel Cc: Nikolay Aleksandrov , Roopa Prabhu , Andrew Lunn , Florian Fainelli , Vivien Didelot , "David S. Miller" , Jiri Pirko , Jakub Kicinski , netdev , Xiaoliang Yang , lkml , Horatiu Vultur , Alexandre Belloni , "Allan W. Nielsen" , Joergen Andreasen , Microchip Linux Driver Support , "Y.b. Lu" , Alexandru Marginean , Po Liu , Claudiu Manoil , Li Yang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 29 Mar 2020 at 14:37, Vladimir Oltean wrote: > > On Sun, 29 Mar 2020 at 12:57, Ido Schimmel wrote: > > > > + Nik, Roopa > > > > On Sun, Mar 29, 2020 at 02:52:02AM +0200, Vladimir Oltean wrote: > > > From: Vladimir Oltean > > > > > > This patch adds complete support for manipulating the L2 Policing Tables > > > from this switch. There are 45 table entries, one entry per each port > > > and traffic class, and one dedicated entry for broadcast traffic for > > > each ingress port. > > > > > > Policing entries are shareable, and we use this functionality to support > > > shared block filters. > > > > > > We are modeling broadcast policers as simple tc-flower matches on > > > dst_mac. As for the traffic class policers, the switch only deduces the > > > traffic class from the VLAN PCP field, so it makes sense to model this > > > as a tc-flower match on vlan_prio. > > > > > > How to limit broadcast traffic coming from all front-panel ports to a > > > cumulated total of 10 Mbit/s: > > > > > > tc qdisc add dev sw0p0 ingress_block 1 clsact > > > tc qdisc add dev sw0p1 ingress_block 1 clsact > > > tc qdisc add dev sw0p2 ingress_block 1 clsact > > > tc qdisc add dev sw0p3 ingress_block 1 clsact > > > tc filter add block 1 flower skip_sw dst_mac ff:ff:ff:ff:ff:ff \ > > > action police rate 10mbit burst 64k > > > > > > How to limit traffic with VLAN PCP 0 (also includes untagged traffic) to > > > 100 Mbit/s on port 0 only: > > > > > > tc filter add dev sw0p0 ingress protocol 802.1Q flower skip_sw \ > > > vlan_prio 0 action police rate 100mbit burst 64k > > > > > > The broadcast, VLAN PCP and port policers are compatible with one > > > another (can be installed at the same time on a port). > > > > Hi Vladimir, > > > > Some switches have a feature called "storm control". It allows one to > > police incoming BUM traffic. > > Yes, I am aware. > DPAA2 switches have a single (as far as I am aware) knob for 'flood > policers', and Ocelot has individual 'storm policers' for unknown > unicast, for multicast, broadcast and for 'learn frames'. > > > See this entry from Cumulus Linux > > documentation: > > > > https://docs.cumulusnetworks.com/cumulus-linux-40/Layer-2/Spanning-Tree-and-Rapid-Spanning-Tree/#storm-control > > > > In the past I was thinking about ways to implement this in Linux. The > > only place in the pipeline where packets are actually classified to > > broadcast / unknown unicast / multicast is at bridge ingress. Therefore, > > Actually I think only 'unknown unicast' is tricky here, and indeed the > bridge driver is the only place in the software datapath that would > know that. > I know very little about frame classification in the Linux network > stack, but would it be possible to introduce a match key in tc-flower > for whether packets have a known destination or not? > > > my thinking was to implement these storm control policers as a > > "bridge_slave" operation. It can then be offloaded to capable drivers > > via the switchdev framework. > > > > I think it would be a bit odd to duplicate tc functionality in the > bridge sysfs. I don't have a better suggestion though. > Not to mention that for hardware like this, to have the same level of flexibility via a switchdev control would mean to duplicate quite a lot of tc functionality. On this 5-port switch I can put a shared broadcast policer on 2 ports (via the ingress_block functionality), and individual policers on the other 3, and the bandwidth budgeting is separate. I can only assume that there are more switches out there that allow this. > > I think that if we have this implemented in the Linux bridge, then your > > patch can be used to support the policing of broadcast packets while > > returning an error if user tries to police unknown unicast or multicast > > packets. > > So even if the Linux bridge gains these knobs for flood policers, > still have the dst_mac ff:ff:ff:ff:ff:ff as a valid way to configure > one of those knobs? > > > Or maybe the hardware you are working with supports these types > > as well? > > Nope, on this hardware it's just broadcast, I just checked that. Which > simplifies things quite a bit. > > > > > WDYT? > > > > I don't know. > > Thanks, > -Vladimir -Vladimir