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 X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83D20C33CB1 for ; Wed, 15 Jan 2020 07:38:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 573E4222C3 for ; Wed, 15 Jan 2020 07:38:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=dlink.ru header.i=@dlink.ru header.b="gmIFfkyP" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729211AbgAOHii (ORCPT ); Wed, 15 Jan 2020 02:38:38 -0500 Received: from fd.dlink.ru ([178.170.168.18]:46316 "EHLO fd.dlink.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726088AbgAOHih (ORCPT ); Wed, 15 Jan 2020 02:38:37 -0500 Received: by fd.dlink.ru (Postfix, from userid 5000) id BCF101B21254; Wed, 15 Jan 2020 10:38:34 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 fd.dlink.ru BCF101B21254 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dlink.ru; s=mail; t=1579073914; bh=CxEiSPavtIlJWlMwr6AuhfGibqHNMwLCY9kUK5W5q30=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=gmIFfkyPm7iywN2d5hK4aX1BTbGnYfpazghsAal7Udzm/YlHKT66E8AVZ7t4B/+Vz k1q9WjqvGlMMytMVqviW5Px4tIEIgq6zYg93koqXYOseMEGSXMNw21krlaTuEAVQwz KU74WOHtFFH7yj706gojdHFav+KiqJGciyAjd/cM= Received: from mail.rzn.dlink.ru (mail.rzn.dlink.ru [178.170.168.13]) by fd.dlink.ru (Postfix) with ESMTP id 257691B20968; Wed, 15 Jan 2020 10:38:21 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 fd.dlink.ru 257691B20968 Received: from mail.rzn.dlink.ru (localhost [127.0.0.1]) by mail.rzn.dlink.ru (Postfix) with ESMTP id 243EB1B21422; Wed, 15 Jan 2020 10:38:20 +0300 (MSK) Received: from mail.rzn.dlink.ru (localhost [127.0.0.1]) by mail.rzn.dlink.ru (Postfix) with ESMTPA; Wed, 15 Jan 2020 10:38:20 +0300 (MSK) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 15 Jan 2020 10:38:19 +0300 From: Alexander Lobakin To: Florian Fainelli Cc: Vladimir Oltean , "David S. Miller" , Edward Cree , Andrew Lunn , Vivien Didelot , Hauke Mehrtens , Sean Wang , Matthias Brugger , Jiri Pirko , Eric Dumazet , Paolo Abeni , Jakub Kicinski , Taehee Yoo , Stephen Hemminger , Stanislav Fomichev , Daniel Borkmann , Song Liu , Matteo Croce , Jakub Sitnicki , Paul Blakey , Yoshiki Komachi , netdev , lkml , "moderated list:ARM/Mediatek SoC support" , "moderated list:ARM/Mediatek SoC support" Subject: Re: [PATCH RFC net-next 05/19] net: dsa: tag_ar9331: add GRO callbacks In-Reply-To: <129bf2bc-c0e9-02a3-7d40-0f7920803769@gmail.com> References: <20191230143028.27313-1-alobakin@dlink.ru> <20191230143028.27313-6-alobakin@dlink.ru> <0002a7388dfd5fb70db4b43a6c521c52@dlink.ru> <129bf2bc-c0e9-02a3-7d40-0f7920803769@gmail.com> User-Agent: Roundcube Webmail/1.4.0 Message-ID: X-Sender: alobakin@dlink.ru Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Florian Fainelli wrote 15.01.2020 00:56: > On 1/13/20 2:28 AM, Vladimir Oltean wrote: >> On Mon, 13 Jan 2020 at 11:46, Alexander Lobakin >> wrote: >>> >>> Vladimir Oltean wrote 13.01.2020 12:42: >>>> Hi Alexander, >>>> >>>> On Mon, 13 Jan 2020 at 11:22, Alexander Lobakin >>>> wrote: >>>>> >>>>> CPU ports can't be bridged anyway >>>>> >>>>> Regards, >>>>> ᚷ ᛖ ᚢ ᚦ ᚠ ᚱ >>>> >>>> The fact that CPU ports can't be bridged is already not ideal. >>>> One can have a DSA switch with cascaded switches on each port, so it >>>> acts like N DSA masters (not as DSA links, since the taggers are >>>> incompatible), with each switch forming its own tree. It is >>>> desirable >>>> that the ports of the DSA switch on top are bridged, so that >>>> forwarding between cascaded switches does not pass through the CPU. >>> >>> Oh, I see. But currently DSA infra forbids the adding DSA masters to >>> bridges IIRC. Can't name it good or bad decision, but was introduced >>> to prevent accidental packet flow breaking on DSA setups. >>> >> >> I just wanted to point out that some people are going to be looking at >> ways by which the ETH_P_XDSA handler can be made to play nice with the >> master's rx_handler, and that it would be nice to at least not make >> the limitation worse than it is by converting everything to >> rx_handlers (which "currently" can't be stacked, from the comments in >> netdevice.h). > > I am not sure this would change the situation much, today we cannot > have > anything but switch tags travel on the DSA master network device, > whether we accomplish the RX tap through a special skb->protocol value > or via rx_handler, it probably does not functionally matter, but it > could change the performance. As for now, I think that we should keep this RFC as it is so developers working with different DSA switches could test it or implement GRO offload for other taggers like DSA and EDSA, *but* any future work on this should come only when we'll revise/reimagine basic DSA packet flow, as we already know (at least me and Florian reproduce it well) that the current path through unlikely branches in eth_type_trans() and frame capturing through packet_type is so suboptimal that nearly destroys overall performance on several setups. Switching to net_device::rx_handler() is just one of all the possible variants, I'm sure we'll find the best solution together. Regards, ᚷ ᛖ ᚢ ᚦ ᚠ ᚱ