Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp5408191rwb; Mon, 14 Nov 2022 04:23:02 -0800 (PST) X-Google-Smtp-Source: AA0mqf5KUDoB4mNZ04VD4kZwQzPpLn2bi6GiMx9cwCNmrPbE5+258Zg7cmYGwHHuYgYaZuM+0Hqd X-Received: by 2002:a17:906:3e90:b0:78a:52bb:d904 with SMTP id a16-20020a1709063e9000b0078a52bbd904mr9734458ejj.630.1668428582098; Mon, 14 Nov 2022 04:23:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668428582; cv=none; d=google.com; s=arc-20160816; b=qZn/Ye/E1F2r+uRovCQtqjQRL7snlVFQVVp5lJc05rRvZKwJ/qkpF6HK3wKMegfuFi E8lUnzT5yJJy0iFYgojmwCJt1lTglfSNSWjm/hWlscFeC8dE85IxWsHzVj8zoW77NdeW OF2A8HhO1eT/GzLl7K+MJ9xQHw0tLQWEBt10ppEqhh104K1ljikj4Ku/m7jpGjs9otX6 TvTog6wzbVHkBZPmm9g1M7D+oTyYM0UlpHHUog2F3XCHOTmymuUqF7Ct/hvYZSQObfno bf4GwIYtH+cNYGNQTP3e97bdWxzHm+gy2qlCaRX3b4nuwTOismPwtP3Z4iaBwgqJmgra rHsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature; bh=zMu0HTKg3FuUP4Nz5uxf9TpO0N2V/XYeubVj5LZJiTY=; b=Fx1fLgzlz0aLT5ejFZZbGe59GCGXWo90fFSU+XXOCBH/+bri70x1g3vqGgQdz7eqln O6yEUsXiJp9X/rpON6x6N8540pS+Gyouov5/e6kK7ug32OSA+rtfFrGfVnq+KXPVFm7b fDXkW06aZfBwPmn9jDSfOkXFNgq7PoYXQ3ykCaefeEOjc6HhmIRtwCRRmCotBFMH4t1D XTGivGhw9MGvuhhZh3v2cZ11qrGg01vHl1xtVmlCA6Jkcxpr6wlTk+ev67Tb93PnPTvA OtEzcOdZ//dryOrIsjXrXCeFhxGsgqWXaBffO4u6yFSVkDt0Bm32mbDJjCp7GITHZ09w v96A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@nbd.name header.s=20160729 header.b=JRKiJ4nD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nbd.name Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t12-20020a056402524c00b004542e6bd242si9681713edd.621.2022.11.14.04.22.38; Mon, 14 Nov 2022 04:23:02 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@nbd.name header.s=20160729 header.b=JRKiJ4nD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nbd.name Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235965AbiKNMHO (ORCPT + 88 others); Mon, 14 Nov 2022 07:07:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39670 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237088AbiKNMHB (ORCPT ); Mon, 14 Nov 2022 07:07:01 -0500 Received: from nbd.name (nbd.name [46.4.11.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31B13E59; Mon, 14 Nov 2022 04:06:58 -0800 (PST) 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=zMu0HTKg3FuUP4Nz5uxf9TpO0N2V/XYeubVj5LZJiTY=; b=JRKiJ4nDH44Lp8lZYuuQJ0FbUx RAciPYCaHXxkO43oTLTNwpYvq+d7+2LFSo9Z4Orj5x0H1xIOcnkK6bmI+QoljvlP/p4GeLH4fZKfq rMf0b5zps6wzl+BdBxQ8nT9pNF5GuZrR8yZREkvcrGhtwFPpKpkdVssXKRPqpQwF+4So=; Received: from p54ae9c3f.dip0.t-ipconnect.de ([84.174.156.63] 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 1ouYEe-0021Go-GC; Mon, 14 Nov 2022 13:06:44 +0100 Message-ID: <8faa9c5d-960c-849b-e6af-a847bb1fd12f@nbd.name> Date: Mon, 14 Nov 2022 13:06:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US To: Vladimir Oltean Cc: Jakub Kicinski , netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Paolo Abeni , Andrew Lunn , Vivien Didelot , Florian Fainelli , linux-kernel@vger.kernel.org References: <20221110212212.96825-1-nbd@nbd.name> <20221110212212.96825-2-nbd@nbd.name> <20221111233714.pmbc5qvq3g3hemhr@skbuf> <20221111204059.17b8ce95@kernel.org> <20221114115559.wl7efrgxphijqz4o@skbuf> From: Felix Fietkau Subject: Re: [PATCH net-next v3 1/4] net: dsa: add support for DSA rx offloading via metadata dst In-Reply-To: <20221114115559.wl7efrgxphijqz4o@skbuf> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14.11.22 12:55, Vladimir Oltean wrote: > On Sat, Nov 12, 2022 at 12:13:15PM +0100, Felix Fietkau wrote: >> On 12.11.22 05:40, Jakub Kicinski wrote: >> I don't really see a valid use case in running generic XDP, TC and NFT on a >> DSA master dealing with packets before the tag receive function has been >> run. And after the tag has been processed, the metadata DST is cleared from >> the skb. > > Oh, there are potentially many use cases, the problem is that maybe > there aren't as many actual implementations as ideas? At least XDP is, > I think, expected to be able to deal with DSA tags if run on a DSA > master (not sure how that applies when RX DSA tag is offloaded, but > whatever). Marek Behun had a prototype with Marvell tags, not sure how > far that went in the end: > https://www.mail-archive.com/netdev@vger.kernel.org/msg381018.html > In general, forwarding a packet to another switch port belonging to the > same master via XDP_TX should be relatively efficient. In that case it likely makes sense to disable DSA tag offloading whenever driver XDP is being used. Generic XDP probably doesn't matter much. Last time I tried to use it and ran into performance issues, I was told that it's only usable for testing anyway and there was no interest in fixing the cases that I ran into. >> How about this: I send a v4 which uses skb_dst_drop instead of skb_dst_set, >> so that other drivers can use refcounting if it makes sense for them. For >> mtk_eth_soc, I prefer to leave out refcounting for performance reasons. >> Is that acceptable to you guys? > > I don't think you can mix refcounting at consumer side with no-refcounting > at producer side, no? skb_dst_drop checks if refcounting was used for the skb dst pointer. > I suppose that we could leave refcounting out for now, and bug you if > someone comes with a real need later and complains. Right now it's a bit > hard for me to imagine all the possibilities. How does that sound? Sounds good. I think I'll send v4 anyway to deal with the XDP case and to switch to skb_dst_drop. - Felix