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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 C9B75C2D0A3 for ; Thu, 29 Oct 2020 08:21:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5A57120732 for ; Thu, 29 Oct 2020 08:21:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=waldekranz-com.20150623.gappssmtp.com header.i=@waldekranz-com.20150623.gappssmtp.com header.b="zJDJsixi" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729250AbgJ2IU7 (ORCPT ); Thu, 29 Oct 2020 04:20:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727559AbgJ2IU6 (ORCPT ); Thu, 29 Oct 2020 04:20:58 -0400 Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1E05C0613CF for ; Thu, 29 Oct 2020 01:11:26 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id p15so2092221ljj.8 for ; Thu, 29 Oct 2020 01:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=waldekranz-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:cc:subject:from:to:date:message-id :in-reply-to; bh=0pOM50VBIVgYUcjgLqeHV2YZkQncc1S8zNRv56k4JAc=; b=zJDJsixiO0la6tuJVfYMwmw1YymnTpaGSaakpukDC9+Xy/LHlmb0OAgcqSk49Bdm2n QIH7PjykJXrqT5I5L4fT5zCxYTKOU/Ht1uybZ02KAnnaAWOXAXrFcJdn1oGhUMCqaiUk r4iLEApv9b4xF3uttTYHmNi7qyzx7r4crm7ZZzMGyGzcli0GsDKoG/7qMD/zVv09bqNL I7/B3ZKvkean+TYDKk1fR/u7Vf6xvYF8uNKcvXxDGgI7Wni2qTkjDbZrbJnfWem1fvOb gRSoei2uuMx8jAJ3EqaEtOx0gY8oOwlUfbsY+HaQB9tbSplD6RKfDTByiSoetM7hEitv H1hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:cc:subject:from:to :date:message-id:in-reply-to; bh=0pOM50VBIVgYUcjgLqeHV2YZkQncc1S8zNRv56k4JAc=; b=DZKF2z/gEblZEYfexzV5xLmfNzL14k8jBQgbl9ogTkD4QWR8vwCVVGdjxAtitUS/Ln 4XAIC9nk2GN22eKuJj+HVFgPkz7tbGAB4GtZEIjATELt4ZOFL8YIp0Hkd6POLu2x9NuX l3yyaAh/+9wSBGP17cL+PtjUl3+6rz3QnFC/Lxid1HUSSmAibjpamYbB2UzGKgKllVr7 yzT4eZLK4z2RML1FiFRbvyogorJaTS+reJ902IAL9wc7Nn2Qgkey7X74KKiwPEfIYn5G gHYOuSVhBaPbYODiagg/EDg7iwW0js7tWZXzoqEevZqlYgFk/Z43fIti3YffCLRkfjHr sEUQ== X-Gm-Message-State: AOAM533tpXLkx9pmssX7mnCjTC3ohzeF0o8I/Puvc9LFgmTMrJ+9hugh c876Gbi5CtwkJ14xdEBbax0T6Q== X-Google-Smtp-Source: ABdhPJzxPobIvsr04P+mI+QIGmNC0Rn6r3n/VRBRanwnMzAj4V9wKCfUqElzm+x9V61mn3/GuZsLng== X-Received: by 2002:a2e:8798:: with SMTP id n24mr1208094lji.317.1603959085332; Thu, 29 Oct 2020 01:11:25 -0700 (PDT) Received: from localhost (h-79-28.A259.priv.bahnhof.se. [79.136.79.28]) by smtp.gmail.com with ESMTPSA id k16sm243378ljc.39.2020.10.29.01.11.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2020 01:11:24 -0700 (PDT) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Cc: , , , , "Ido Schimmel" Subject: Re: [RFC PATCH 4/4] net: dsa: tag_edsa: support reception of packets from lag devices From: "Tobias Waldekranz" To: "Vladimir Oltean" Date: Thu, 29 Oct 2020 08:47:17 +0100 Message-Id: In-Reply-To: <20201028230858.5rgzbgdnxo2boqnd@skbuf> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu Oct 29, 2020 at 2:08 AM CET, Vladimir Oltean wrote: > On Wed, Oct 28, 2020 at 11:31:58PM +0100, Tobias Waldekranz wrote: > > The thing is, unlike L2 where the hardware will add new neighbors to > > its FDB autonomously, every entry in the hardware FIB is under the > > strict control of the CPU. So I think you can avoid much of this > > headache simply by determining if a given L3 nexthop/neighbor is > > "foreign" to the switch or not, and then just skip offloading for > > those entries. > >=20 > > You miss out on the hardware acceleration of replacing the L2 header > > of course. But my guess would be that once you have payed the tax of > > receiving the buffer via the NIC driver, allocated an skb, and called > > netif_rx() etc. the routing operation will be a rounding error. At > > least on smaller devices where the FIB is typically quite small. > > Right, but in that case, there is less of an argument to have something > like DSA injecting directly into an upper device's RX path, if only > mv88e6xxx with bonding is ever going to use that. Doesn't that basically boil down to the argument that "we can't merge this change because it's never going to be used, except for when it is used"? I don't know if I buy that. How about the inverse question: If this change is not acceptable, do you have any other suggestion on to solve it? The hardware is what it is, I can not will the source port information into existence, and injecting packets on the wrong DSA port feels even more dirty to me.