From patchwork Tue Mar 16 11:24:10 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 402318 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=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham 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 8D851C4332B for ; Tue, 16 Mar 2021 11:25:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 456126503C for ; Tue, 16 Mar 2021 11:25:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234244AbhCPLYp (ORCPT ); Tue, 16 Mar 2021 07:24:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232625AbhCPLYd (ORCPT ); Tue, 16 Mar 2021 07:24:33 -0400 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67061C06174A for ; Tue, 16 Mar 2021 04:24:32 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id e7so21018371edu.10 for ; Tue, 16 Mar 2021 04:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=kNcIxvr5K3KWWO+wJV4eXS1fCT/KzxdI1FTVgwiyVOc=; b=ASWswAcoJzaPqrD2nNtmQWC1XVtgb0YthPIZmMlB0bBemSZvujI2X3GZFrx12ZeAfZ 0W01/9ZSMtSlBfCaTVBorojJMyAb99HzgGW9mWeWtype6UwCDVPFr0tcBDGwJQbx/MIz ocz08c4Re3ADrzzvW1OMocr0mQlAd7bqhR4EpTgS6IBWu98HqeI6EhvC1fZ+0Gy3gC9Y gi7rsV1yKDe7Iq/vT44yBisWpVOcPVUbyHVVz0qZT4xv1WQcHjcOAPMB2yTq2yRTSdTa /8vcPVdf35PKZTuZlMYRSIca6POedo9TbmmYvp5kxUHX/nUhYb8O285pLSIBLw/NStp1 wbgg== 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:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=kNcIxvr5K3KWWO+wJV4eXS1fCT/KzxdI1FTVgwiyVOc=; b=JDwMtksGkIL6REaD0zx3P94OLtk31uyPG3edzCpKKvdW0GGH4zfuhtNEcFQVogFPYP w2cRVoab9O194lzFg1oOiPY8XhNIQq7dIZtq6q4aXxPutwcukkMYRB6bDsKH7S7h9nTT 8prgSN9gQpcEHi/qitkiI2PGJRBDHHpYPr0LLSaQ3miNfmjb+Ha53yOdBBW1hGFoojvb asujolByaWn2xjvHF/I4urnzxVO9QfDDqMrPyTZpgSzJGUypRtLg5DRjsbpIwslTzoKz zk/v2slCOP+gObmtau9RnlnYY9bcuyMh7Txb3xYtA2Te/zA0TeGVaef639LgnV4Ldz9B hZDA== X-Gm-Message-State: AOAM5333ArvnWSF9vuTquF0e9qxioWMu80g7wn7rQVHiwwXEvRY9wJot x4GHCSGS10li+PLvFkzoYxL9ptt4Wno= X-Google-Smtp-Source: ABdhPJz4lp3GVFgnAMxrrm5ssx3pQxv/8KpecJFhH0XiTsJeV6WoSBNFwa75C5cild7ofmeseU4nAg== X-Received: by 2002:aa7:d1d0:: with SMTP id g16mr18897531edp.358.1615893869927; Tue, 16 Mar 2021 04:24:29 -0700 (PDT) Received: from localhost.localdomain (5-12-16-165.residential.rdsnet.ro. [5.12.16.165]) by smtp.gmail.com with ESMTPSA id y12sm9294825ejb.104.2021.03.16.04.24.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 04:24:29 -0700 (PDT) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , Tobias Waldekranz , Vladimir Oltean Subject: [PATCH v2 net-next 03/12] Documentation: networking: dsa: remove static port count from limitations Date: Tue, 16 Mar 2021 13:24:10 +0200 Message-Id: <20210316112419.1304230-4-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210316112419.1304230-1-olteanv@gmail.com> References: <20210316112419.1304230-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Vladimir Oltean After Vivien's series from 2019 containing commits 27d4d19d7c82 ("net: dsa: remove limitation of switch index value") and ab8ccae122a4 ("net: dsa: add ports list in the switch fabric"), this is basically no longer true. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli --- Documentation/networking/dsa/dsa.rst | 9 --------- 1 file changed, 9 deletions(-) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 17d1422ac085..3bca80a53a86 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -382,14 +382,6 @@ DSA data structures are defined in ``include/net/dsa.h`` as well as Design limitations ================== -Limits on the number of devices and ports ------------------------------------------ - -DSA currently limits the number of maximum switches within a tree to 4 -(``DSA_MAX_SWITCHES``), and the number of ports per switch to 12 (``DSA_MAX_PORTS``). -These limits could be extended to support larger configurations would this need -arise. - Lack of CPU/DSA network devices ------------------------------- @@ -719,7 +711,6 @@ two subsystems and get the best of both worlds. Other hanging fruits -------------------- -- making the number of ports fully dynamic and not dependent on ``DSA_MAX_PORTS`` - allowing more than one CPU/management interface: http://comments.gmane.org/gmane.linux.network/365657 - porting more drivers from other vendors: From patchwork Tue Mar 16 11:24:12 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 402319 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=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham 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 48D1BC43381 for ; Tue, 16 Mar 2021 11:25:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0BB3C6502B for ; Tue, 16 Mar 2021 11:25:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234171AbhCPLYn (ORCPT ); Tue, 16 Mar 2021 07:24:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232781AbhCPLYd (ORCPT ); Tue, 16 Mar 2021 07:24:33 -0400 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6AA2FC06175F for ; Tue, 16 Mar 2021 04:24:33 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id b16so8273822eds.7 for ; Tue, 16 Mar 2021 04:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=GA9KgPbXCjkkZMOpk0TLpFUUrFcKnH4dAm++pMGhu5w=; b=g0yjYL3Z0UTZJBCmjrPhILlc4jjnhvXRh485ONS9xWcizzVn83RB75LImgbLAOpju8 qwIJIWJnAcszuJ1OJa3lnrl8MQZ0FvA++hijJP1UEseWJpVitS3RuFo5yw1RxGvKQg1j PKM9b+pJ6OZkMWL0+HDIbVi8e4F/XRWCOkHO+RCWUW5nyyqbLUMl8qPU4b/zohTGi8CJ diipajsiS80LyVU3rLqYWCFQOpk1a1CUiK07GU9EGIQ+x0WrSZfk3w7c7oos+uWcm6SO E0JzgYWm00TO1nVaEIl05hmVB5/qJF/tuoH1ktua5sywxYsT44x2KmNJNGsJw76GiNlq i9MA== 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:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=GA9KgPbXCjkkZMOpk0TLpFUUrFcKnH4dAm++pMGhu5w=; b=m0TTD1/l7lSAqGXpYPFp1a/vxLD+Q34NRqga1e8ogKE5LCJWOuII7P0+jd+1x55JLl U8tAxqpihubX19YgGQlvLZDkxS8NynSMwJ6BkbeWS2qbB+58XbFz3934ROpp6MDAu0Az 9ZzElcK3Ho/EqIMXbtxZgRwTPP1zkRnVlpzCM2q36o6LFObWAwdeb8J7VEko/4v6FETK Xeij45TV5YgKSMACS27QQOZz/HUq7rfRBpFE7Bz30xbGq9CtuyMyOWGgRh0+kjdgENo8 zXGyFjEtCbDwXN5uQK4vjeHuSd2/X+KcNEcH5gC+iFAYnWOFYzWrKKnVuXLut53HToBA tyEw== X-Gm-Message-State: AOAM530phoCamtG8ZQblTdCmZBa6eyyQs13prlWPCShkQujPNLw98fVL vLo78GFSUDLBjAmwAz7iT+GC6sEvHdc= X-Google-Smtp-Source: ABdhPJzncDxSEzulEBaROIldXV2k5velXNnyV7gsA+nULEvWYf72gdqnhLowPn0cI4Hz+XtvR9oxdQ== X-Received: by 2002:aa7:cd54:: with SMTP id v20mr35756970edw.80.1615893871931; Tue, 16 Mar 2021 04:24:31 -0700 (PDT) Received: from localhost.localdomain (5-12-16-165.residential.rdsnet.ro. [5.12.16.165]) by smtp.gmail.com with ESMTPSA id y12sm9294825ejb.104.2021.03.16.04.24.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 04:24:31 -0700 (PDT) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , Tobias Waldekranz , Vladimir Oltean Subject: [PATCH v2 net-next 05/12] Documentation: networking: dsa: remove TODO about porting more vendor drivers Date: Tue, 16 Mar 2021 13:24:12 +0200 Message-Id: <20210316112419.1304230-6-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210316112419.1304230-1-olteanv@gmail.com> References: <20210316112419.1304230-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Vladimir Oltean On one hand, the link is dead and therefore useless. On the other hand, there are always more drivers to port, but at this stage, DSA does not need to affirm itself as the driver model to use for Ethernet-connected switches (since we already have 15 tagging protocols supported and probably more switch families from various vendors), so there is nothing actionable to do. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn --- Documentation/networking/dsa/dsa.rst | 2 -- 1 file changed, 2 deletions(-) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index ced2eb6d647a..b90a852e5329 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -699,5 +699,3 @@ Other hanging fruits - allowing more than one CPU/management interface: http://comments.gmane.org/gmane.linux.network/365657 -- porting more drivers from other vendors: - http://comments.gmane.org/gmane.linux.network/365510 From patchwork Tue Mar 16 11:24:14 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 402316 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=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham 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 BA06AC4332D for ; Tue, 16 Mar 2021 11:25:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 900C36502B for ; Tue, 16 Mar 2021 11:25:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234264AbhCPLYy (ORCPT ); Tue, 16 Mar 2021 07:24:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232921AbhCPLYf (ORCPT ); Tue, 16 Mar 2021 07:24:35 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C67AC06174A for ; Tue, 16 Mar 2021 04:24:35 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id x21so21018247eds.4 for ; Tue, 16 Mar 2021 04:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=7RxxPLuNb53DtH90pDP+Np5bAnHDIr3BhHi4g+PrkFs=; b=K0aWYiuFHLRBuIB3i7FEzK5YXPkm9PHM22/901Bf1FKXoLH66zOW843K/r9SLX76Uq N9oXrigKSF0i7gEwMJio329unZfT1U0vGPve3xetlkxIJw8eAMvKYGr/RtHe9cnxRTvi EOQ3wNAUl6jJ/K4B/zkxym9vHwapAOqDtv388EO2UfiaVWVSZd6VvljlEK5zOmjRxgVU EPwhxMF2Lzwth7bal5z7280ZJJKEgfBYfZhcVeNqJg0E2O34oTgsuWrGssrJTNtsoTRt uRsCfZ8cjkT6xuLu9C/qgUong5vXUyCHgnDf9Y4NVKSg9e9VMlQVJ8LL7pnnSBDOANpj g17Q== 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:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7RxxPLuNb53DtH90pDP+Np5bAnHDIr3BhHi4g+PrkFs=; b=iH+eGk7FwtPihElYB2yfwv92fuBMOknPBUfmuBuLT/ItfPTAU5lJMQ6TP1CR4+QcLk lvnWYhtuUsS4bgl78Bzscq8GViRLuiff5F/J+IgUcoSkFiZutzCQGvyot8TN5yetVOuP NGJVYC/COAyCRv0aoqrmkJqAp7Hnk74yhQbWcZZXKTKpFuhZG/hbtC9c1w7HJ66Mww9R eZxHI1E3JrWq/VEQyBu7Qa2a0rhmh6Ac0pp4oF1n7VK7h2v98rculC7sLIeC4pKA6IfN xGmINmVp1dBo9C2zpUj3nsiAWC7J/ndgtrBpxoSFOyEdJB0TeMQOpLya2E+qUawTGNmQ 9uDA== X-Gm-Message-State: AOAM530qpAGylf6puXOm44U9As3Gw4+NeENc2xdcosOYQqixyom6gsHs thGDCo2iOccI+qpAYbrNtrvHYCtCJro= X-Google-Smtp-Source: ABdhPJxPO8d2BXg8DJNpFRUwREkq/Z4d7wUZ9zqV7sEaK5gxFxxWKJ9i/uk1mXynTDUN2FwXooFGjw== X-Received: by 2002:a05:6402:3493:: with SMTP id v19mr30393129edc.355.1615893873720; Tue, 16 Mar 2021 04:24:33 -0700 (PDT) Received: from localhost.localdomain (5-12-16-165.residential.rdsnet.ro. [5.12.16.165]) by smtp.gmail.com with ESMTPSA id y12sm9294825ejb.104.2021.03.16.04.24.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 04:24:33 -0700 (PDT) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , Tobias Waldekranz , Vladimir Oltean Subject: [PATCH v2 net-next 07/12] Documentation: networking: dsa: mention integration with devlink Date: Tue, 16 Mar 2021 13:24:14 +0200 Message-Id: <20210316112419.1304230-8-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210316112419.1304230-1-olteanv@gmail.com> References: <20210316112419.1304230-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Vladimir Oltean Add a short summary of the devlink features supported by the DSA core. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn --- Documentation/networking/dsa/dsa.rst | 31 ++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 9c287dfd3c45..af604fe976b3 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -416,6 +416,7 @@ DSA currently leverages the following subsystems: - MDIO/PHY library: ``drivers/net/phy/phy.c``, ``mdio_bus.c`` - Switchdev:``net/switchdev/*`` - Device Tree for various of_* functions +- Devlink: ``net/core/devlink.c`` MDIO/PHY library ---------------- @@ -455,6 +456,36 @@ more specifically with its VLAN filtering portion when configuring VLANs on top of per-port slave network devices. As of today, the only SWITCHDEV objects supported by DSA are the FDB and VLAN objects. +Devlink +------- + +DSA registers one devlink device per physical switch in the fabric. +For each devlink device, every physical port (i.e. user ports, CPU ports, DSA +links or unused ports) is exposed as a devlink port. + +DSA drivers can make use of the following devlink features: +- Regions: debugging feature which allows user space to dump driver-defined + areas of hardware information in a low-level, binary format. Both global + regions as well as per-port regions are supported. It is possible to export + devlink regions even for pieces of data that are already exposed in some way + to the standard iproute2 user space programs (ip-link, bridge), like address + tables and VLAN tables. For example, this might be useful if the tables + contain additional hardware-specific details which are not visible through + the iproute2 abstraction, or it might be useful to inspect these tables on + the non-user ports too, which are invisible to iproute2 because no network + interface is registered for them. +- Params: a feature which enables user to configure certain low-level tunable + knobs pertaining to the device. Drivers may implement applicable generic + devlink params, or may add new device-specific devlink params. +- Resources: a monitoring feature which enables users to see the degree of + utilization of certain hardware tables in the device, such as FDB, VLAN, etc. +- Shared buffers: a QoS feature for adjusting and partitioning memory and frame + reservations per port and per traffic class, in the ingress and egress + directions, such that low-priority bulk traffic does not impede the + processing of high-priority critical traffic. + +For more details, consult ``Documentation/networking/devlink/``. + Device Tree ----------- From patchwork Tue Mar 16 11:24:15 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 402317 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=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham 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 E6341C43331 for ; Tue, 16 Mar 2021 11:25:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AFF0A65023 for ; Tue, 16 Mar 2021 11:25:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234318AbhCPLY4 (ORCPT ); Tue, 16 Mar 2021 07:24:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232994AbhCPLYg (ORCPT ); Tue, 16 Mar 2021 07:24:36 -0400 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 747D6C06174A for ; Tue, 16 Mar 2021 04:24:36 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id jt13so71542995ejb.0 for ; Tue, 16 Mar 2021 04:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=G8mmUAD7BKWW5pIh8nz/334IfE8cFMNkF30yLdi/DEo=; b=Wk5QQ5KlWs1BKjUE6oaB+M2/Sb7y+dcIzBxR9++Oa0n1cgIykYabDuEHF0S7n2xGTO W2ETJjMZMu0d3TfgF4Femtk/vlbMvN6QzPP3r6buoz5j1dbNPZFNYrwPRXvSPRCyz9Jm hAsWwlwwCxDXehlZdFH4UbtrzsZn2NY9YvSZGfknOwWrBVTznqUXrm7PG5kzxjopP+oY pQ7sRfXdwHAGV6hFPZO6X0uixGbFyjpjN5YKBYcg7E8dz1HsBStHXO4UX9bRBQ4pE+9K x0pBlUVbFwsfSgtzVgmLIvkM4j5ZmRuaox8g5mN11ucqhhkIu9zA38GMMed642Sa3pvl /1GQ== 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:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=G8mmUAD7BKWW5pIh8nz/334IfE8cFMNkF30yLdi/DEo=; b=N5NoXSdUdFoQsTwgXFGZYQwBOttNrwlOd3qd2xL7nmQadTH1YfzhOyQyQm7IosvLVc EU8rZ3WdmDXbYMogtIAaVDCojHVBtY5rb5TaglvXdGJ5keVYfq9NtKCDG7qJSF8ooUQa Gj5/8sgl52gnA8MN8ieZhPNbtiOjW43+ogGbQFvWKl4jCsjxrZIlvgXzdN9YrjaddCi4 4vJIKg041FOZ0/PYzuzuc08xArbiin8i+2Jt5Fu8UE8yPfq5tESZILTTv4VDRDd4J8Zq Egb1ssbJk4rzRsITLeNE5SrjJNRdgCl45yKp2xo9UwacbWOSwT7S0NQyLVihwCrbD0EE Lsog== X-Gm-Message-State: AOAM5308BO/XCoYQDra0GUJJq+HYGVob2TYHUBKL+/NxhIi2tpBQix1T GrM38nvc2dYn0eMPUHtXr+xw6ar9NCc= X-Google-Smtp-Source: ABdhPJyAQngDtIbPhD6TieGy5txJwQHudVaO9gavjk9Ht48Td9rlQl5hm7D7fwG6NPRR+5DSVXq/Lw== X-Received: by 2002:a17:907:2642:: with SMTP id ar2mr29072982ejc.145.1615893874880; Tue, 16 Mar 2021 04:24:34 -0700 (PDT) Received: from localhost.localdomain (5-12-16-165.residential.rdsnet.ro. [5.12.16.165]) by smtp.gmail.com with ESMTPSA id y12sm9294825ejb.104.2021.03.16.04.24.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 04:24:34 -0700 (PDT) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , Tobias Waldekranz , Vladimir Oltean Subject: [PATCH v2 net-next 08/12] Documentation: networking: dsa: add paragraph for the LAG offload Date: Tue, 16 Mar 2021 13:24:15 +0200 Message-Id: <20210316112419.1304230-9-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210316112419.1304230-1-olteanv@gmail.com> References: <20210316112419.1304230-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Vladimir Oltean Add a short summary of the methods that a driver writer must implement for offloading a link aggregation group, and what is still missing. Cc: Tobias Waldekranz Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli --- Documentation/networking/dsa/dsa.rst | 33 ++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index af604fe976b3..e8576e81735c 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -724,6 +724,39 @@ Bridge VLAN filtering function that the driver has to call for each MAC address known to be behind the given port. A switchdev object is used to carry the VID and MDB info. +Link aggregation +---------------- + +Link aggregation is implemented in the Linux networking stack by the bonding +and team drivers, which are modeled as virtual, stackable network interfaces. +DSA is capable of offloading a link aggregation group (LAG) to hardware that +supports the feature, and supports bridging between physical ports and LAGs, +as well as between LAGs. A bonding/team interface which holds multiple physical +ports constitutes a logical port, although DSA has no explicit concept of a +logical port at the moment. Due to this, events where a LAG joins/leaves a +bridge are treated as if all individual physical ports that are members of that +LAG join/leave the bridge. Switchdev port attributes (VLAN filtering, STP +state, etc) and objects (VLANs, MDB entries) offloaded to a LAG as bridge port +are treated similarly: DSA offloads the same switchdev object / port attribute +on all members of the LAG. Static bridge FDB entries on a LAG are not yet +supported, since the DSA driver API does not have the concept of a logical port +ID. + +- ``port_lag_join``: function invoked when a given switch port is added to a + LAG. The driver may return ``-EOPNOTSUPP``, and in this case, DSA will fall + back to a software implementation where all traffic from this port is sent to + the CPU. +- ``port_lag_leave``: function invoked when a given switch port leaves a LAG + and returns to operation as a standalone port. +- ``port_lag_change``: function invoked when the link state of any member of + the LAG changes, and the hashing function needs rebalancing to only make use + of the subset of physical LAG member ports that are up. + +Drivers that benefit from having an ID associated with each offloaded LAG +can optionally populate ``ds->num_lag_ids`` from the ``dsa_switch_ops::setup`` +method. The LAG ID associated with a bonding/team interface can then be +retrieved by a DSA switch driver using the ``dsa_lag_id`` function. + TODO ==== From patchwork Tue Mar 16 11:24:17 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 402315 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=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham 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 1DA15C4332E for ; Tue, 16 Mar 2021 11:25:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E479965027 for ; Tue, 16 Mar 2021 11:25:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234565AbhCPLZP (ORCPT ); Tue, 16 Mar 2021 07:25:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39952 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233801AbhCPLYi (ORCPT ); Tue, 16 Mar 2021 07:24:38 -0400 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42BADC061756 for ; Tue, 16 Mar 2021 04:24:38 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id dm8so21050029edb.2 for ; Tue, 16 Mar 2021 04:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=0WpW69oiat4AL/7w4xQSBuoH/oWbmSWU7a7v5E8qqiQ=; b=CMjDT384YMzd4wobuTGXuKG0PgXxyiaBEXNvJCVINBKhW1HdSbH8k57W1H4Ew6GQrk 8tEZ+6b613kyeMifInEqRZ9m3sMT0zVrzM8yUQaEO2ZZOYw3LyXQlWIsGDQJ8Vgpx+tO FK821w2b/wAjmsuoZh4TqYVInTQsQKWil91RWE8bKl2EPTGhvMcj2ZRWPHfv61fglhCA N4MUK8Lq9rkNDYtgRp6C4i7otoJvttEta1H7KMeFH6rBg2ZQO1ZPyP6RAXllK0tuPob8 q7Z+XaDIOAy+RS8d32+KiQ1x4dmXJWOUpKdsGTD4o+1bDzZTXTDhiGnt+8Nw+dc6Zadn 3jww== 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:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=0WpW69oiat4AL/7w4xQSBuoH/oWbmSWU7a7v5E8qqiQ=; b=pF9OYLoIVJsMEvsiPL9Mz72qVht96fqs3Cxh7BHuAfFsz3LyYx4jLEndcPZFQSNUpB 4WEtXwhrMoByvWMAOpcrs6f+LhoIxlyNVHtoYY78iLsgjvJs+FGgFZ83XdUUuhdxs0sB E9W+MeVOVUcdLDWjAnkbNhhGkOebRIPc6aRCnxf/27DTuZpSnJXtZcw1VZWYIumzowB2 OgaUjlbLlsFWtIgKh6bpRNFwGTpZFTxXusUWih6tO6q0+pi6UF6BTfkRQBO6zE2SKAY7 7SoeOlpv7LP8cL4z/5Md5NFN+V7MoSqc9i09O+aEcu9IVdTARwF1r9pqsw3yP02YWswB zR4g== X-Gm-Message-State: AOAM530aSdR27xYL9RGKVfLdwT4pGRV2BPQwWW0RbekWq730mBZI43dK qrJOoOzRMqa4vKscyUB5wxgEW5AileQ= X-Google-Smtp-Source: ABdhPJzE6fidlH8F/qPlZrg7JVftCcYvAmknxOfbEh8tIK4GouNtgSDoLR4QWV6ww/ODfEjx75qezg== X-Received: by 2002:aa7:db01:: with SMTP id t1mr35605918eds.77.1615893876828; Tue, 16 Mar 2021 04:24:36 -0700 (PDT) Received: from localhost.localdomain (5-12-16-165.residential.rdsnet.ro. [5.12.16.165]) by smtp.gmail.com with ESMTPSA id y12sm9294825ejb.104.2021.03.16.04.24.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 04:24:36 -0700 (PDT) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , Tobias Waldekranz , Vladimir Oltean , George McCollister Subject: [PATCH v2 net-next 10/12] Documentation: networking: dsa: add paragraph for the HSR/PRP offload Date: Tue, 16 Mar 2021 13:24:17 +0200 Message-Id: <20210316112419.1304230-11-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210316112419.1304230-1-olteanv@gmail.com> References: <20210316112419.1304230-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Vladimir Oltean Add a short summary of the methods that a driver writer must implement for offloading a HSR/PRP network interface. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: George McCollister --- Documentation/networking/dsa/dsa.rst | 32 ++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 0daafa2fb9eb..69040e11ee5e 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -787,6 +787,38 @@ to work properly. The operations are detailed below. which MRP PDUs should be trapped to software and which should be autonomously forwarded. +IEC 62439-3 (HSR/PRP) +--------------------- + +The Parallel Redundancy Protocol (PRP) is a network redundancy protocol which +works by duplicating and sequence numbering packets through two independent L2 +networks (which are unaware of the PRP tail tags carried in the packets), and +eliminating the duplicates at the receiver. The High-availability Seamless +Redundancy (HSR) protocol is similar in concept, except all nodes that carry +the redundant traffic are aware of the fact that it is HSR-tagged (because HSR +uses a header with an EtherType of 0x892f) and are physically connected in a +ring topology. Both HSR and PRP use supervision frames for monitoring the +health of the network and for discovery of other nodes. + +In Linux, both HSR and PRP are implemented in the hsr driver, which +instantiates a virtual, stackable network interface with two member ports. +The driver only implements the basic roles of DANH (Doubly Attached Node +implementing HSR) and DANP (Doubly Attached Node implementing PRP); the roles +of RedBox and QuadBox are not implemented (therefore, bridging a hsr network +interface with a physical switch port does not produce the expected result). + +A driver which is able of offloading certain functions of a DANP or DANH should +declare the corresponding netdev features as indicated by the documentation at +``Documentation/networking/netdev-features.rst``. Additionally, the following +methods must be implemented: + +- ``port_hsr_join``: function invoked when a given switch port is added to a + DANP/DANH. The driver may return ``-EOPNOTSUPP`` and in this case, DSA will + fall back to a software implementation where all traffic from this port is + sent to the CPU. +- ``port_hsr_leave``: function invoked when a given switch port leaves a + DANP/DANH and returns to normal operation as a standalone port. + TODO ==== From patchwork Tue Mar 16 11:24:18 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 402314 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=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham 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 422CCC43332 for ; Tue, 16 Mar 2021 11:25:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 23EBD6502A for ; Tue, 16 Mar 2021 11:25:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234636AbhCPLZ2 (ORCPT ); Tue, 16 Mar 2021 07:25:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234049AbhCPLYk (ORCPT ); Tue, 16 Mar 2021 07:24:40 -0400 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58320C06174A for ; Tue, 16 Mar 2021 04:24:39 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id y6so20992010eds.1 for ; Tue, 16 Mar 2021 04:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Eg9THuLsg7vrGGYOXORia/rek6lJG57hpLgitqjmlMs=; b=QNpaNVeJdIHrKEcpog8kl9gRt0oCzq72F03ueRayfHXL+u/8GerU2WIrZbDS8tT4RC ARTWl0QDoYb4wDkD7tXdG+pruGVv+X9r2VvQm74k3GBP4b/taGcX/TQZlWBVSWFstU9a 3D+Iud3etqlIjfXaN70Wea3aFScTOjfUVg3XBbiTxElNLq7qNr+eVX6gO1EOdmZjW33q FvIpNXSbYFe6fz2h48fik2Pwgx8qf+FQtSgzxRMOuJNPZwKHTYgUQBOe2PNU9wCmQ4yu cDBJksZP7nN2c4DCQkR6SPMYM555Jf+GCfpdeR9YDfunAKbksqEVW4ovuryiW++cTDqt y24A== 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:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Eg9THuLsg7vrGGYOXORia/rek6lJG57hpLgitqjmlMs=; b=hqBSwEffp6zASXueDXrq+fkfC+f006dUgQOHgBrK2+16GmfuCQzTyhqnlpZGuCxKxu D6fCUwM8vJSREpeFLAwFlNVp8I0V7nSXr9JXaaKbKVOQtGMR7fZzUoyAkCR0llWN3Msq 2RnKUe0YRGAtNW7BAkCuwYKXUtdoRgyRTRAGNwrEPdZUKFiF/li6Q5jc2J4iyGOwXnyd xSb2ESq0L63UR0pEzVeVxk6RWxuzaz87UXfJ3WFklzAY07sO2B5CXsOS9XbzoQThzG6N 4jtfpGS84p7DC3QZzHUjJV/qaA81Jp/7yOgFKUDJszlWoxwabG+rl8JDCRH46OFudXnp Wy8Q== X-Gm-Message-State: AOAM530FoK/lRKLrYtsnwYKfQwOR2hugQvcilQzd4RzW2pyGVvxyo/Af YjsvkDsAPNInXozeR+qEaL1275Q19g4= X-Google-Smtp-Source: ABdhPJx6RfP+k8p1rxC3su7sV03apRM9lGDJgCeFDILs4TN8ahhO5o0egUCSzgf17el48a83Kbw6MA== X-Received: by 2002:a05:6402:51cd:: with SMTP id r13mr35752100edd.116.1615893877735; Tue, 16 Mar 2021 04:24:37 -0700 (PDT) Received: from localhost.localdomain (5-12-16-165.residential.rdsnet.ro. [5.12.16.165]) by smtp.gmail.com with ESMTPSA id y12sm9294825ejb.104.2021.03.16.04.24.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 04:24:37 -0700 (PDT) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , Tobias Waldekranz , Vladimir Oltean Subject: [PATCH v2 net-next 11/12] Documentation: networking: switchdev: clarify device driver behavior Date: Tue, 16 Mar 2021 13:24:18 +0200 Message-Id: <20210316112419.1304230-12-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210316112419.1304230-1-olteanv@gmail.com> References: <20210316112419.1304230-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Florian Fainelli This patch provides details on the expected behavior of switchdev enabled network devices when operating in a "stand alone" mode, as well as when being bridge members. This clarifies a number of things that recently came up during a bug fixing session on the b53 DSA switch driver. Signed-off-by: Florian Fainelli Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Reviewed-by: Ido Schimmel --- Documentation/networking/switchdev.rst | 152 +++++++++++++++++++++++++ 1 file changed, 152 insertions(+) diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst index ddc3f35775dc..016531a3d471 100644 --- a/Documentation/networking/switchdev.rst +++ b/Documentation/networking/switchdev.rst @@ -385,3 +385,155 @@ The driver can monitor for updates to arp_tbl using the netevent notifier NETEVENT_NEIGH_UPDATE. The device can be programmed with resolved nexthops for the routes as arp_tbl updates. The driver implements ndo_neigh_destroy to know when arp_tbl neighbor entries are purged from the port. + +Device driver expected behavior +------------------------------- + +Below is a set of defined behavior that switchdev enabled network devices must +adhere to. + +Configuration-less state +^^^^^^^^^^^^^^^^^^^^^^^^ + +Upon driver bring up, the network devices must be fully operational, and the +backing driver must configure the network device such that it is possible to +send and receive traffic to this network device and it is properly separated +from other network devices/ports (e.g.: as is frequent with a switch ASIC). How +this is achieved is heavily hardware dependent, but a simple solution can be to +use per-port VLAN identifiers unless a better mechanism is available +(proprietary metadata for each network port for instance). + +The network device must be capable of running a full IP protocol stack +including multicast, DHCP, IPv4/6, etc. If necessary, it should program the +appropriate filters for VLAN, multicast, unicast etc. The underlying device +driver must effectively be configured in a similar fashion to what it would do +when IGMP snooping is enabled for IP multicast over these switchdev network +devices and unsolicited multicast must be filtered as early as possible in +the hardware. + +When configuring VLANs on top of the network device, all VLANs must be working, +irrespective of the state of other network devices (e.g.: other ports being part +of a VLAN-aware bridge doing ingress VID checking). See below for details. + +If the device implements e.g.: VLAN filtering, putting the interface in +promiscuous mode should allow the reception of all VLAN tags (including those +not present in the filter(s)). + +Bridged switch ports +^^^^^^^^^^^^^^^^^^^^ + +When a switchdev enabled network device is added as a bridge member, it should +not disrupt any functionality of non-bridged network devices and they +should continue to behave as normal network devices. Depending on the bridge +configuration knobs below, the expected behavior is documented. + +Bridge VLAN filtering +^^^^^^^^^^^^^^^^^^^^^ + +The Linux bridge allows the configuration of a VLAN filtering mode (statically, +at device creation time, and dynamically, during run time) which must be +observed by the underlying switchdev network device/hardware: + +- with VLAN filtering turned off: the bridge is strictly VLAN unaware and its + data path will process all Ethernet frames as if they are VLAN-untagged. + The bridge VLAN database can still be modified, but the modifications should + have no effect while VLAN filtering is turned off. Frames ingressing the + device with a VID that is not programmed into the bridge/switch's VLAN table + must be forwarded and may be processed using a VLAN device (see below). + +- with VLAN filtering turned on: the bridge is VLAN-aware and frames ingressing + the device with a VID that is not programmed into the bridges/switch's VLAN + table must be dropped (strict VID checking). + +When there is a VLAN device (e.g: sw0p1.100) configured on top of a switchdev +network device which is a bridge port member, the behavior of the software +network stack must be preserved, or the configuration must be refused if that +is not possible. + +- with VLAN filtering turned off, the bridge will process all ingress traffic + for the port, except for the traffic tagged with a VLAN ID destined for a + VLAN upper. The VLAN upper interface (which consumes the VLAN tag) can even + be added to a second bridge, which includes other switch ports or software + interfaces. Some approaches to ensure that the forwarding domain for traffic + belonging to the VLAN upper interfaces are managed properly: + * If forwarding destinations can be managed per VLAN, the hardware could be + configured to map all traffic, except the packets tagged with a VID + belonging to a VLAN upper interface, to an internal VID corresponding to + untagged packets. This internal VID spans all ports of the VLAN-unaware + bridge. The VID corresponding to the VLAN upper interface spans the + physical port of that VLAN interface, as well as the other ports that + might be bridged with it. + * Treat bridge ports with VLAN upper interfaces as standalone, and let + forwarding be handled in the software data path. + +- with VLAN filtering turned on, these VLAN devices can be created as long as + the bridge does not have an existing VLAN entry with the same VID on any + bridge port. These VLAN devices cannot be enslaved into the bridge since they + duplicate functionality/use case with the bridge's VLAN data path processing. + +Non-bridged network ports of the same switch fabric must not be disturbed in any +way by the enabling of VLAN filtering on the bridge device(s). If the VLAN +filtering setting is global to the entire chip, then the standalone ports +should indicate to the network stack that VLAN filtering is required by setting +'rx-vlan-filter: on [fixed]' in the ethtool features. + +Because VLAN filtering can be turned on/off at runtime, the switchdev driver +must be able to reconfigure the underlying hardware on the fly to honor the +toggling of that option and behave appropriately. If that is not possible, the +switchdev driver can also refuse to support dynamic toggling of the VLAN +filtering knob at runtime and require a destruction of the bridge device(s) and +creation of new bridge device(s) with a different VLAN filtering value to +ensure VLAN awareness is pushed down to the hardware. + +Even when VLAN filtering in the bridge is turned off, the underlying switch +hardware and driver may still configure itself in a VLAN-aware mode provided +that the behavior described above is observed. + +The VLAN protocol of the bridge plays a role in deciding whether a packet is +treated as tagged or not: a bridge using the 802.1ad protocol must treat both +VLAN-untagged packets, as well as packets tagged with 802.1Q headers, as +untagged. + +The 802.1p (VID 0) tagged packets must be treated in the same way by the device +as untagged packets, since the bridge device does not allow the manipulation of +VID 0 in its database. + +When the bridge has VLAN filtering enabled and a PVID is not configured on the +ingress port, untagged 802.1p tagged packets must be dropped. When the bridge +has VLAN filtering enabled and a PVID exists on the ingress port, untagged and +priority-tagged packets must be accepted and forwarded according to the +bridge's port membership of the PVID VLAN. When the bridge has VLAN filtering +disabled, the presence/lack of a PVID should not influence the packet +forwarding decision. + +Bridge IGMP snooping +^^^^^^^^^^^^^^^^^^^^ + +The Linux bridge allows the configuration of IGMP snooping (statically, at +interface creation time, or dynamically, during runtime) which must be observed +by the underlying switchdev network device/hardware in the following way: + +- when IGMP snooping is turned off, multicast traffic must be flooded to all + ports within the same bridge that have mcast_flood=true. The CPU/management + port should ideally not be flooded (unless the ingress interface has + IFF_ALLMULTI or IFF_PROMISC) and continue to learn multicast traffic through + the network stack notifications. If the hardware is not capable of doing that + then the CPU/management port must also be flooded and multicast filtering + happens in software. + +- when IGMP snooping is turned on, multicast traffic must selectively flow + to the appropriate network ports (including CPU/management port). Flooding of + unknown multicast should be only towards the ports connected to a multicast + router (the local device may also act as a multicast router). + +The switch must adhere to RFC 4541 and flood multicast traffic accordingly +since that is what the Linux bridge implementation does. + +Because IGMP snooping can be turned on/off at runtime, the switchdev driver +must be able to reconfigure the underlying hardware on the fly to honor the +toggling of that option and behave appropriately. + +A switchdev driver can also refuse to support dynamic toggling of the multicast +snooping knob at runtime and require the destruction of the bridge device(s) +and creation of a new bridge device(s) with a different multicast snooping +value.