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 50332C47DD9 for ; Wed, 28 Feb 2024 13:28:24 +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=/wopF+PLLUJIFqaGKzQFzBCY90HJzmOQZuTGVr5x89M=; b=Enyjta/+FRDNvB CDvUo6pNsQ9owHKz6Orby1w8S7o1jX6tt9oAqIFcytTUroAXm9rkQW+xpP/v/wosgFrH3ASbGaImO krDDqSbpUaSwMdun0Av/NArprVbiIADZ/Qzq4PX8pQPnsJGai42M5P8Z2rUYfmRKI7sJYgu6j9gkN vnt9kj9O3lPgaKjY3OYXAnhBvKKb3t7p4eaa/Tk5velWl7gyS/6vQtzU0HCgV3ynsvA3uyAI73tP/ PhPpow4BAmiB+EzJM/qqQKqgtvednQvDgoRP+PyvxDUyWupRhSTZW7WNnsqzejB3Z1oiXTciKCBeE 30JRsLXS8ByvK8nTVlaA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfJyi-00000009T6U-3BeJ; Wed, 28 Feb 2024 13:28:08 +0000 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfJye-00000009T3X-2lJH for linux-arm-kernel@lists.infradead.org; Wed, 28 Feb 2024 13:28:07 +0000 Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-412b824e0f3so344155e9.0 for ; Wed, 28 Feb 2024 05:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=resnulli-us.20230601.gappssmtp.com; s=20230601; t=1709126882; x=1709731682; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=e9wUp62staKveDTu96LB6OyYEe4qCAP2aId49Azr470=; b=AJIyXMKB2IGQeoRXHRCPWy1gimGjVGVtd/FRbMf0hLfEcbrrdIQTHPzlNxQDr70BMB yiucpBW1lLZNq/sLa+ZWyLRG+Yv4GDFULoMp2bCQkUQGUhCnf7T1K6tDmtnM3XQrRw7F 6vE1OiGGJqJTG4ftMviA9WUtcXZbC8GP1XPVV+Yd/jktbZt9sHW8m+p8yxP35A/tuy8D fcE868dY0qG1lbFH+MCAsHNWJjOjaqujbSofgnrxGPLKzqRsCgqToX82ernkfIzuum9z TQOkxpYBKtPzR0EaLmqogsK7qm224V//FOHd5G/a0R//MgqLjVW/FjyRAcDHDp5BnT2n MCWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709126882; x=1709731682; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=e9wUp62staKveDTu96LB6OyYEe4qCAP2aId49Azr470=; b=HNmP8oW9icTdWwID/3opkODPCFLiriNt4YbFFPBjqG9j+iu3LRV83kGrsGfyqQWeew 5sEm4fPVFdEav6+wTnGi7/bax8BhkWp47cnsZHHgu3q4+qge0gsJMYXiR8bk06pK9bhy UxvQ3w8VfCLAte24g+73AZcrRizNP6Idn0DRZ6ac5XC13gwKzTN2vIq7z+3pZrpaTccz gxPKTC2NZNEr1irTekhK7vZcTJAB4yn/nD8mvnUoQEoGn3J/98vwyF0lerOKf5J+7Imd dWu7mnN9tUNZDX5VGYKTL0iluwdWCeauRJu749IPOgN2OJDs8QGcfJYpdd9s39yizP9J PSYg== X-Forwarded-Encrypted: i=1; AJvYcCV4ifTsYGhBL4rJH9nftVmObsdB3zL+1k12xvwLUy9RSXRauFdGcqffQA9gu6HXZMwvEkVgJeohVTqbS6L4OnPc6RFqJAjqnzOUciPpAB/eDHIkuHM= X-Gm-Message-State: AOJu0YzokD5ZjfS2aRPqaE/WANfm+A5Nl8U2S+HvD2OdvLGRV4W9nOGY Z2iGxuKyam1LMiJWwPPv4jRuSgDxfCVMXp9dpQfZkWK8yEYNn1uyVbWADzueAnQ= X-Google-Smtp-Source: AGHT+IEPcxRfVeevLifaXmgO5QobEy2Cf5VY3JV3xCE4YTrpJZ6rYoXF80CZFflldoLPhoHRiWr5EA== X-Received: by 2002:a5d:528d:0:b0:33d:7c8:2230 with SMTP id c13-20020a5d528d000000b0033d07c82230mr9850374wrv.24.1709126882544; Wed, 28 Feb 2024 05:28:02 -0800 (PST) Received: from localhost ([193.47.165.251]) by smtp.gmail.com with ESMTPSA id d14-20020a5d538e000000b0033d4deb2356sm14476145wrv.56.2024.02.28.05.28.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Feb 2024 05:28:02 -0800 (PST) Date: Wed, 28 Feb 2024 14:27:59 +0100 From: Jiri Pirko To: Siddharth Vadapalli Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, rogerq@kernel.org, andrew@lunn.ch, vladimir.oltean@nxp.com, hkallweit1@gmail.com, dan.carpenter@linaro.org, horms@kernel.org, yuehaibing@huawei.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, srk@ti.com Subject: Re: [PATCH net-next] net: ethernet: ti: am65-cpsw: Add priv-flag for Switch VLAN Aware mode Message-ID: References: <20240227082815.2073826-1-s-vadapalli@ti.com> <7d1496da-100a-4336-b744-33e843eba930@ti.com> <49e531f7-9465-40ea-b604-22a3a7f13d62@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49e531f7-9465-40ea-b604-22a3a7f13d62@ti.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240228_052804_878963_20D89C6B X-CRM114-Status: GOOD ( 34.01 ) 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 Wed, Feb 28, 2024 at 11:04:55AM CET, s-vadapalli@ti.com wrote: > > >On 28/02/24 13:53, Jiri Pirko wrote: >> Wed, Feb 28, 2024 at 08:06:39AM CET, s-vadapalli@ti.com wrote: >>> >>> >>> On 27/02/24 18:09, Jiri Pirko wrote: >>>> Tue, Feb 27, 2024 at 09:28:15AM CET, s-vadapalli@ti.com wrote: >>>>> The CPSW Ethernet Switch on TI's K3 SoCs can be configured to operate in >>>>> VLAN Aware or VLAN Unaware modes of operation. This is different from >>>>> the ALE being VLAN Aware and Unaware. The Ethernet Switch being VLAN Aware >>>>> results in the addition/removal/replacement of VLAN tag of packets during >>>>> egress as described in section "12.2.1.4.6.4.1 Transmit VLAN Processing" of >>>>> the AM65x Technical Reference Manual available at: >>>>> https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf >>>>> In VLAN Unaware mode, packets remain unmodified on egress. >>>>> >>>>> The driver currently configures the Ethernet Switch in VLAN Aware mode by >>>>> default and there is no support to toggle this capability of the Ethernet >>>>> Switch at runtime. Thus, add support to toggle the capability by exporting >>>>> it via the ethtool "priv-flags" interface. >>>> >>>> I don't follow. You have all the means to offload all bridge/vlan >>>> configurations properly and setup your hw according to that. See mlxsw >>>> for a reference. I don't see the need for any custom driver knobs. >>>> >>> >>> Thank you for reviewing the patch. Please note that the "VLAN Aware mode" being >>> referred to here is different from ALE being VLAN aware. The hw offload of >>> bridge/vlan configurations is already supported in the context of the ALE. The >>> Ethernet Switch being VLAN Aware is a layer on top of that, which enables >>> further processing on top of the untagged/VLAN packets. This patch aims to >>> provide a method to enable the following use-cases: >>> 1. ALE VLAN Aware + CPSW VLAN Aware >>> 2. ALE VLAN Aware + CPSW VLAN Unaware >>> >>> All hw offloads of bridge/vlan configurations are w.r.t. ALE VLAN Aware alone. >>> Currently, only use-case 1 is enabled by the driver by default and there is no >>> knob to toggle to use-case 2. >>> >>> I am quoting sections of the Technical Reference Manual mentioned in my commit >>> message, in order to clarify the CPSW VLAN Unaware and CPSW VLAN Aware terminology. >>> >>> CPSW VLAN Unaware: >>> Transmit packets are NOT modified during switch egress. >>> >>> CPSW VLAN Aware: >>> 1. Untagged Packet Operations >>> Untagged packets are all packets that are not a VLAN packet or a priority tagged >>> packet. According to the CPWS0_FORCE_UNTAGGED_EGRESS_REG[1-0] MASK bit in the >>> packet header the packet may exit the switch with a VLAN tag inserted or the >>> packet may leave the switch unchanged.... >>> 2. Priority Tagged Packet Operations (VLAN VID == 0 && EN_VID0_MODE ==0h) >>> Priority tagged packets are packets that contain a VLAN header with VID = 0. >>> According to the CPSW_ALE_FORCE_UNTAGGED_EGRESS_REG[1-0] MASK bit in the packet >>> header, priority tagged packets may exit the switch with their VLAN ID and >>> priority replaced or they may have their priority tag completely removed.... >>> 3. VLAN Tagged Packet Operations (VLAN VID != 0 || (EN_VID0_MODE ==1h && VLAN >>> VID ==0)) >>> VLAN tagged packets are packets that contain a VLAN header specifying the VLAN >>> the packet belongs to >>> (VID), the packet priority (PRI), and the drop eligibility indicator (CFI). >>> According to the CPSW_ALE_FORCE_UNTAGGED_EGRESS_REG[1-0] MASK bit in the packet >>> header, VLAN tagged packets may exit the switch with their VLAN priority >>> replaced or they may have their VLAN header completely removed... >>> >>> I hope that this clarifies that CPSW VLAN Unaware/Aware is a layer on top of the >>> hw offload-able bridge/vlan configuration. Please let me know if there is >>> anything specific that could enable this without requiring the "priv-flag" based >>> implementation of this patch. >> >> I have no clue what "ALE" is. But in general. User provided > >ALE is Address Lookup Engine. > >> configuration, using ip/bridge/etc tools/uapi. According to this >> configuration, kernel is bahaving. When you do offload, you should just >> make sure to mimic/mirror the kernel behaviour. With this in mind, why > >What if there is no kernel behavior associated with it? How can it be mimicked >then? This patch isn't offloading any feature that is supported in software. It >might not be possible to offload features which act on the forwarding path of >packets entirely in Hardware within the Ethernet Switch. > >Please consider the following: >Untagged packets sent from Software via the corresponding VLAN interfaces will >be tagged which is the expected behavior. However, if this is offloaded, it will >imply that even untagged packets that are simply forwarded in the Ethernet >Switch and never get to software will also have to be tagged by the Ethernet >Switch. This is not allowing the choice of leaving untagged packets as-is on the >Ethernet Switch's forwarding path. This patch attempts to allow configuring >something quite similar to this, where it is possible to *choose* whether or not >to tag packets being forwarded. What would kernel datapath do? That is the question you need to ask and configure the hw accordingly. If 2 interfaces are in the bridge, vlans involved, etc, the forward behavior is well defined, isn't it. What am I missing? > >> can't you do it without adding additional knob? And if you really need >> it because the know does some internal hw/fw tuning, priv flag of netdev > >The feature can be turned on or off depending on the use-case. Is it acceptable >to have build configs scattered in the driver code? I don't suppose that is >acceptable, due to which it will be preferable to have a runtime configuration >option, which is what this patch provides. > >> is most probably not the correct place to put it. If it is, make sure > >Please suggest an alternative if this isn't the right place. Otherwise, I can >only assume that there isn't one. > >> you advocate for it properly in the patch description. >> >> pw-bot: cr >> > >-- >Regards, >Siddharth. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel