From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2506DC433FE for ; Fri, 10 Dec 2021 11:59:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gRVbk+PJQZZT3/KLY7nnsSdX35xuDsj6o71Crt8N6QY=; b=w0kkHUkDlp/ON0 BTUPcZwpgpqbvhPTwo6goBkJzRoqukSike/1EnUrDgQqDJvYC/GZ7sHkNSZncLItdznj0h6kLxKgT Qh8x9hCIZtDktg5H61SgIz1zLiHXmOHOgmDyPC7/g2EoUq1LIcJuzmL1T0Dwq0bVbMlf9yy5HVPCK u/5lNQ3a0YEbImLE8zkZrevmjAVcTyc/P7G6LL8dFgsw950qK5nUjt1FZUOOufdizBMGNeDVzXjTg 21iwgQ4/gmQml7o8i0qqdjUsZDMj4z5+UU/cy+1qbDHJY1nsJ+puioln6KlMsCVYTdfPd8uDGeoQq BhAW++qdAeNwsYZ0Q+sg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mveWx-001kdV-Fo; Fri, 10 Dec 2021 11:57:39 +0000 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mveWt-001kc3-7i for linux-arm-kernel@lists.infradead.org; Fri, 10 Dec 2021 11:57:36 +0000 Received: by mail-ed1-x530.google.com with SMTP id g14so28473478edb.8 for ; Fri, 10 Dec 2021 03:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ZKkcUBSPJzMq8SMeF9ajj9v3yK8GDhaOX6LqwtsglKU=; b=Ex2qNUyDM3sxiZwZKPmzPrB2Sm3dtWDQJmw6yR58bSjgfNyBhI7Rd+pGsUWuf0Rahr m2wzhXPJY06Wd3Q8ETtrXqw7tN9+eTmqP8U9Wd2wJTh5/7CeQnoHx1cPmYYCVc9g/LiS eZOOsV418ticlZjrJO+FRV5vhca6n5ULDc9lnrEcaYNzf6z/83fV+GmT4h9LMbWLpR57 7psarxI4twRYbc4KhLccU+Qx5h36fTg9B+RTACLxTmzLfaPEIQGxu/osOz4BRrmeDY79 wlkE5fvSOEKu2ElJ2yS/1ANWaryaM8d/WISeSqmikB0/VgPq6vM8LtbtVEn/QlhmUve0 vJ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ZKkcUBSPJzMq8SMeF9ajj9v3yK8GDhaOX6LqwtsglKU=; b=xyKneXEfT1yJE8B08g+48BG+m1A98+i33A5H1FFJeQoSLVUlHXDnIiROR4bYix/VI+ +Vnv35KTDs42I4ojUHNOQKZaLBYR2v1YLY1HsiXg981a2lRqUP82cZcG4HXAE89CKQq+ VpuA49+6hO6tHJY1PQSGeDknkw0JXj7PuT8FmH7Fu+4ewLi0W7KxlVknF8gAkMn5zpT9 MG3OTwrn9dLZSlkO5QwMm4Ms3eHi9SNwlBAmXAVG7rofPMRzGnJ4fwVfgLwImf2uI5b9 qJ6BQZOIJ88d/2lK1Iso5efRNPD2YfEiImMVY1mHarCsAebT40T5eqIlPPW+E8hB4A3U wcnA== X-Gm-Message-State: AOAM531tpPLZ8zHKewryiG+XmvVclprUzSMK2IclVfjSvlqoIFmBnXU6 EYoh5m53aUlXDYEz+kmOv0s= X-Google-Smtp-Source: ABdhPJwO6i/fjvqB1W9zY9joF47Rvl/w7uIQpgr7Qla+Sz2tR3V/8eDSvdBdRLeczxzVbXqKbYDbmg== X-Received: by 2002:a05:6402:1292:: with SMTP id w18mr37753850edv.46.1639137452517; Fri, 10 Dec 2021 03:57:32 -0800 (PST) Received: from skbuf ([188.25.173.50]) by smtp.gmail.com with ESMTPSA id h7sm1330524edb.89.2021.12.10.03.57.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Dec 2021 03:57:32 -0800 (PST) Date: Fri, 10 Dec 2021 13:57:30 +0200 From: Vladimir Oltean To: Ong Boon Leong , "David S . Miller" , Jakub Kicinski Cc: Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , Maxime Coquelin , alexandre.torgue@foss.st.com, Kurt Kanzenbach , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH net-next 0/2] net: stmmac: add EthType Rx Frame steering Message-ID: <20211210115730.bcdh7jvwt24u5em3@skbuf> References: <20211209151631.138326-1-boon.leong.ong@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211209151631.138326-1-boon.leong.ong@intel.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211210_035735_329083_5A190ADB X-CRM114-Status: GOOD ( 19.31 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi David, Jakub, On Thu, Dec 09, 2021 at 11:16:29PM +0800, Ong Boon Leong wrote: > Hi, > > Patch 1/2: Fixes issue in tc filter delete flower for VLAN priority > steering. Patch has been sent to 'net' ML. Link as follow: > > https://patchwork.kernel.org/project/netdevbpf/patch/20211209130335.81114-1-boon.leong.ong@intel.com/ > > Patch 2/2: Patch to add LLDP and IEEE1588 EtherType RX frame steering > in tc flower that is implemented on-top of patch 1/2. > > Below are the test steps for checking out the newly added feature:- > > # Setup traffic class and ingress filter > $ IFDEVNAME=eth0 > $ tc qdisc add dev $IFDEVNAME ingress > $ tc qdisc add dev $IFDEVNAME root mqprio num_tc 8 \ > map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 \ > queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 > > # Add two VLAN priority based RX Frame Steering > $ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \ > flower vlan_prio 1 hw_tc 1 > $ tc filter add dev $IFDEVNAME parent ffff: protocol 802.1Q \ > flower vlan_prio 2 hw_tc 2 > > # For LLDP > $ tc filter add dev $IFDEVNAME parent ffff: protocol 0x88cc \ > flower hw_tc 5 > > # For PTP > $ tc filter add dev $IFDEVNAME parent ffff: protocol 0x88f7 \ > flower hw_tc 6 > > # Show the ingress tc filters > $ tc filter show dev $IFDEVNAME ingress > > filter parent ffff: protocol ptp pref 49149 flower chain 0 > filter parent ffff: protocol ptp pref 49149 flower chain 0 handle 0x1 hw_tc 6 > eth_type 88f7 > in_hw in_hw_count 1 > filter parent ffff: protocol LLDP pref 49150 flower chain 0 > filter parent ffff: protocol LLDP pref 49150 flower chain 0 handle 0x1 hw_tc 5 > eth_type 88cc > in_hw in_hw_count 1 > filter parent ffff: protocol 802.1Q pref 49151 flower chain 0 > filter parent ffff: protocol 802.1Q pref 49151 flower chain 0 handle 0x1 hw_tc 2 > vlan_prio 2 > in_hw in_hw_count 1 > filter parent ffff: protocol 802.1Q pref 49152 flower chain 0 > filter parent ffff: protocol 802.1Q pref 49152 flower chain 0 handle 0x1 hw_tc 1 > vlan_prio 1 > in_hw in_hw_count 1 > > # Delete tc filters > $ tc filter del dev $IFDEVNAME parent ffff: pref 49149 > $ tc filter del dev $IFDEVNAME parent ffff: pref 49150 > $ tc filter del dev $IFDEVNAME parent ffff: pref 49151 > $ tc filter del dev $IFDEVNAME parent ffff: pref 49152 > > Thanks, > BL > > Ong Boon Leong (2): > net: stmmac: fix tc flower deletion for VLAN priority Rx steering > net: stmmac: add tc flower filter for EtherType matching > > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 20 ++ > .../net/ethernet/stmicro/stmmac/stmmac_tc.c | 189 +++++++++++++++++- > 2 files changed, 205 insertions(+), 4 deletions(-) > > -- > 2.25.1 > Is it the canonical approach to perform flow steering via tc-flower hw_tc, as opposed to ethtool --config-nfc? My understanding from reading the documentation is that tc-flower hw_tc only selects the hardware traffic class for a packet, and that this has to do with prioritization (although the concept in itself is a bit ill-defined as far as I understand it, how does it relate to things like offloaded skbedit priority?). But selecting a traffic class, in itself, doesn't (directly or necessarily) select a ring per se, as ethtool does? Just like ethtool doesn't select packet priority, just RX queue. When the RX queue priority is configurable (see the "snps,priority" device tree property in stmmac_mtl_setup) and more RX queues have the same priority, I'm not sure what hw_tc is supposed to do in terms of RX queue selection? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel