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 AC336C433FE for ; Tue, 8 Nov 2022 12:23:56 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:Subject:From:References:Cc:To: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4gzHVXjePiZmASh4M64JiZoUhq7RFDYxTfX2tL8YRYI=; b=3AIH62hhU5TxqC 4rFOrvUMdhSZxofWRkXGCX8vb77GOR3Ej/HE5kp4TJ9rKFtt3IwoQ+BJg/FYDs2mLTInxhN1q5KZt iE1v2XaSOK8nAzjeTHNmJHI78KKW2Ii0sgXOGuutwj78Mxdl4WCnukaqCmHx59cNvQoaWfwY9ygdr eZURAUuimhYWBWTBcUKtoQD6NgyIe04Wg9SKa/dKEryew1vCFs7cnzH2VfqdQLsk7pQ8WzVdFQftF CRxYphaU4E3Np8j5rWSAlVUNLQfbdxDJ+k7d4V8exPggk0i9afP7LO/s01eK3PX9bVr1ymmTXxDFi dh/L0/yNoz+DHfFChTlQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1osNck-005BKH-0R; Tue, 08 Nov 2022 12:22:38 +0000 Received: from nbd.name ([46.4.11.11]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1osNcf-005BGN-Qg for linux-arm-kernel@lists.infradead.org; Tue, 08 Nov 2022 12:22:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nbd.name; s=20160729; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:Cc:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fgQwEkH8uRLIyzAJvAaLR6EdvjROWR71Np+0VG6O3UU=; b=nitwdRgJEnOLhDL6edIbrobgDb JT1qJTkHeOn2LIW+8O7bbLc0R4C827LiB7LNjnFFaqhkG25Ag252h700DcaYB87k4zAUV0UUeZhxV 87CpusS+NrxvVOQNIOjRMe0QYVpHoWEgHjm1dbbAod4TT1UiIZ+YY/8pY9kyQkl0+5Nk=; Received: from p200300daa72ee1006d973cebf3767a25.dip0.t-ipconnect.de ([2003:da:a72e:e100:6d97:3ceb:f376:7a25] helo=nf.local) by ds12 with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1osNcQ-000VU5-Uc; Tue, 08 Nov 2022 13:22:19 +0100 Message-ID: <6b38ec27-65a3-c973-c5e1-a25bbe4f6104@nbd.name> Date: Tue, 8 Nov 2022 13:22:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Content-Language: en-US To: Maxime Chevallier , Jakub Kicinski Cc: davem@davemloft.net, Rob Herring , Krzysztof Kozlowski , Eric Dumazet , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, thomas.petazzoni@bootlin.com, Andrew Lunn , Florian Fainelli , Heiner Kallweit , Russell King , linux-arm-kernel@lists.infradead.org, Vladimir Oltean , Luka Perkov , Robert Marko , Andy Gross , Bjorn Andersson , Konrad Dybcio References: <20221104174151.439008-1-maxime.chevallier@bootlin.com> <20221104174151.439008-4-maxime.chevallier@bootlin.com> <20221104200530.3bbe18c6@kernel.org> <20221107093950.74de3fa1@pc-8.home> From: Felix Fietkau Subject: Re: [PATCH net-next v8 3/5] net: dsa: add out-of-band tagging protocol In-Reply-To: <20221107093950.74de3fa1@pc-8.home> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221108_042233_983192_2656ABF1 X-CRM114-Status: GOOD ( 36.61 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 07.11.22 09:39, Maxime Chevallier wrote: >> On Fri, 4 Nov 2022 18:41:49 +0100 Maxime Chevallier wrote: >> > This tagging protocol is designed for the situation where the link >> > between the MAC and the Switch is designed such that the Destination >> > Port, which is usually embedded in some part of the Ethernet >> > Header, is sent out-of-band, and isn't present at all in the >> > Ethernet frame. >> > >> > This can happen when the MAC and Switch are tightly integrated on an >> > SoC, as is the case with the Qualcomm IPQ4019 for example, where >> > the DSA tag is inserted directly into the DMA descriptors. In that >> > case, the MAC driver is responsible for sending the tag to the >> > switch using the out-of-band medium. To do so, the MAC driver needs >> > to have the information of the destination port for that skb. >> > >> > Add a new tagging protocol based on SKB extensions to convey the >> > information about the destination port to the MAC driver >> >> This is what METADATA_HW_PORT_MUX is for, you shouldn't have >> to allocate a piece of memory for every single packet. > > Does this work with DSA ? The information conveyed in the extension is > the DSA port identifier. I'm not familiar at all with > METADATA_HW_PORT_MUX, should we extend that mechanism to convey the > DSA port id ? > > I also agree that allocating data isn't the best way to go, but from > the history of this series, we've tried 3 approaches so far : > > - Adding a new field to struct sk_buff, which isn't a good idea > - Using the skb headroom, but then we can't know for sure is the skb > contains a DSA tag or not > - Using skb extensions, that comes with the cost of this memory > allocation. Is this approach also incorrect then ? FYI, I'm currently working on hardware DSA untagging on the mediatek mtk_eth_soc driver. On this hardware, I definitely need to keep the custom DSA tag driver, as hardware untagging is not always available. For the receive side, I came up with this patch (still untested) for using METADATA_HW_PORT_MUX. It has the advantage of being able to skip the tag protocol rcv ops call for offload-enabled packets. Maybe for the transmit side we could have some kind of netdev feature or capability that indicates offload support and allows skipping the tag xmit function as well. In that case, ipqess could simply use a no-op tag driver. What do you think? --- --- a/net/core/flow_dissector.c +++ b/net/core/flow_dissector.c @@ -972,11 +972,13 @@ bool __skb_flow_dissect(const struct net *net, if (unlikely(skb->dev && netdev_uses_dsa(skb->dev) && skb->protocol == htons(ETH_P_XDSA))) { const struct dsa_device_ops *ops; + struct metadata_dst *md_dst = skb_metadata_dst(skb); int offset = 0; ops = skb->dev->dsa_ptr->tag_ops; /* Only DSA header taggers break flow dissection */ - if (ops->needed_headroom) { + if (ops->needed_headroom && + (!md_dst || md_dst->type != METADATA_HW_PORT_MUX)) { if (ops->flow_dissect) ops->flow_dissect(skb, &proto, &offset); else --- a/net/dsa/dsa.c +++ b/net/dsa/dsa.c @@ -11,6 +11,7 @@ #include #include #include +#include #include "dsa_priv.h" @@ -216,6 +217,7 @@ static bool dsa_skb_defer_rx_timestamp(struct dsa_slave_priv *p, static int dsa_switch_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt, struct net_device *unused) { + struct metadata_dst *md_dst = skb_metadata_dst(skb); struct dsa_port *cpu_dp = dev->dsa_ptr; struct sk_buff *nskb = NULL; struct dsa_slave_priv *p; @@ -229,7 +231,21 @@ static int dsa_switch_rcv(struct sk_buff *skb, struct net_device *dev, if (!skb) return 0; - nskb = cpu_dp->rcv(skb, dev); + if (md_dst && md_dst->type == METADATA_HW_PORT_MUX) { + unsigned int port = md_dst->u.port_info.port_id; + + dsa_default_offload_fwd_mark(skb); + skb_dst_set(skb, NULL); + if (!skb_has_extensions(skb)) + skb->slow_gro = 0; + + skb->dev = dsa_master_find_slave(dev, 0, port); + if (skb->dev) + nskb = skb; + } else { + nskb = cpu_dp->rcv(skb, dev); + } + if (!nskb) { kfree_skb(skb); return 0; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel