From patchwork Tue Mar 16 11:24:08 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12141987 X-Patchwork-Delegate: kuba@kernel.org 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 0B48BC433E0 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 B927465018 for ; Tue, 16 Mar 2021 11:25:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234013AbhCPLYj (ORCPT ); Tue, 16 Mar 2021 07:24:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232320AbhCPLYa (ORCPT ); Tue, 16 Mar 2021 07:24:30 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87301C06174A for ; Tue, 16 Mar 2021 04:24:29 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id ox4so55859340ejb.11 for ; Tue, 16 Mar 2021 04:24:29 -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=+sscrZfx852jdNoCdkU3M4svDACOXt6VG5XQsbu8SBk=; b=O+NzD7sgGrMlSQZojqClgNh/ql4M6olEgNSYzk5wRmIWt2wQQ+VW1gZNu51Q+IzNC8 SYI5WJgHi8nTBBY5bM+2Db7h/WZl/t7sL9KkaRHv8VST1oMC+XtmtuGiFvyVv25UMlWf LJao5Lei0bKSvHwE/GCtqv6mQj1alIp8lCL+ktqTDU1Uinfw4d/nMcBLRXoyjOAYSsR5 ORIAXf4BnHUfgic6eKWJTquMVqt7o0j15kmQ9KW0uDt9u/Rdf8g6DT2QujbX9HyKy7hU XHmzvl6WI7tfjIRqJLeiGVSjxxD5B96QYwtQ/vjvsXkW2+vrHv1MxrqIKyvv7ATJihjj b3WQ== 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=+sscrZfx852jdNoCdkU3M4svDACOXt6VG5XQsbu8SBk=; b=Gnw7Z+ZhyGcB0aIeXM+oSk1iI+S2mi/MRJx9HrJEtgRWWTxj9lYKXaEiqqq36IePoH 01LLts8fUH1h57hZJMoqKl0+wT/ZJlLKDAcI6AqD6fCZuday3VXNOzEOg9rZJlL3T7zf whNR1Pd/r4CrVz4ec7d4oYs4gmGYzf1o4XblTzU3Dbx8XM4aJoP8oaY60l4BKDu9ewJT D/jBtxRMuHK87GXt3x6dIUYOSqT60DGm0VTHJeJthTUwOkfkPFf213MinWXCUX8KTl0/ BWCVtZEsLlyvLjYAQKyzjpehDGhJmEIpNZmEwLiheqx1xisANAaM9xiJ4cMOsNZwNvYT o3bg== X-Gm-Message-State: AOAM533b2ltbP9w1T1oBq8dQB9IiDqQpuQljed7TtXdH9XeTHfkZhPXb yyGIofFZJGA9yzKu/BWjaEkw5MD4Gxg= X-Google-Smtp-Source: ABdhPJwzXV9eE6ALr5VgdKFY8V8VwWLlS7tryzrvVudYtCfSaHDOQ8lQsf71nDJD+ZIvyWX5DrQzfw== X-Received: by 2002:a17:907:628a:: with SMTP id nd10mr26219861ejc.326.1615893868002; Tue, 16 Mar 2021 04:24:28 -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.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 04:24:27 -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 01/12] Documentation: networking: update the graphical representation Date: Tue, 16 Mar 2021 13:24:08 +0200 Message-Id: <20210316112419.1304230-2-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 X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean While preparing some slides for a customer presentation, I found the existing high-level view to be a bit confusing, so I modified it a little bit. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Tobias Waldekranz --- Documentation/networking/dsa/dsa.rst | 45 +++++++++++++++++----------- 1 file changed, 28 insertions(+), 17 deletions(-) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index e9517af5fe02..e20fbad2241a 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -172,23 +172,34 @@ Graphical representation Summarized, this is basically how DSA looks like from a network device perspective:: - - |--------------------------- - | CPU network device (eth0)| - ---------------------------- - | | - |--------------------------------------------| - | Switch driver | - |--------------------------------------------| - || || || - |-------| |-------| |-------| - | sw0p0 | | sw0p1 | | sw0p2 | - |-------| |-------| |-------| - - + Unaware application + opens and binds socket + | ^ + | | + +-----------v--|--------------------+ + |+------+ +------+ +------+ +------+| + || swp0 | | swp1 | | swp2 | | swp3 || + |+------+-+------+-+------+-+------+| + | DSA switch driver | + +-----------------------------------+ + | ^ + Tag added by | | Tag consumed by + switch driver | | switch driver + v | + +-----------------------------------+ + | Unmodified host interface driver | Software + --------+-----------------------------------+------------ + | Host interface (eth0) | Hardware + +-----------------------------------+ + | ^ + Tag consumed by | | Tag added by + switch hardware | | switch hardware + v | + +-----------------------------------+ + | Switch | + |+------+ +------+ +------+ +------+| + || swp0 | | swp1 | | swp2 | | swp3 || + ++------+-+------+-+------+-+------++ Slave MDIO bus -------------- From patchwork Tue Mar 16 11:24:09 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12141999 X-Patchwork-Delegate: kuba@kernel.org 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 34F73C433E6 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 D79EB65033 for ; Tue, 16 Mar 2021 11:25:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233738AbhCPLYn (ORCPT ); Tue, 16 Mar 2021 07:24:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39908 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232381AbhCPLYb (ORCPT ); Tue, 16 Mar 2021 07:24:31 -0400 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C251C06174A for ; Tue, 16 Mar 2021 04:24:30 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id c10so71409807ejx.9 for ; Tue, 16 Mar 2021 04:24:30 -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=QXqHpOQoy/Kk5pei4kuycWUmrEJa8bIinA5w7A6OUnQ=; b=dmDDc/NYNpJjbzOtD4+TkJxisopeAIN5ZubajNapa5Zeomb/ICDHwosgEUSGz/4yxO Do4SN2SSjOZpxHjZHxx8oNAabbysvJRJm1Lbt6sutNRmxevWfbS06HNp2YRKmEjJKulp 05EyfHuQ7E+YdmRuk7OH260PnWIHM5sDrg85YV8f/h1sHyv4hHnrEF9OOqIJBESHnPsY xCD43z2C9C1YTES3KWIZ6I68zZaCVBt+2rMbuCgnVT2UijpfDdC+huY4uqCDsVaVwCEU QN5fBOgWjCcBJ/eVDCNOmZXgo9kh9ymi4Q8nWRkhtOSDKQAg6mLH2cAsdF2iz3sqZl3v bXUQ== 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=QXqHpOQoy/Kk5pei4kuycWUmrEJa8bIinA5w7A6OUnQ=; b=UDrTY9UoLyeI15UFre95U7GgaDKSCfAMBqYJD7qSOt4HsD9kHk/t8Q2/Sjalg65iTd Wkz/dOymIDR+roVHvgNPXwfzTHOAZ5r0Hr8umx0Bj1ywBD7KqHIE1Y6paceBnS80fipI im+nBWd4m/yssznTvgoVunoVBZ/D2A+AbyGzYi//S7+86h4Fhg/KuUw6xB/88e46Z9iS ssgD9fWEKEpw8Kzu9pGfBlPkKgY8zq3bw8Wu/oTOEGxvz/tzz+itvM80Kf89R4TLAp0W IDa5XtaLOjqGwthHzIVWx2zY/LnTxNnOa8eHua2Q+jFy5LdJT0Iw5zajRrgQEiRqAZ7L kDYw== X-Gm-Message-State: AOAM532UbOVSi05bbh7Gr6b8XovdzXbaY1m6iqH/ltaTMOF81HzcH6Lt ZtDBCn2yj7KV+EQ7wYGeJFdXsXx3wqs= X-Google-Smtp-Source: ABdhPJx12Zny1b3Udv1/yrj4FgGb0DJVE4M2+KbHSKvCtw8X6vbqCsVd/feNfJhHnBZVWeEyZEGTlg== X-Received: by 2002:a17:906:3881:: with SMTP id q1mr29211913ejd.490.1615893868978; Tue, 16 Mar 2021 04:24:28 -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.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 04:24:28 -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 02/12] Documentation: networking: dsa: rewrite chapter about tagging protocol Date: Tue, 16 Mar 2021 13:24:09 +0200 Message-Id: <20210316112419.1304230-3-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 X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean The chapter about tagging protocols is out of date because it doesn't mention all taggers that have been added since last documentation update. But judging based on that, it will always tend to lag behind, and there's no good reason why we would enumerate the supported hardware. Instead we could do something more useful and explain what there is to know about tagging protocols instead. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn Reviewed-by: Tobias Waldekranz --- Documentation/networking/dsa/dsa.rst | 148 +++++++++++++++++++++++++-- 1 file changed, 140 insertions(+), 8 deletions(-) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index e20fbad2241a..17d1422ac085 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -65,14 +65,8 @@ Note that DSA does not currently create network interfaces for the "cpu" and Switch tagging protocols ------------------------ -DSA currently supports 5 different tagging protocols, and a tag-less mode as -well. The different protocols are implemented in: - -- ``net/dsa/tag_trailer.c``: Marvell's 4 trailer tag mode (legacy) -- ``net/dsa/tag_dsa.c``: Marvell's original DSA tag -- ``net/dsa/tag_edsa.c``: Marvell's enhanced DSA tag -- ``net/dsa/tag_brcm.c``: Broadcom's 4 bytes tag -- ``net/dsa/tag_qca.c``: Qualcomm's 2 bytes tag +DSA supports many vendor-specific tagging protocols, one software-defined +tagging protocol, and a tag-less mode as well (``DSA_TAG_PROTO_NONE``). The exact format of the tag protocol is vendor specific, but in general, they all contain something which: @@ -80,6 +74,144 @@ all contain something which: - identifies which port the Ethernet frame came from/should be sent to - provides a reason why this frame was forwarded to the management interface +All tagging protocols are in ``net/dsa/tag_*.c`` files and implement the +methods of the ``struct dsa_device_ops`` structure, which are detailed below. + +Tagging protocols generally fall in one of three categories: + +1. The switch-specific frame header is located before the Ethernet header, + shifting to the right (from the perspective of the DSA master's frame + parser) the MAC DA, MAC SA, EtherType and the entire L2 payload. +2. The switch-specific frame header is located before the EtherType, keeping + the MAC DA and MAC SA in place from the DSA master's perspective, but + shifting the 'real' EtherType and L2 payload to the right. +3. The switch-specific frame header is located at the tail of the packet, + keeping all frame headers in place and not altering the view of the packet + that the DSA master's frame parser has. + +A tagging protocol may tag all packets with switch tags of the same length, or +the tag length might vary (for example packets with PTP timestamps might +require an extended switch tag, or there might be one tag length on TX and a +different one on RX). Either way, the tagging protocol driver must populate the +``struct dsa_device_ops::overhead`` with the length in octets of the longest +switch frame header. The DSA framework will automatically adjust the MTU of the +master interface to accomodate for this extra size in order for DSA user ports +to support the standard MTU (L2 payload length) of 1500 octets. The ``overhead`` +is also used to request from the network stack, on a best-effort basis, the +allocation of packets with a ``needed_headroom`` or ``needed_tailroom`` +sufficient such that the act of pushing the switch tag on transmission of a +packet does not cause it to reallocate due to lack of memory. + +Even though applications are not expected to parse DSA-specific frame headers, +the format on the wire of the tagging protocol represents an Application Binary +Interface exposed by the kernel towards user space, for decoders such as +``libpcap``. The tagging protocol driver must populate the ``proto`` member of +``struct dsa_device_ops`` with a value that uniquely describes the +characteristics of the interaction required between the switch hardware and the +data path driver: the offset of each bit field within the frame header and any +stateful processing required to deal with the frames (as may be required for +PTP timestamping). + +From the perspective of the network stack, all switches within the same DSA +switch tree use the same tagging protocol. In case of a packet transiting a +fabric with more than one switch, the switch-specific frame header is inserted +by the first switch in the fabric that the packet was received on. This header +typically contains information regarding its type (whether it is a control +frame that must be trapped to the CPU, or a data frame to be forwarded). +Control frames should be decapsulated only by the software data path, whereas +data frames might also be autonomously forwarded towards other user ports of +other switches from the same fabric, and in this case, the outermost switch +ports must decapsulate the packet. + +Note that in certain cases, it might be the case that the tagging format used +by a leaf switch (not connected directly to the CPU) to not be the same as what +the network stack sees. This can be seen with Marvell switch trees, where the +CPU port can be configured to use either the DSA or the Ethertype DSA (EDSA) +format, but the DSA links are configured to use the shorter (without Ethertype) +DSA frame header, in order to reduce the autonomous packet forwarding overhead. +It still remains the case that, if the DSA switch tree is configured for the +EDSA tagging protocol, the operating system sees EDSA-tagged packets from the +leaf switches that tagged them with the shorter DSA header. This can be done +because the Marvell switch connected directly to the CPU is configured to +perform tag translation between DSA and EDSA (which is simply the operation of +adding or removing the ``ETH_P_EDSA`` EtherType and some padding octets). + +It is possible to construct cascaded setups of DSA switches even if their +tagging protocols are not compatible with one another. In this case, there are +no DSA links in this fabric, and each switch constitutes a disjoint DSA switch +tree. The DSA links are viewed as simply a pair of a DSA master (the out-facing +port of the upstream DSA switch) and a CPU port (the in-facing port of the +downstream DSA switch). + +The tagging protocol of the attached DSA switch tree can be viewed through the +``dsa/tagging`` sysfs attribute of the DSA master:: + + cat /sys/class/net/eth0/dsa/tagging + +If the hardware and driver are capable, the tagging protocol of the DSA switch +tree can be changed at runtime. This is done by writing the new tagging +protocol name to the same sysfs device attribute as above (the DSA master and +all attached switch ports must be down while doing this). + +It is desirable that all tagging protocols are testable with the ``dsa_loop`` +mockup driver, which can be attached to any network interface. The goal is that +any network interface should be capable of transmitting the same packet in the +same way, and the tagger should decode the same received packet in the same way +regardless of the driver used for the switch control path, and the driver used +for the DSA master. + +The transmission of a packet goes through the tagger's ``xmit`` function. +The passed ``struct sk_buff *skb`` has ``skb->data`` pointing at +``skb_mac_header(skb)``, i.e. at the destination MAC address, and the passed +``struct net_device *dev`` represents the virtual DSA user network interface +whose hardware counterpart the packet must be steered to (i.e. ``swp0``). +The job of this method is to prepare the skb in a way that the switch will +understand what egress port the packet is for (and not deliver it towards other +ports). Typically this is fulfilled by pushing a frame header. Checking for +insufficient size in the skb headroom or tailroom is unnecessary provided that +the ``overhead`` and ``tail_tag`` properties were filled out properly, because +DSA ensures there is enough space before calling this method. + +The reception of a packet goes through the tagger's ``rcv`` function. The +passed ``struct sk_buff *skb`` has ``skb->data`` pointing at +``skb_mac_header(skb) + ETH_ALEN`` octets, i.e. to where the first octet after +the EtherType would have been, were this frame not tagged. The role of this +method is to consume the frame header, adjust ``skb->data`` to really point at +the first octet after the EtherType, and to change ``skb->dev`` to point to the +virtual DSA user network interface corresponding to the physical front-facing +switch port that the packet was received on. + +Since tagging protocols in category 1 and 2 break software (and most often also +hardware) packet dissection on the DSA master, features such as RPS (Receive +Packet Steering) on the DSA master would be broken. The DSA framework deals +with this by hooking into the flow dissector and shifting the offset at which +the IP header is to be found in the tagged frame as seen by the DSA master. +This behavior is automatic based on the ``overhead`` value of the tagging +protocol. If not all packets are of equal size, the tagger can implement the +``flow_dissect`` method of the ``struct dsa_device_ops`` and override this +default behavior by specifying the correct offset incurred by each individual +RX packet. Tail taggers do not cause issues to the flow dissector. + +Due to various reasons (most common being category 1 taggers being associated +with DSA-unaware masters, mangling what the master perceives as MAC DA), the +tagging protocol may require the DSA master to operate in promiscuous mode, to +receive all frames regardless of the value of the MAC DA. This can be done by +setting the ``promisc_on_master`` property of the ``struct dsa_device_ops``. +Note that this assumes a DSA-unaware master driver, which is the norm. + +Hardware manufacturers are strongly discouraged to do this, but some tagging +protocols might not provide source port information on RX for all packets, but +e.g. only for control traffic (link-local PDUs). In this case, by implementing +the ``filter`` method of ``struct dsa_device_ops``, the tagger might select +which packets are to be redirected on RX towards the virtual DSA user network +interfaces, and which are to be left in the DSA master's RX data path. + +It might also happen (although silicon vendors are strongly discouraged to +produce hardware like this) that a tagging protocol splits the switch-specific +information into a header portion and a tail portion, therefore not falling +cleanly into any of the above 3 categories. DSA does not support this +configuration. + Master network devices ---------------------- 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: 12141993 X-Patchwork-Delegate: kuba@kernel.org 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 X-Patchwork-Delegate: kuba@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:11 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12141991 X-Patchwork-Delegate: kuba@kernel.org 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 656D1C433E9 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 2A3A16502F for ; Tue, 16 Mar 2021 11:25:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234206AbhCPLYp (ORCPT ); Tue, 16 Mar 2021 07:24:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232728AbhCPLYd (ORCPT ); Tue, 16 Mar 2021 07:24:33 -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 8542DC061756 for ; Tue, 16 Mar 2021 04:24:32 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id p8so71461653ejb.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=5sg2Nx8Fg6/wBx/cLi5Zi9NgorSY7gPt+6/GGb4CrKg=; b=LpeF1eakGdXed9Fa8+B/9xYrHHl1Twjf1LCuQVWb6s1STxZmlROjpELPpmLWmg+Ytq CEHnHfATKJW7CN3aZokEjHb88m51m0ueaxlCdsKoK6PA4PQnDPExotr3y/E+pBHD/VdH qLJP6QrkvA9jDT6Em7iu7Q+Vjvet0/BgpLvV13eT9G2RxsZhEc3AglpkYhY58PoXyInL bbE/FU+hx4LNd4As0hCKCiRjrqysY61/7Wl7EePIpTkxvJbyZk5egTLhERfjJyk2gBin OCNTCJZupt75mgrinL7TS5UFcWMMiTIps6Mg4baMjx/842c7ZEfzlpeqIMNQf9VxRy/C Fi9g== 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=5sg2Nx8Fg6/wBx/cLi5Zi9NgorSY7gPt+6/GGb4CrKg=; b=TFTv20T+9yfhXs6BTncHO1w9EiTq7ro/45Fb2pLEP9Wr6BAYW//LTJt0LJTHOqOJSl JXrV0sm6wDpkCWVtuXAVd7msZ7BpcuU2WVWe8HVhwqSbXHuGZiGN/HgeWL8nkPkM1XFp QENt58d4fFhLgeVv+ArKMw+MYTD6A8cW1hF/GjylPK3PsTZmOiY6HwTgf5oBDPi57gWy Y1Rv8+ueSH7QjxzqoJ6S+f+PzxoKtiLyv68iCGfPKxQIPNbe6KutfIvryHQdZ1Rgr9y4 yolFYvm03XuAmrzJBieVSNBIgmvmR7RDEZd2sL2k3lGVQoRELhxgvkhasJQh9n3CNZGD w5zA== X-Gm-Message-State: AOAM530m31H1K1q3KwUl1B1usPAJ+4jCECXP21htCxebb6fjZaL0DTGM un7AuNv5ReD8gmBq/VOaSAAvMADoLe4= X-Google-Smtp-Source: ABdhPJxwUhRyUOyaoMkkTcC7gLh7RYNXDe1pilJbKndT4Z+nEOWnn/a7ZSxUn2sRXxP7kXQ/8pm6sw== X-Received: by 2002:a17:906:fcc7:: with SMTP id qx7mr29089541ejb.486.1615893870977; Tue, 16 Mar 2021 04:24:30 -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.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 04:24:30 -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 04/12] Documentation: networking: dsa: remove references to switchdev prepare/commit Date: Tue, 16 Mar 2021 13:24:11 +0200 Message-Id: <20210316112419.1304230-5-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 X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean After the recent series containing commit bae33f2b5afe ("net: switchdev: remove the transaction structure from port attributes"), there aren't prepare/commit transactional phases anymore in most of the switchdev objects/attributes, and as a result, there aren't any in the DSA driver API either. So remove this piece. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn --- Documentation/networking/dsa/dsa.rst | 30 ++++++++-------------------- 1 file changed, 8 insertions(+), 22 deletions(-) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 3bca80a53a86..ced2eb6d647a 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -452,14 +452,8 @@ SWITCHDEV DSA directly utilizes SWITCHDEV when interfacing with the bridge layer, and more specifically with its VLAN filtering portion when configuring VLANs on top -of per-port slave network devices. Since DSA primarily deals with -MDIO-connected switches, although not exclusively, SWITCHDEV's -prepare/abort/commit phases are often simplified into a prepare phase which -checks whether the operation is supported by the DSA switch driver, and a commit -phase which applies the changes. - -As of today, the only SWITCHDEV objects supported by DSA are the FDB and VLAN -objects. +of per-port slave network devices. As of today, the only SWITCHDEV objects +supported by DSA are the FDB and VLAN objects. Device Tree ----------- @@ -638,14 +632,10 @@ Bridge VLAN filtering accept any 802.1Q frames irrespective of their VLAN ID, and untagged frames are allowed. -- ``port_vlan_prepare``: bridge layer function invoked when the bridge prepares the - configuration of a VLAN on the given port. If the operation is not supported - by the hardware, this function should return ``-EOPNOTSUPP`` to inform the bridge - code to fallback to a software implementation. No hardware setup must be done - in this function. See port_vlan_add for this and details. - - ``port_vlan_add``: bridge layer function invoked when a VLAN is configured - (tagged or untagged) for the given switch port + (tagged or untagged) for the given switch port. If the operation is not + supported by the hardware, this function should return ``-EOPNOTSUPP`` to + inform the bridge code to fallback to a software implementation. - ``port_vlan_del``: bridge layer function invoked when a VLAN is removed from the given switch port @@ -673,14 +663,10 @@ 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 FDB info. -- ``port_mdb_prepare``: bridge layer function invoked when the bridge prepares the - installation of a multicast database entry. If the operation is not supported, - this function should return ``-EOPNOTSUPP`` to inform the bridge code to fallback - to a software implementation. No hardware setup must be done in this function. - See ``port_fdb_add`` for this and details. - - ``port_mdb_add``: bridge layer function invoked when the bridge wants to install - a multicast database entry, the switch hardware should be programmed with the + a multicast database entry. If the operation is not supported, this function + should return ``-EOPNOTSUPP`` to inform the bridge code to fallback to a + software implementation. The switch hardware should be programmed with the specified address in the specified VLAN ID in the forwarding database associated with this VLAN ID. 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: 12141989 X-Patchwork-Delegate: kuba@kernel.org 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 X-Patchwork-Delegate: kuba@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:13 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12141995 X-Patchwork-Delegate: kuba@kernel.org 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 9599DC4332E 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 6F29565034 for ; Tue, 16 Mar 2021 11:25:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233473AbhCPLYt (ORCPT ); Tue, 16 Mar 2021 07:24:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232509AbhCPLYe (ORCPT ); Tue, 16 Mar 2021 07:24:34 -0400 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4310DC06174A for ; Tue, 16 Mar 2021 04:24:34 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id c10so71410078ejx.9 for ; Tue, 16 Mar 2021 04:24:34 -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=CpCfl0bYoqF8thfkebTAWyvngGslCFJA8QRSmeXy8FY=; b=GnALewWZyYlwLIpd2iHSwMNU+6PMVGXRv54kh4/zE/Gknpg26r01LAhFpsEWOUt1JT tu3+79xQKR0f58eP7ZzjPvv3lOMmE6SAFI3auo3Dq6T8fx6NNP8VgqLUCgx+kK+QLdAf x6Vq4b9H6A/xf9Qg10fdXZK07iopSxAu4ipf6ilHZylRukeKWrDD/NYC26OX+8oUsDxf 5CTAi8YXQm/fok2JRbCIKR7l57Yzz8zQd2c9HrM8+E621i9oq8aMvAYwXffhW1jdohUB cBfu/RANnGhcGvQMmsI8ESCh/Xam4aRqVAwh5oEkyTGUp3rQC3iYMVvJqfhlpFfpqU14 XnhA== 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=CpCfl0bYoqF8thfkebTAWyvngGslCFJA8QRSmeXy8FY=; b=Nb0OyyRV+v1Lo4V+c90cAMWuu6A0193c/Y/num6Yl3V72Ofg5TpiWnqLW2r29TQwB3 GmT516PN/i+yEmq440UkgtSKLK1+zwAeMQMqeUrn4/o8uD6myBs800HTnhe6RmtkTs8C iIV5IU4MxPXfifhKVPOfsILCi9NHXjonhTWTk+To0ZrNUeOXX9NP7RcxcfcuykxWHHzL DvHdoGx55tzPB9CuSPGaf8hhRFgT96I0k/ivzredGmrFV7VPIfrOjvXBc9C2CXC9Jl1Q u9Stmt1JRy6oXmTA9waN4MnurceEQCKh+zpE1YM4Ph6/7SRUDKf74CMKiRfin8OIiMFd DmOQ== X-Gm-Message-State: AOAM5327c3iFbtyaUb8Sdtl3yLVMAI6DzUftarPiD3htqg8W1c8qce4b VVPS5CNd5DbsgiWrMjL+jEOErIv7CYw= X-Google-Smtp-Source: ABdhPJxNFQ3cocJIerukkPp+ayNMdzIbPn5ja4nrwP60B4GELCqTwNCL6vH4fgHUnapfZd3AblqDJw== X-Received: by 2002:a17:907:9808:: with SMTP id ji8mr29183537ejc.333.1615893872784; Tue, 16 Mar 2021 04:24:32 -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:32 -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 06/12] Documentation: networking: dsa: document the port_bridge_flags method Date: Tue, 16 Mar 2021 13:24:13 +0200 Message-Id: <20210316112419.1304230-7-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 X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean The documentation was already lagging behind by not mentioning the old version of port_bridge_flags (port_set_egress_floods). So now we are skipping one step and just explaining how a DSA driver should configure address learning and flooding settings. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn --- Documentation/networking/dsa/dsa.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index b90a852e5329..9c287dfd3c45 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -619,6 +619,17 @@ Bridge layer computing a STP state change based on current and asked parameters and perform the relevant ageing based on the intersection results +- ``port_bridge_flags``: bridge layer function invoked when a port must + configure its settings for e.g. flooding of unknown traffic or source address + learning. The switch driver is responsible for initial setup of the + standalone ports with address learning disabled and egress flooding of all + types of traffic, then the DSA core notifies of any change to the bridge port + flags when the port joins and leaves a bridge. DSA does not currently manage + the bridge port flags for the CPU port. The assumption is that address + learning should be statically enabled (if supported by the hardware) on the + CPU port, and flooding towards the CPU port should also be enabled, due to a + lack of an explicit address filtering mechanism in the DSA core. + Bridge VLAN filtering --------------------- 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: 12142001 X-Patchwork-Delegate: kuba@kernel.org 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 X-Patchwork-Delegate: kuba@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: 12141997 X-Patchwork-Delegate: kuba@kernel.org 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 X-Patchwork-Delegate: kuba@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 Reviewed-by: Tobias Waldekranz --- 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:16 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12142003 X-Patchwork-Delegate: kuba@kernel.org 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 E82FFC4332B for ; Tue, 16 Mar 2021 11:25:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 988496502E for ; Tue, 16 Mar 2021 11:25:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234328AbhCPLZM (ORCPT ); Tue, 16 Mar 2021 07:25:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39944 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230526AbhCPLYi (ORCPT ); Tue, 16 Mar 2021 07:24:38 -0400 Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F274C06174A for ; Tue, 16 Mar 2021 04:24:37 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id r17so71470460ejy.13 for ; Tue, 16 Mar 2021 04:24:37 -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=3F80TPs4WAjb4QnZL3S6m5+vCzslZHZnokWdtOsrud8=; b=cVV/E8G9BNZaftvCs0635vGUVU1A7LnwGSQkY3Mt5U2SHWaxzNpwEcYwduD/0XKGiW K4rBgjH4bj1S37gSH+L1T1Lb0CB/ZCTUPviSnPwLIFkxj1NIo55G3ShR4aCzGWLVjrQp LNg6dtIwyoKviiWCa6vIrdJyQBaa/mBj0JJuywreBoZ09aoiZjcdp7Kk7fDZYa0mR12q iaPNtaPaduEpusKDaHUDcgZk4i2AsKPxsm4aqn5mBS5EIClb0RREdc6GmvvbDRFhLD8S jpIahltEXg2lSltJ0zoVHagJV/j1gK1g8sf8Ubat5z+vwBPmlUdNGMI5GhMrmcr9AP6q 6q8g== 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=3F80TPs4WAjb4QnZL3S6m5+vCzslZHZnokWdtOsrud8=; b=ZAXLyZLMkX4iL7P+Rd/S8+EH/uwZAUbkezLpLo2U6Wgu2fp1RqJ4zJ2bo52VP5DqvJ WKGObeL2lHUYvj1Pq7Kvxj8eQ+KfPeoNoECXYiW6GGAJpK573pVKY9vqz7a78FdxC/bR wWtLyyckVt8WWC7dB8zhtTKm+FjsNGVvHdiutMxGVVkxH551NEX821YWB5p2lVPeBj9u r45MRs8ib1X7hYWgiE+chBvajzKfc7OS7BtZFhaKLJkTv+ElWVRcb2apRrbkayCDSgYk 9cDrWqo+IdRbQx6LfcSFSPjB4dXRxNilDCEvQgezob1ewlK7dXReTe1hynF+J81FQqPB eCRw== X-Gm-Message-State: AOAM533eIEpvpcmcoJlXaRmmPaAXMnEuRvkRpL/JpVQgEA9stC0AplpN PtnpEy8kdXCw3RUy71Lgr3JaGF/BLBU= X-Google-Smtp-Source: ABdhPJy/CnnEO4Gcg5oCYKSa90rkvzeuIhMvw1qyiMZVhLatMPffRnqtO4Prv7aG1d2RYi+3PK4z9A== X-Received: by 2002:a17:906:260a:: with SMTP id h10mr29481535ejc.392.1615893875868; Tue, 16 Mar 2021 04:24:35 -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:35 -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 , Horatiu Vultur Subject: [PATCH v2 net-next 09/12] Documentation: networking: dsa: add paragraph for the MRP offload Date: Tue, 16 Mar 2021 13:24:16 +0200 Message-Id: <20210316112419.1304230-10-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 X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean Add a short summary of the methods that a driver writer must implement for getting an MRP instance to work on top of a DSA switch. Cc: Horatiu Vultur Signed-off-by: Vladimir Oltean Reviewed-by: Horatiu Vultur --- Documentation/networking/dsa/dsa.rst | 30 ++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index e8576e81735c..0daafa2fb9eb 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -757,6 +757,36 @@ 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. +IEC 62439-2 (MRP) +----------------- + +The Media Redundancy Protocol is a topology management protocol optimized for +fast fault recovery time for ring networks, which has some components +implemented as a function of the bridge driver. MRP uses management PDUs +(Test, Topology, LinkDown/Up, Option) sent at a multicast destination MAC +address range of 01:15:4e:00:00:0x and with an EtherType of 0x88e3. +Depending on the node's role in the ring (MRM: Media Redundancy Manager, +MRC: Media Redundancy Client, MRA: Media Redundancy Automanager), certain MRP +PDUs might need to be terminated locally and others might need to be forwarded. +An MRM might also benefit from offloading to hardware the creation and +transmission of certain MRP PDUs (Test). + +Normally an MRP instance can be created on top of any network interface, +however in the case of a device with an offloaded data path such as DSA, it is +necessary for the hardware, even if it is not MRP-aware, to be able to extract +the MRP PDUs from the fabric before the driver can proceed with the software +implementation. DSA today has no driver which is MRP-aware, therefore it only +listens for the bare minimum switchdev objects required for the software assist +to work properly. The operations are detailed below. + +- ``port_mrp_add`` and ``port_mrp_del``: notifies driver when an MRP instance + with a certain ring ID, priority, primary port and secondary port is + created/deleted. +- ``port_mrp_add_ring_role`` and ``port_mrp_del_ring_role``: function invoked + when an MRP instance changes ring roles between MRM or MRC. This affects + which MRP PDUs should be trapped to software and which should be autonomously + forwarded. + 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: 12142005 X-Patchwork-Delegate: kuba@kernel.org 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 X-Patchwork-Delegate: kuba@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: 12142009 X-Patchwork-Delegate: kuba@kernel.org 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 X-Patchwork-Delegate: kuba@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. From patchwork Tue Mar 16 11:24:19 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12142007 X-Patchwork-Delegate: kuba@kernel.org 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 D501EC433DB 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 917716502E for ; Tue, 16 Mar 2021 11:25:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237172AbhCPLZa (ORCPT ); Tue, 16 Mar 2021 07:25:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234116AbhCPLYk (ORCPT ); Tue, 16 Mar 2021 07:24:40 -0400 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35868C061756 for ; Tue, 16 Mar 2021 04:24:40 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id jt13so71543252ejb.0 for ; Tue, 16 Mar 2021 04:24:40 -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=sckutMAyutoKxTGnU+hRCjp7ZyGTCTbEbQkztPY9k4Y=; b=oogm8x/w4wP0qB8ncU6w6uOzKHD/GwrIHJ5sFsLGond4cxliKO/0roYK0Q7oKM2RHl mMfQrWBqKpjZRIEEYYZqNCM7LYPWir1kiC8vNwDfmpCc93h4kjY2SJSZjlrap/gCCAev m4hq/QhoYf9JJvw8pmO//H3/3cADajW2YcgKhJ75z5g2jgmQZtzhZJkqhm1x7g0Estug 4cEpGG2BrAN2GBFNprYqmNFaFn2LgIKH+ff3w/fWYG5iPQmNyTAAfm90pwKmx0d/j/QJ EkRhDbu6LT+1RinY2V7czSuqpXYCXdKoerXdqB68msgxkVUK3tALB9UhkQtjwl0pu1lS VuIA== 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=sckutMAyutoKxTGnU+hRCjp7ZyGTCTbEbQkztPY9k4Y=; b=hsde5rkWhPCCu25woT8ojXaTpjiIi7GHVuzebKKbXyX6kYnKrAN9airQMA7BqxaAM/ wXNVXv9nnOWOP4gBh6zPZkxVBG0u5Dhh6HjDhqv8VJpeyoLUypW0uXKh2hBbG6g8M2PV MrOLZK+lf4ZAKOyUJbIkLXs2qyFn4uC0F0k15egGXOS4bTYnACqL54soXaA0IMqSljNO wP8Lxn7JdjEY+uVwiXuh3BEg0BvMd33uzxoYUZkvcPbumvrO13hEMVypbKclCDuviSvM h1YWhvEYW/MNrA/q2LClwzfWz0pSAXNGEp3jbFBZ2xiVa4ZZ4k2zHdsToIM/R0Sjl0NE QJvg== X-Gm-Message-State: AOAM530eSsV4L7CtSB7+kLucIpKSOmxkwvRIb6w7QUpyxsBnm0Oborio LlkuILwKbRYJFQUAOZRMMmZeemfGmBA= X-Google-Smtp-Source: ABdhPJzJDoJ0YW8h0Ifi3fLpemFwd0Ti1A+vOV1yo5iL2Yt1HqwuHon7efyzbDGDvhnCVlnxkNtY8A== X-Received: by 2002:a17:906:5d12:: with SMTP id g18mr28552997ejt.246.1615893878680; Tue, 16 Mar 2021 04:24:38 -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.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 04:24:38 -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 12/12] Documentation: networking: switchdev: fix command for static FDB entries Date: Tue, 16 Mar 2021 13:24:19 +0200 Message-Id: <20210316112419.1304230-13-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 X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean The "bridge fdb add" command provided in the switchdev documentation is junk now, not only because it is syntactically incorrect and rejected by the iproute2 bridge program, but also because it was not updated in light of Arkadi Sharshevsky's radical switchdev refactoring in commit 29ab586c3d83 ("net: switchdev: Remove bridge bypass support from switchdev"). Try to explain what the intended usage pattern is with the new kernel implementation. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Ido Schimmel --- Documentation/networking/switchdev.rst | 47 +++++++++++++++++++------- 1 file changed, 35 insertions(+), 12 deletions(-) diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst index 016531a3d471..1b56367d85ad 100644 --- a/Documentation/networking/switchdev.rst +++ b/Documentation/networking/switchdev.rst @@ -181,18 +181,41 @@ To offloading L2 bridging, the switchdev driver/device should support: Static FDB Entries ^^^^^^^^^^^^^^^^^^ -The switchdev driver should implement ndo_fdb_add, ndo_fdb_del and ndo_fdb_dump -to support static FDB entries installed to the device. Static bridge FDB -entries are installed, for example, using iproute2 bridge cmd:: - - bridge fdb add ADDR dev DEV [vlan VID] [self] - -The driver should use the helper switchdev_port_fdb_xxx ops for ndo_fdb_xxx -ops, and handle add/delete/dump of SWITCHDEV_OBJ_ID_PORT_FDB object using -switchdev_port_obj_xxx ops. - -XXX: what should be done if offloading this rule to hardware fails (for -example, due to full capacity in hardware tables) ? +A driver which implements the ``ndo_fdb_add``, ``ndo_fdb_del`` and +``ndo_fdb_dump`` operations is able to support the command below, which adds a +static bridge FDB entry:: + + bridge fdb add dev DEV ADDRESS [vlan VID] [self] static + +(the "static" keyword is non-optional: if not specified, the entry defaults to +being "local", which means that it should not be forwarded) + +The "self" keyword (optional because it is implicit) has the role of +instructing the kernel to fulfill the operation through the ``ndo_fdb_add`` +implementation of the ``DEV`` device itself. If ``DEV`` is a bridge port, this +will bypass the bridge and therefore leave the software database out of sync +with the hardware one. + +To avoid this, the "master" keyword can be used:: + + bridge fdb add dev DEV ADDRESS [vlan VID] master static + +The above command instructs the kernel to search for a master interface of +``DEV`` and fulfill the operation through the ``ndo_fdb_add`` method of that. +This time, the bridge generates a ``SWITCHDEV_FDB_ADD_TO_DEVICE`` notification +which the port driver can handle and use it to program its hardware table. This +way, the software and the hardware database will both contain this static FDB +entry. + +Note: for new switchdev drivers that offload the Linux bridge, implementing the +``ndo_fdb_add`` and ``ndo_fdb_del`` bridge bypass methods is strongly +discouraged: all static FDB entries should be added on a bridge port using the +"master" flag. The ``ndo_fdb_dump`` is an exception and can be implemented to +visualize the hardware tables, if the device does not have an interrupt for +notifying the operating system of newly learned/forgotten dynamic FDB +addresses. In that case, the hardware FDB might end up having entries that the +software FDB does not, and implementing ``ndo_fdb_dump`` is the only way to see +them. Note: by default, the bridge does not filter on VLAN and only bridges untagged traffic. To enable VLAN support, turn on VLAN filtering::