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 2B681C433B4 for ; Tue, 4 May 2021 21:24:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0168F613DB for ; Tue, 4 May 2021 21:24:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232883AbhEDVZx (ORCPT ); Tue, 4 May 2021 17:25:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232684AbhEDVZw (ORCPT ); Tue, 4 May 2021 17:25:52 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F4F8C061574 for ; Tue, 4 May 2021 14:24:56 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id 12so15344732lfq.13 for ; Tue, 04 May 2021 14:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=waldekranz-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=uliylMPA3scQqPaauQbVrIOixvG300bg8trmMivqpf0=; b=KFS/nGi1eolFwtYT6NELDRAushYNsu4vIKv4FZrf5JKt3IoYJpFAKmQ5N2iEM8luNG ceizYfDegDgvfioz0FPWRlwC+BT5vAMxYunFnXn2LhPKuPlM1tYcMOeR0dZjdQe8Z15u gy7rBvCZNqyYja5VimuxEyBvGWat3pHV3Jf1IRCYOmiAE9bRmKijSHtakap5UPWv2vau 38Wy4IkGaSyt1i4MVG4A0ZWLai8LpQAujiWkwux58NTsnUu8hy3zNs0DetSbMUXm1sLR LTVd6+KiS3JofDeIFk1c+wTrLdb8XNBPo0W5ZwqHnmXSXmrD5LU91i23TYmoWNw1HulN lp6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=uliylMPA3scQqPaauQbVrIOixvG300bg8trmMivqpf0=; b=c4jhsJNkE1QQHDjG/Cxml0HebJUqGxJ37zwhxGp87iB9SwQ/vOx84iV46Wae48bv9C pf0n3cwy1oij6szW/wuw06NqODRo/4hes0sY5gNs4+GqQnNB05+Rnwrz+WlCwPoXgePv xMaw0vwqqcDG90CchHJo5sE1uB0zc4vzlEB9Wu6T3oEgN4ylmh1FJj+RHvY0BDIecky4 V1gLQAmcgSNz4yOz0wMCOEO9PVlRWWhdhf9RD1RoK+RyVXOuR0/yOvQ8cWGLH+xnS4m0 BsLRGRMdFxxcmalevgUeL/ObiD23I27JIhKEm13uEZAOOXtLNomrIiU5Cfw2ylnGuAGM 6sXg== X-Gm-Message-State: AOAM532GZBBubD8o9aUgmRJQgSq31OUsqeoO60MRro4ZPG5ySUMedcCp bIrszmHK1i1rrZ/MAgphGL7Z7A== X-Google-Smtp-Source: ABdhPJwOz299VrftPbCO7qLkDc3Ng/aTngBk9v/lnjlgXm+ouCEQ5CFF+JF2+FXdX1vkFuu+ce2pMw== X-Received: by 2002:a05:6512:693:: with SMTP id t19mr6651918lfe.91.1620163494568; Tue, 04 May 2021 14:24:54 -0700 (PDT) Received: from wkz-x280 (h-90-88.A259.priv.bahnhof.se. [212.85.90.88]) by smtp.gmail.com with ESMTPSA id i7sm361703lfv.126.2021.05.04.14.24.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 May 2021 14:24:53 -0700 (PDT) From: Tobias Waldekranz To: Andrew Lunn Cc: Vladimir Oltean , davem@davemloft.net, kuba@kernel.org, vivien.didelot@gmail.com, f.fainelli@gmail.com, roopa@nvidia.com, nikolay@nvidia.com, jiri@resnulli.us, idosch@idosch.org, stephen@networkplumber.org, netdev@vger.kernel.org, bridge@lists.linux-foundation.org Subject: Re: [RFC net-next 6/9] net: dsa: Forward offloading In-Reply-To: References: <20210426170411.1789186-1-tobias@waldekranz.com> <20210426170411.1789186-7-tobias@waldekranz.com> <20210427101747.n3y6w6o7thl5cz3r@skbuf> <878s4uo8xc.fsf@waldekranz.com> <20210504152106.oppawchuruapg4sb@skbuf> <874kfintzh.fsf@waldekranz.com> Date: Tue, 04 May 2021 23:24:52 +0200 Message-ID: <871ramnqe3.fsf@waldekranz.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, May 04, 2021 at 22:33, Andrew Lunn wrote: >> There is really no need to recompute the static parts of the tags on >> each skb. It would mean moving some knowledge of the tagging format to >> the driver. But that boundary is pretty artificial for >> mv88e6xxx. tag_dsa has no use outside of mv88e6xxx, and mv88e6xxx does >> not work with any other tagger. I suppose you could even move the whole >> tagger to drivers/net/dsa/mv88e6xxx/? >> >> What do you think? >> >> Andrew? > > We have resisted this before. > > What information do you actually need to share between the tagger and > the driver? So far: - Trunk/LAG ID to netdev mappings (this is stored on the dst now, but I think I have seen the light and agree with Vladimir that it really has no business there). - DSA dev/port to bridge netdev mappings for the forwarding offloading in this RFC (or preferably the actual tag templates to use on egress since that would probably give you better performance) In the future: - Completions for in-flight remote management operations. - FlowID to TC rule mappings (from the "Switch Egress header" when we enable that) - In-band signaling between firmware running on the IMP and the driver for things like MRP and CFM offloading. > Both tag_lan9303.c and tag_ocelot_8021q.c do reference > their switch driver data structures, so some sharing is allowed. But > please try to keep the surface areas down. If you have a surface area keep it small, yes, agreed. I guess my question is more why we should have any surface area at all? What do we gain by the tagger/driver separation in the case of mv88e6xxx? > Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=waldekranz-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=uliylMPA3scQqPaauQbVrIOixvG300bg8trmMivqpf0=; b=KFS/nGi1eolFwtYT6NELDRAushYNsu4vIKv4FZrf5JKt3IoYJpFAKmQ5N2iEM8luNG ceizYfDegDgvfioz0FPWRlwC+BT5vAMxYunFnXn2LhPKuPlM1tYcMOeR0dZjdQe8Z15u gy7rBvCZNqyYja5VimuxEyBvGWat3pHV3Jf1IRCYOmiAE9bRmKijSHtakap5UPWv2vau 38Wy4IkGaSyt1i4MVG4A0ZWLai8LpQAujiWkwux58NTsnUu8hy3zNs0DetSbMUXm1sLR LTVd6+KiS3JofDeIFk1c+wTrLdb8XNBPo0W5ZwqHnmXSXmrD5LU91i23TYmoWNw1HulN lp6w== From: Tobias Waldekranz In-Reply-To: References: <20210426170411.1789186-1-tobias@waldekranz.com> <20210426170411.1789186-7-tobias@waldekranz.com> <20210427101747.n3y6w6o7thl5cz3r@skbuf> <878s4uo8xc.fsf@waldekranz.com> <20210504152106.oppawchuruapg4sb@skbuf> <874kfintzh.fsf@waldekranz.com> Date: Tue, 04 May 2021 23:24:52 +0200 Message-ID: <871ramnqe3.fsf@waldekranz.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Bridge] [RFC net-next 6/9] net: dsa: Forward offloading List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew Lunn Cc: f.fainelli@gmail.com, jiri@resnulli.us, netdev@vger.kernel.org, bridge@lists.linux-foundation.org, vivien.didelot@gmail.com, idosch@idosch.org, nikolay@nvidia.com, roopa@nvidia.com, kuba@kernel.org, Vladimir Oltean , davem@davemloft.net On Tue, May 04, 2021 at 22:33, Andrew Lunn wrote: >> There is really no need to recompute the static parts of the tags on >> each skb. It would mean moving some knowledge of the tagging format to >> the driver. But that boundary is pretty artificial for >> mv88e6xxx. tag_dsa has no use outside of mv88e6xxx, and mv88e6xxx does >> not work with any other tagger. I suppose you could even move the whole >> tagger to drivers/net/dsa/mv88e6xxx/? >> >> What do you think? >> >> Andrew? > > We have resisted this before. > > What information do you actually need to share between the tagger and > the driver? So far: - Trunk/LAG ID to netdev mappings (this is stored on the dst now, but I think I have seen the light and agree with Vladimir that it really has no business there). - DSA dev/port to bridge netdev mappings for the forwarding offloading in this RFC (or preferably the actual tag templates to use on egress since that would probably give you better performance) In the future: - Completions for in-flight remote management operations. - FlowID to TC rule mappings (from the "Switch Egress header" when we enable that) - In-band signaling between firmware running on the IMP and the driver for things like MRP and CFM offloading. > Both tag_lan9303.c and tag_ocelot_8021q.c do reference > their switch driver data structures, so some sharing is allowed. But > please try to keep the surface areas down. If you have a surface area keep it small, yes, agreed. I guess my question is more why we should have any surface area at all? What do we gain by the tagger/driver separation in the case of mv88e6xxx? > Andrew