Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1454895ybb; Sun, 29 Mar 2020 05:14:39 -0700 (PDT) X-Google-Smtp-Source: ADFU+vufM7iYTwPOn7EdoMaWIZKHLnlAadisnMf+MeJwefgTQA2yOHUoYHaixa4AlighpE63tpau X-Received: by 2002:a9d:3405:: with SMTP id v5mr5858594otb.131.1585484079135; Sun, 29 Mar 2020 05:14:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585484079; cv=none; d=google.com; s=arc-20160816; b=JqBCIxNccIumTkxT1B7xXRNRJ33I/n9preZNN7VFUYvqT/llSXCuhLPbDgLIjARs26 ffUDFMyIof0d05dvgmqWA4rqQtphZQrB/EIT1GKwVOhHcTxayJVg+2R6L07lbu6uPITW IowfoIRujuFQ5MbAeEUXt7Q8WgMKrwR4BSsvlVo18/XHlJqwm4yzj1a653wMNZieVtUH oYTZTp5ox+efmLE2eFEc9SDCQ6qpisU7XCvC+bppqTkkweuPohbv09ZDb56/F+KIOr1P Fa9bWT/xDzfLqZem57FbM2bq3Q69DEquemfv5efVlkiJstr9aiZzoQ6qK7q4FZEi0UXL D3/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=Cq8VIxSwvwCSuQt3WNmGkXzcdrs0outzKbdn+QVFL8s=; b=vLPuT3/WsOxNqjIoglc928tAb5JPDWAW4GfHdHGVPnJICmHiKneqtv8UCvNtZUw05u Xo3C6bKXREXznPNyR8v+23ZATnT8OVJj+1ZO9HOoNqsT6QQGmGImRj/TJCRi9AjUHdAx IYPS6xq0N4Z8Tgc/BX1Bgxh/WsBL/7iuDRX4YeNzvltlYztHrfLuhLTyllHjgCw5IlQ8 SIT3vcaAi7q36g4ObBRK4WDR28LGTkrNdZO1gmc40/qQtEJm70QwXuc9Oz+jetPIt2qJ 3BDivmNzLqdRMvxitWJmDxzs+idh8B1WxF5KQulIgIT1cWjnDbovvIhrKa8d5glZja3L SReQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cumulusnetworks.com header.s=google header.b=C5SDUba+; 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=NONE dis=NONE) header.from=cumulusnetworks.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h66si2755004oif.53.2020.03.29.05.14.25; Sun, 29 Mar 2020 05:14:39 -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=@cumulusnetworks.com header.s=google header.b=C5SDUba+; 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=NONE dis=NONE) header.from=cumulusnetworks.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728070AbgC2MCU (ORCPT + 99 others); Sun, 29 Mar 2020 08:02:20 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:47067 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727965AbgC2MCU (ORCPT ); Sun, 29 Mar 2020 08:02:20 -0400 Received: by mail-lj1-f196.google.com with SMTP id r7so7179015ljg.13 for ; Sun, 29 Mar 2020 05:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Cq8VIxSwvwCSuQt3WNmGkXzcdrs0outzKbdn+QVFL8s=; b=C5SDUba+Fkoy2P8Hc0dS+/pcVzsmUR1V/3qsUjGDQcKAG56T6DUtDJZu9YY9ZF0ezZ jwyEZ/VxLc7emmpUOm9NmpFXL1VUTcgnX2CFb5pdV/GhJ6XlGtOMa+NsBF5KLRkbu/NQ X5O9GNW0nyM/erPBbBpkQYzj11e9iTQZG83xs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Cq8VIxSwvwCSuQt3WNmGkXzcdrs0outzKbdn+QVFL8s=; b=hXh88xjcEtkAvLSe67K3JgnNsbDyVJK4WNBvSgSO7t9d9lOyBuxBlbY78Eu8TBuoRU 198W49CWbyln1i5IDYxpLOMfT38Stcyim4LdVtwWE7WNH5nEmqfqLlPEki08vfXKQ/5m Og+bfuM3zCJlB5/nTXyYp6xXPK8y5xjkZ3cWwRZopzhHK0wkqj94xZKMA4RyEeOt/QAD dAJQJpEZ/EKvtRKfIz1jtKxw4FE79HTLTV2ewuVWPys8jtf/9fJ6ND2H9D82OCFDX9Kq O8RFGZ8BXTeZG+wINLQvyaLPZMGLTclFb6jA66Qtp5EGG714rECXjXy1srb8KbmyuB5x jhbA== X-Gm-Message-State: AGi0PubpSeVbKal7L4/eKsPdoDtka//fvT+hlh+MWgiHp6fw29dJ5yJC mn+Jwq0Isrm4EhNQnexEfjZF8g== X-Received: by 2002:a2e:9586:: with SMTP id w6mr4514883ljh.133.1585483337920; Sun, 29 Mar 2020 05:02:17 -0700 (PDT) Received: from [192.168.0.109] (84-238-136-197.ip.btc-net.bg. [84.238.136.197]) by smtp.gmail.com with ESMTPSA id c13sm5328557ljj.37.2020.03.29.05.02.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Mar 2020 05:02:17 -0700 (PDT) Subject: Re: [PATCH net-next 6/6] net: dsa: sja1105: add broadcast and per-traffic class policers To: Vladimir Oltean , Ido Schimmel Cc: 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 References: <20200329005202.17926-1-olteanv@gmail.com> <20200329005202.17926-7-olteanv@gmail.com> <20200329095712.GA2188467@splinter> From: Nikolay Aleksandrov Message-ID: Date: Sun, 29 Mar 2020 15:02:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/03/2020 14:46, Vladimir Oltean wrote: > 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 [snip] >>> 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. Yep, unknown unicast is hard to pass outside of the bridge, especially at ingress where the bridge hasn't been hit yet. One possible solution is to expose a function from the bridge which can make such a decision at the cost of 1 more fdb hash lookup, but if the packet is going to hit the bridge anyway that cost won't be that high since it will have to do the same. We already have some internal bridge functionality exposed for netfilter, tc and some drivers so it would be in line with that. I haven't looked into how feasible the above is, so I'm open to other ideas (the bridge_slave functions for example, we've discussed such extensions before in other contexts). But I think this can be much simpler if we just expose the unknown unicast information, the mcast/bcast can be decided by the classifier already or with very little change. I think such exposed function can be useful to netfilter as well. >> 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 >