From patchwork Sun Feb 21 21:33:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 386100 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 66EA9C433DB for ; Sun, 21 Feb 2021 21:35:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3741260295 for ; Sun, 21 Feb 2021 21:35:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231153AbhBUVfM (ORCPT ); Sun, 21 Feb 2021 16:35:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230453AbhBUVes (ORCPT ); Sun, 21 Feb 2021 16:34:48 -0500 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1A72C06178A for ; Sun, 21 Feb 2021 13:34:07 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id e13so22856499ejl.8 for ; Sun, 21 Feb 2021 13:34:07 -0800 (PST) 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=1IpLJbP5ciwR6SMBLis+whJOXKeaI6W/OneiV4n/9jo=; b=SGKVwIom1x2WQ14lWlfc5n7xdraES6n4DpaRzx5GimcrLarAVxQ1Gs1xx25wxec3qK 7Yc0YN6dBMV7Q9p1+hIo5iVAH6S/GwhFmviICmInV2xxCW0sYFSOArrfLP17nyy5n7xf HLK21rPZBcA4wG05wAhFV59RFSSLSswiEggzhHd903w5zZhw/SdoE0ORib4WNtwcve1Q jd3bif7kjdXWN3a9pyNC2bNAL69+Z/Z0jtI5FEoETaSF3mXmT/r1Pvt/JHaP9oF9BxD6 2wqNpF+oqJvhneeTXt50LvfEX31H7iW27kVXbNdwo53s8fY0rFIhdnFQJ2Zq0w/cCPJi 1RlA== 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=1IpLJbP5ciwR6SMBLis+whJOXKeaI6W/OneiV4n/9jo=; b=UtXAk+5ti44kpc1kJz92WJl54zqFIDgGkg5gzDD2QQ3V0yJDWRoXSdLcj7IikxLoPE A/xoEJO2fnsEydEk2PmBhAOB/9VcY/XgaQImVEaAn6+KoOKpy9yBfsxtXAxjOYm1twnO GDaUuOLrByQImbj26UsKkJsVn+UUN3lIY4dOf4xOvDza/6/Lln/zAwsS8N1IMDiN5qei IAK0itdiInMSOBRUYd7TEVqbs0oGOfjt8tL4Z+oRNk0tnq5NxBgaOnj5p9gxb78lffAE 4gHQ99ouQd8pJfvimB9B0cF1483cBSXA4zkQqIDZS3Wk75Gzf3InyM01Yui2qg0/nO04 OBkw== X-Gm-Message-State: AOAM533DWF30bjOKde0Gjp9gl0uoycVqq9JeQHlxn0K0Gtv+op5+SvCe 7rlCwjtPe56nYhI5wHXsTH8plVmZuSQ= X-Google-Smtp-Source: ABdhPJxAmGTt7X0z4rC7Gw+BBYPZV5u6FGPPfsMKUYsfw5HSk7z1OlzOuDds9f4HIeZwOWsoOIDw5w== X-Received: by 2002:a17:906:ad3:: with SMTP id z19mr16436817ejf.350.1613943246441; Sun, 21 Feb 2021 13:34:06 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:06 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 01/12] Documentation: networking: update the graphical representation Date: Sun, 21 Feb 2021 23:33:44 +0200 Message-Id: <20210221213355.1241450-2-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.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 Sun Feb 21 21:33:45 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 385708 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 153EBC433E0 for ; Sun, 21 Feb 2021 21:35:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D46B364E77 for ; Sun, 21 Feb 2021 21:35:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231167AbhBUVfb (ORCPT ); Sun, 21 Feb 2021 16:35:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230454AbhBUVet (ORCPT ); Sun, 21 Feb 2021 16:34:49 -0500 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 0D458C06178B for ; Sun, 21 Feb 2021 13:34:09 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id hs11so26150323ejc.1 for ; Sun, 21 Feb 2021 13:34:08 -0800 (PST) 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=PmIoEWlbqv9fihHtJWIhH0WsoDVT4PPZxzWZdAVFsiY=; b=kYtdEnqfJkkf7/K8SRxtaM1VIScw8kSHmtn4oKFPsJ7XIzJastMNRTFoz6A8jzADVd cz2XEaHOFoHkFiMgkWmklXx/neg84TdRDiHyo2hzhN4eok9yjqJh0Qzpa3MrPN0B1zlf R5z98v3/6CWb0pHOgQFBtQfPEuthoxvnlmdfWT9eIMy8RZfrOj9+0LIJUnGyS6kIjaqR AFh+IyU6y59cwAL6K93YVD4oFYXgl9HRhU98WBHmc8xWeIWIs+XP2n7eTIxFZYwCrph3 opMcCbVa+cvKlIeX5inV82oey2G2e3fOztR7Y0Z58U6e7i66jtl/HyB2Oe5tXKGoonk4 fTqQ== 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=PmIoEWlbqv9fihHtJWIhH0WsoDVT4PPZxzWZdAVFsiY=; b=b89Ld7A3dcBnTGpCQ46CEktIzBrnHlLBcnKi4KyfskQOWQA8UQ4sFACbEoK5V0ARJl FeVBoqg4nslehF4sh1aB01Zj8ap9XqEUerMuAjSpa1qQPtkIJ3COek8fqEb4KpHm3OM6 yQxKldbjqIU363WOdjc41dqiSfzNCHysNDd4aCVbiIquNStBaXaxFZcaaibvpj5C16gz hYYPoPzqmMlh26clRgRBhVFU6nD6iOhIbXgw/Bzrdf81xkiDmRsxuy0wOLLNCQ5eE42V Rl5Yxa9KfDYi2AhITSROwQiHOM/LTM238LDjCLnNtJc+Y7OqzV1zMj+UOAZsyrHQs4l1 liUg== X-Gm-Message-State: AOAM53101ZPL7IEFKgmYvcIuz3BLFGQH/YDW4qm2o3j6XkSZZGIGQEZ/ QvRsO1Fr264n0Rm1/DZXAnEAWFsZrCs= X-Google-Smtp-Source: ABdhPJzGZxPuvO0Ky0VBw4Pv/gJDwJ8euLipbKgBsNb5vhW974mMN88UnOVswn82X1QbFewUBFo75A== X-Received: by 2002:a17:906:d147:: with SMTP id br7mr6386705ejb.66.1613943247405; Sun, 21 Feb 2021 13:34:07 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:07 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 02/12] Documentation: networking: dsa: rewrite chapter about tagging protocol Date: Sun, 21 Feb 2021 23:33:45 +0200 Message-Id: <20210221213355.1241450-3-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.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 | 126 +++++++++++++++++++++++++-- 1 file changed, 118 insertions(+), 8 deletions(-) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index e20fbad2241a..fc98b5774fb6 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,122 @@ 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: + +- 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. +- 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. +- 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). + +By definition, 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. + +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 able 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. + +Some tagging protocols, such as those in category 1 (shifting the MAC DA as +seen by the DSA master), 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``. + +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. + +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. + Master network devices ---------------------- From patchwork Sun Feb 21 21:33:46 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 385709 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 81E21C433E6 for ; Sun, 21 Feb 2021 21:35:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4C9A864E61 for ; Sun, 21 Feb 2021 21:35:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230170AbhBUVfX (ORCPT ); Sun, 21 Feb 2021 16:35:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230462AbhBUVeu (ORCPT ); Sun, 21 Feb 2021 16:34:50 -0500 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB1FCC06178C for ; Sun, 21 Feb 2021 13:34:09 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id n20so130847ejb.5 for ; Sun, 21 Feb 2021 13:34:09 -0800 (PST) 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=fxTIFR4EqLLuVSHPMzl4uGYJ6EYKN6vyQGKYjXcR7i4=; b=oGTyVL2FWBU0nBlBXL+OCfoflf7tb32Ue6y7C+d+FBxg+Yr1xqJeHzzzXdQcNVSURY F3ElPH4srlWT/Tm1lgwaauRJBzyPu1m3xppNml6jeJGgAonQVWYtAq2puItfchofh7i5 H6mYOYOJrpmWnqZkWmI4JYi10bVJL8K/dvM1opo5cC68O9mkNDh8qwWNuZVpEa0YIWUn cAKq4bwn3dentY21DzHYC4+IL+zbx4Q456Sw74B5RBHaZnxRLn9Yxx1KpEritAmZq4Xf xiD47lv98UdQzCKzwkJkq1OUlwGgJugUtHIVuwOSVvy44VLjGSsqEVwvzouuIZyb2xIw zdmA== 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=fxTIFR4EqLLuVSHPMzl4uGYJ6EYKN6vyQGKYjXcR7i4=; b=liLzZFxzXMjI6MYzI4L9yNdhdLcpyBmTxjHUyOAsVUaQuLFpEihyM8P2wVH5z6TaUu pL6Oi6XTpy1sPDVQr7emboq/TsJcZygN0BDszhkwS2QVXIB3O9wyu/nteWaB+QVp/jpR RwlFQcuUGHb5uG4VrMXNf1NRFF3G1jGSQyx+LSYZA2Dhy+zvakqmtNn0pEe4nUm+eany RWACy7IfD5LNAP88Yw+BSAEqFEN5fkUa7iZWuiMuDbaTz8EVhUxleceDpatiLdVbEgio VR5P2re0DWSTWMQW1FseH5YXfidyDJyFrmdhrkBwlyvAt0rDwvk7o/PnnhAWSgB1qRq2 4WIA== X-Gm-Message-State: AOAM533rS/OBI2ihfbERcfB6Sijy1EdHXzpJqxcyxDsnRYoz2SHhVOtz 7bf13CGwTAxp38U5Kley/MHyKj07Fmk= X-Google-Smtp-Source: ABdhPJwfD6WilmmeugRSmsPAjdDxU1F0rYRrGwEc1rzHICC0rHaGtl9KxhGx9S7rcImTLE7Q4INZhA== X-Received: by 2002:a17:906:f102:: with SMTP id gv2mr18014365ejb.47.1613943248469; Sun, 21 Feb 2021 13:34:08 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:08 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 03/12] Documentation: networking: dsa: remove static port count from limitations Date: Sun, 21 Feb 2021 23:33:46 +0200 Message-Id: <20210221213355.1241450-4-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Vladimir Oltean After Vivien's series from 2019 containing commits 27d4d19d7c82 ("net: dsa: remove limitation of switch index value") and ab8ccae122a4 ("net: dsa: add ports list in the switch fabric"), this is basically no longer true. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli --- Documentation/networking/dsa/dsa.rst | 9 --------- 1 file changed, 9 deletions(-) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index fc98b5774fb6..cb59df6e80f4 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -360,14 +360,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 ------------------------------- @@ -697,7 +689,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 Sun Feb 21 21:33:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 386099 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 C4EA8C433DB for ; Sun, 21 Feb 2021 21:35:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9544C64EBE for ; Sun, 21 Feb 2021 21:35:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231210AbhBUVfm (ORCPT ); Sun, 21 Feb 2021 16:35:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230445AbhBUVfI (ORCPT ); Sun, 21 Feb 2021 16:35:08 -0500 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 D9210C061793 for ; Sun, 21 Feb 2021 13:34:10 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id t11so26067660ejx.6 for ; Sun, 21 Feb 2021 13:34:10 -0800 (PST) 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=kXuZvLLvx0TuGzlM0GmcZEDK9pas+V35vr/sayO3ytE=; b=fmyMjyqZGiB3ByBNLHA+c5u7w3imcfzP07C45EKaVJxIY3gNtNgNIDNMjAm0543nhM dr7sAFn4EiWcJfYR9hQ0yoZr+6DQWSBBY9ucmosQIpJT9qc9qpqoMQhHD9gYsH8u9Wvb uBPiY0nXzpONJ7TOaFUFgb0GlKpmUhez2ULG6IYqGxfZ8oJlTdB5qqAt9MwwXMlF8Q5I nNZPKajjBG70GVYZpLCBp52jo5Wscbhf4ytez5nFnjHPWv8r2STXUpKFTX2hRkjwU8JJ Tr2VSfFtZQysqAanFGcRPjsepAGKq9jMyMpyOUKdRpwXyrkQAs7Xtp12SXI0oZGYpMtD TiMg== 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=kXuZvLLvx0TuGzlM0GmcZEDK9pas+V35vr/sayO3ytE=; b=hPem9E0cVKQ1MNZ0Y3gx43KLhSxzUOW2U3jkKxoEz4n28Hn9s6V3K1eOMalNi3zJ7w NaYlXCK1dgnQdA+aNKPnwdRbBN1aQBk4yadWXizrqo0bjTexFeg09WEtxnJhW7zN2GFe bd3+cXLsJcosxYY0RTnAwvyFe2m5OOOskAoPWvJt4/iAuw+PleG+I8Diu9CU4U4Xpboq yMXssv3pJzwj/VeACnV5hYrdexuuMLY7rGsxjyQLDVocIh70qRSIxoYW4C9s+LtGdwQn W6So3r2d8nNSe7OS5ax9MqeZ8DuLNNuWIlxOzrsbhPi3fvT5iaSsqSwddk94M5AzzaWa Cu0w== X-Gm-Message-State: AOAM532x6xnYMum3fs0hZ2v7rSNGnmt9mP0988M8tduJyzLe03L8xN1I EMrkRkR5+b+8o/Rw8EGaBfcsqqHaNew= X-Google-Smtp-Source: ABdhPJzvj1NNhVQyW52au1lYhRxjgP/EsUdtQ0+1bg5HWyKWijLgTlLA31Te1IGE7l2U98DqCHTKyA== X-Received: by 2002:a17:906:3801:: with SMTP id v1mr18467064ejc.353.1613943249423; Sun, 21 Feb 2021 13:34:09 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:09 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 04/12] Documentation: networking: dsa: remove references to switchdev prepare/commit Date: Sun, 21 Feb 2021 23:33:47 +0200 Message-Id: <20210221213355.1241450-5-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.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: 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 cb59df6e80f4..8fb0ceff3418 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -430,14 +430,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 ----------- @@ -616,14 +610,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 @@ -651,14 +641,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 Sun Feb 21 21:33:48 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 385707 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 02FEBC433DB for ; Sun, 21 Feb 2021 21:36:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C5CB564EBE for ; Sun, 21 Feb 2021 21:36:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231222AbhBUVgB (ORCPT ); Sun, 21 Feb 2021 16:36:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230516AbhBUVfI (ORCPT ); Sun, 21 Feb 2021 16:35:08 -0500 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 C7223C061794 for ; Sun, 21 Feb 2021 13:34:11 -0800 (PST) Received: by mail-ej1-x62e.google.com with SMTP id u20so25384045ejb.7 for ; Sun, 21 Feb 2021 13:34:11 -0800 (PST) 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=UqFesGulIMwJDkH9ePR4lANvy3siG3rdUdqpoeTimIQ=; b=XH5qKMhEwrNBrXO7xMINN6IsRnE7ZJImZz4LCp/Ld6TT+87qWJlemCAs/+sv8FehOv iViAaWuOYpFt43IhTeWvvIfP+DeSH5j+a/g7sr2Izr2QdQHKtx7j8GcN80YLosioOvmF vrxpYN+M0rb0HBGun/JxX8b2DZMn7Ab0uvBgEaIBKV2tIHUvOJI2bq8ODCDZnKvoPRI1 KRlqDf9zOxTszTdloCtD4SdIfsjjQDRuGs3OJKbZYQnB8x3NtuRD5ViK4yS/tk8db8VF zHsd7awEK1UGaI/hn91r2NHBQ0WYGNl2nZwFNQ5gaSCaDXBlMNvRKAwO1Kx8dp7Hkqqi YmSw== 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=UqFesGulIMwJDkH9ePR4lANvy3siG3rdUdqpoeTimIQ=; b=nIaLJEcdtIpr1v7SwiJ0Fw7w3Ww8OQrfTF6mHnulYxypSJLmTf7lIQDZc1tL7g/W/s 8/x+yB/gb9yPlGslNcG+l64iLHR+iYxKTI9mr37i8IwGQ1zOZgD0RLTFRfLDxIU+CXX5 VRSyBfb97MtHxp+lvira2bh4eOxA1FuuARoH7Tkh9P4kPvH3irnpo1jteEBld2mGwXEz nhJJVHb8UevN51vd74fdKkhVdQZ3g8xnOTrlLmElYUGkNTny6kex148LXeP3veoGSSZJ BkHAt9YCr32nW5KJarU2F48JeesooXV097lAy5uO/7xH50ecM7+qC70OEb8jl5IA6v4a zHjw== X-Gm-Message-State: AOAM530Y30sAKmgvWRIAiU1TFUmJoH3cRAjI3pqQNNb/KdDU1GlNFm4P kMix+UOTcFpIMhsWU5Prl9dRRIpyFQI= X-Google-Smtp-Source: ABdhPJzjSDF6ToLk/OXqc4lKHVLbKpmsQ4UxqsQoAYKjDCs1kkMUGhsm9QANxqnGBgzLR75TW/sTKg== X-Received: by 2002:a17:906:68e:: with SMTP id u14mr17473095ejb.380.1613943250344; Sun, 21 Feb 2021 13:34:10 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:10 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 05/12] Documentation: networking: dsa: remove TODO about porting more vendor drivers Date: Sun, 21 Feb 2021 23:33:48 +0200 Message-Id: <20210221213355.1241450-6-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Vladimir Oltean On one hand, the link is dead and therefore useless. On the other hand, there are always more drivers to port, but at this stage, DSA does not need to affirm itself as the driver model to use for Ethernet-connected switches (since we already have 15 tagging protocols supported and probably more switch families from various vendors), so there is nothing actionable to do. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn --- Documentation/networking/dsa/dsa.rst | 2 -- 1 file changed, 2 deletions(-) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 8fb0ceff3418..19ce5bb0a7a4 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -677,5 +677,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 Sun Feb 21 21:33:49 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 386098 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 8934AC433E0 for ; Sun, 21 Feb 2021 21:36:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5826364EBE for ; Sun, 21 Feb 2021 21:36:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231225AbhBUVgJ (ORCPT ); Sun, 21 Feb 2021 16:36:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231187AbhBUVff (ORCPT ); Sun, 21 Feb 2021 16:35:35 -0500 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACB56C061797 for ; Sun, 21 Feb 2021 13:34:12 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id n20so130943ejb.5 for ; Sun, 21 Feb 2021 13:34:12 -0800 (PST) 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=Usl1rqCbmOEg2pvdQd27xpHlcodyRAZEdfcp9vyKaM8=; b=uKXfmdO7v5tynRiQVcfJf59XFi1G2UMTAGvPGArnPeAcGcjlAbpH/pvl9WNagippA9 WwOYYBdhl0MbKjOqf1vJoxm/HhUEvad713TD0PbJiIjKcQZfojLttY8o/b0jvjNoiI3x oT65Vu3jHxZwy7aAfGzqYMW8Xb6M5Zraw3SxA/zTuTNvu6jptpsAlnO7ij1Hp22t8EES OqNgBT4dtUi5GtlbGF2eU3qDgtdmC22xiPKGyaaNAxn83L2oUz0+TrYvX1z4WflSXySc 4poBI+fV+hU29xfivyRKFLBJLxYxphkf/OdoP2DOuaZ370Pyi5LMt3QrydW284ZmlIjM uLag== 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=Usl1rqCbmOEg2pvdQd27xpHlcodyRAZEdfcp9vyKaM8=; b=dhmi9K4ybEXlC0TWDZP0mKxrIMXhRIeDYLB/WI1k4LJBLdG8zyGUmONrwfVrob+VgH tjaohfsL0rnOeKWnL/Bprh2AjIQQ+yiKTC0o5Bv/3SkaP5erh5h7bGJqYyP7jOQLSrwJ k8w9AG0TffGHaF9hbLFv+F8dxYQQgfakG+Pj/Eb2JCJAYMnvSEt43JjANFwzagtX3/O7 KrrAY/vq+TvJuJlPzlo0Mk60iJI3NgxdHqDG/+fnCTXz8Frw11O6yuDo6d7uVxO/ylo5 xjy5OdEyL38SwGdfrbs/R9k6URCEUc60mHlmsc12jCt8oVb4jNTSdI7oiedW0+ZLRS3s VhNA== X-Gm-Message-State: AOAM533PZnmTpE7TlOK1n7jWVbq5ahSAvQtAFJjZ+qoZ1/TjE3fMDmOJ 6PoncrqeRd/X+e2Bgvs+Q3zCWB9qedM= X-Google-Smtp-Source: ABdhPJxJPUODwF0gH0LfZrROO4rmpRRQDz+J+jpVwIl3JSe0B5Ju8uGcuMRsl0Jcdl0N7wuQItowHQ== X-Received: by 2002:a17:906:4e1a:: with SMTP id z26mr17902658eju.349.1613943251267; Sun, 21 Feb 2021 13:34:11 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:10 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 06/12] Documentation: networking: dsa: document the port_bridge_flags method Date: Sun, 21 Feb 2021 23:33:49 +0200 Message-Id: <20210221213355.1241450-7-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.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: 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 19ce5bb0a7a4..3c6560a43ae0 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -597,6 +597,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, in lack + of an explicit address filtering mechanism in the DSA core. + Bridge VLAN filtering --------------------- From patchwork Sun Feb 21 21:33:50 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 385706 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 66375C433DB for ; Sun, 21 Feb 2021 21:36:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2F77164EBE for ; Sun, 21 Feb 2021 21:36:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231206AbhBUVg0 (ORCPT ); Sun, 21 Feb 2021 16:36:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231185AbhBUVff (ORCPT ); Sun, 21 Feb 2021 16:35:35 -0500 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A887FC0617A7 for ; Sun, 21 Feb 2021 13:34:13 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id p2so19425684edm.12 for ; Sun, 21 Feb 2021 13:34:13 -0800 (PST) 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=wLn5Ey/E1lc3VrlQcKa5CIQrW1vv9LmA3yA1oq69pjs=; b=XYMZ94DMXmdwGC3qhNIplHLxl8U/Q40SC03uVaJBiCpjHFk/8/1fYtfG2XuEUSv90M 5LjdI3kbtaUmWYHMAIG4lu2rrYmRMuFkzYhMUjZgEcpHX4gUDtesAqtOYrBCHvrVZ99y 0Eh/RpUMiKUfUIz5j5fuk6JCFVa8rEMahSCVEAGCy/yN11TPf05Pf90clhOLHuH4PYRT y4oBK6DRR79s1rWbELVcBF9AyaRWy4WyvNWkjdB5pIWHKuUpgvAyZ7XthliExztZaj9f kgFL6qx/Faip2iEC/FqZFA0fZ2QSW1YDPJuOsttmAEvJNZD8tqUyR8/pXgon/uS67jOV SyTA== 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=wLn5Ey/E1lc3VrlQcKa5CIQrW1vv9LmA3yA1oq69pjs=; b=ovIDDIOlkLZ/0ION11HzIbSLf1TGLhMU+9mIgbHklgEbCXDMGiDuP7nDLnc4YRJRzp K/p+dw/GoF2oSr/4pYvLe3/DP59KMcqBYq25wsAfDb37ZZ7E5KPbke739OZiyWfHmaAf C2ySBHhkFGVTUXDnIB1MNVVwDcE68mN+Eb4YzHbNIm15YNDdHxfJwesNx5FKVMMkUECE rvhTxDGkGoAeuup8c3tr8dKpbuTTlmmvrifoPCASilYA82j2sNR442HRQojtVd0D/vi9 Y00RfKsf8zHeLggsfcctq0HMW5J3z5usnVpYEtShv7zosI/oRDePFOs12hXEvUHRvp+c iUQA== X-Gm-Message-State: AOAM532Pts2e0xiVHgLNy+jPiNHTWN+ZE/pE5JYLs7gKOe+WedQJsb/2 CymtQlWIu1MENylyflzvAttyU41XAlI= X-Google-Smtp-Source: ABdhPJx8R01Dj6AEB2nEH0m7YcaDc9wUhYoOzBLxsYv4jK7WrHBDKudfRZ1CJmos29LSwzcMXl+i/w== X-Received: by 2002:aa7:cb0d:: with SMTP id s13mr19270256edt.221.1613943252207; Sun, 21 Feb 2021 13:34:12 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:11 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 07/12] Documentation: networking: dsa: mention integration with devlink Date: Sun, 21 Feb 2021 23:33:50 +0200 Message-Id: <20210221213355.1241450-8-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Vladimir Oltean Add a short summary of the devlink features supported by the DSA core. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn --- Documentation/networking/dsa/dsa.rst | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 3c6560a43ae0..463b48714fe9 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -394,6 +394,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 ---------------- @@ -433,6 +434,32 @@ 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 each physical switch in the fabric. +For each devlink device, every physical port (i.e. user ports, CPU ports, DSA +links and 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. Since address tables and + VLAN tables are only inspectable by core iproute2 tools (ip-link, bridge) on + user ports, devlink regions can be created for dumping these tables on the + non-user ports too. +- 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 Sun Feb 21 21:33:51 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 386097 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 0A007C433DB for ; Sun, 21 Feb 2021 21:36:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D6E5864EBE for ; Sun, 21 Feb 2021 21:36:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231238AbhBUVgc (ORCPT ); Sun, 21 Feb 2021 16:36:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40156 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231190AbhBUVff (ORCPT ); Sun, 21 Feb 2021 16:35:35 -0500 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AFCA3C0617A9 for ; Sun, 21 Feb 2021 13:34:14 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id h25so5862654eds.4 for ; Sun, 21 Feb 2021 13:34:14 -0800 (PST) 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=2zYyNpPOqLqu4fXlOOuGHHQD2qu3Ha8IhbOXBQeShV4=; b=VzaSuO2QsW1UiNl+ZpK9L6Z9bZ7jcUh98PdbEG4QIYk25P3hFTei55T/jk3W77a+pP /NMufkFgvxJEfP2bqhgezF5iOzgGr2zcKrCZFVTia/JatFvOQfqAU5Noi8j0BOkaAU8n 2HCV/qSUroabwAEqzVTNPAJAJ1+G8ox5nT6jdisiRoowqArxGtvyOxakPnsG/G+WzwYe MWHgSKiz82fzBzWg9h7Hp4qFP/f4qBqVvVDwJYZnIUek2bQiCHwsj8oLoGHy0PpVRKUx kzGn8doIBLTyXZ8gQppK3sym4s2Y5dXdZRb91wSkazfCPGzrsWmCOKir4BQ8G7CV+eCV zWbw== 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=2zYyNpPOqLqu4fXlOOuGHHQD2qu3Ha8IhbOXBQeShV4=; b=mWX+wULVWmwHdkDUq9vA8jmzeYCanKUeA9jUhXmifp+45SQf6BQQoOIGQsbhrY1Bnc 6dqu3GfntKEDfVoGoBKg9M7n1xmZFmtVpiLAJPThyQm2fUifXHAqfNwcXlFvdJ78MN+V FNFfkAemHSVNHu0SqD0uzDYVftH+pfSrsw9Xxc5Lb+bbdg9dlz6JJhP4Fy0NWCDC2C1G edGJLElWJ3dn+99Ig++X7VXw/xMxKSfr07kpMPQzTYPR2RXPTHeUIn8pr6Nyq+kQGsuy RddR7v4DK/ARmsiBmgQHcptGt/Ne5O51FCDAXQElpjir/VCL+qWcidUVM80Qz6a1nk08 lTtg== X-Gm-Message-State: AOAM532jz0RP18upeNOqiiiFXaRIxLJzX2HaPC1HHJXaSH+X4Qg5jv0t mtxLZxlGl8iq6wnj22Qzf1OjzkufYlw= X-Google-Smtp-Source: ABdhPJzifpBckF8vS+8jERH6Te6TkN+0X8pRB6bmuRSkyuFvDQTq4Eno6m2VxR849ZTKWiI/jd5yxQ== X-Received: by 2002:a50:da8b:: with SMTP id q11mr20010466edj.352.1613943253205; Sun, 21 Feb 2021 13:34:13 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:12 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 08/12] Documentation: networking: dsa: add paragraph for the LAG offload Date: Sun, 21 Feb 2021 23:33:51 +0200 Message-Id: <20210221213355.1241450-9-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Vladimir Oltean Add a short summary of the methods that a driver writer must implement for offloading a link aggregation group, and what is still missing. Cc: Tobias Waldekranz Signed-off-by: Vladimir Oltean --- 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 463b48714fe9..0a5b06cf4d45 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -698,6 +698,38 @@ 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 +physical 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) on a LAG are treated similarly: DSA offloads the same switchdev +port attribute on all members of the LAG. Switchdev objects on a LAG (FDB, MDB) +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 only towards 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 Sun Feb 21 21:33:52 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 385705 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 66480C433E0 for ; Sun, 21 Feb 2021 21:36:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3E10864EBE for ; Sun, 21 Feb 2021 21:36:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231218AbhBUVgt (ORCPT ); Sun, 21 Feb 2021 16:36:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231192AbhBUVff (ORCPT ); Sun, 21 Feb 2021 16:35:35 -0500 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F744C0617AA for ; Sun, 21 Feb 2021 13:34:15 -0800 (PST) Received: by mail-ej1-x635.google.com with SMTP id do6so26120236ejc.3 for ; Sun, 21 Feb 2021 13:34:15 -0800 (PST) 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=AtU1jI36zvlzU7aZb0x5ZQh27mcQmIY9drQEMcXyUJw=; b=kup3r1t7ARCAF93QSEV1aut0MJ8LQxyyDeLXHACPwgB/Nxf9ncF3yVrw7os4iAxCpe fGU9lB9i3MMFSuGkdXvgiLG2FqrsMgdrHjh9ssrZjBQl1XkYeM6QMyacsGMzUxHkUQAX c2LcpFBg3CuuZ+OYVBAYAzUfUhdFcZ/bcq2QOyuOvBPH3eUg6fSqqYOyAl6AlWbtEb+p gSMTVfOiLxtcj9v3yWSmbB9dH1n3H8zVKeQxMzsoiltRgqDXL5JFVDSTbJ+wMk8FJ4P6 zktyHBGY+rOOpMp58hyTmkgKOha2NdoFTcHk+oFdkfpGqHD07g5aEK2Z1qTsFYEC7ScM xEiw== 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=AtU1jI36zvlzU7aZb0x5ZQh27mcQmIY9drQEMcXyUJw=; b=Pc64HacFen5nLdWekuYS2MujQ8gr9GOukGyOIa1vGtmhZNiKFOezRQoUFV4mPZj4if xKplkOqaEczHhZTWcBUl+82GX+kHk+bp+rNI6+UY8mdGOZbCWm6MPWYLSvZjNerhnZwY 5UbV1J0VQ9akP0cGARwkmL4PupuZkaG9zEJRMvVNcUaklHqdiAqBQp968biVEgjDYLDC j9Ex6SKFo9grGDG6xjvYYiLyy7R/HbsW0rnqFwA49d6TGe3F3V3Cykk5rywrDueswQOc SSbjDhrik9xw9cGBaaWtLQdRABLs4ZL62hOkfFnNQI6pdhMO31mXZ1tc6b7rB6jMfVqL 0Vww== X-Gm-Message-State: AOAM530mqnWQUyvAltLEVqJkWoPor+dP1lqojye9ggC3EHx5gunFGx85 KYnx0clZlye/FMCefdniZexVlCDkoFw= X-Google-Smtp-Source: ABdhPJy63mK2zLGZfQVdVsraQY6iqVvpLO/O/CSXIL4OBU5u92ggfgSOyCzAe4ZGeTjnl45eP5Q52w== X-Received: by 2002:a17:906:70d4:: with SMTP id g20mr18435669ejk.361.1613943254191; Sun, 21 Feb 2021 13:34:14 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:13 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 09/12] Documentation: networking: dsa: add paragraph for the MRP offload Date: Sun, 21 Feb 2021 23:33:52 +0200 Message-Id: <20210221213355.1241450-10-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Vladimir Oltean Add a short summary of the methods that a driver writer must implement for getting an MRP instance to work on top of a DSA switch. Cc: Horatiu Vultur Signed-off-by: Vladimir Oltean Horatiu: - Why does ocelot support a single MRP ring if all it does is trap the MRP PDUs to the CPU? What is stopping it from supporting more than one ring? - Why is listening for SWITCHDEV_OBJ_ID_MRP necessary at all, since it does nothing related to hardware configuration? - Why is ocelot_mrp_del_vcap called from both ocelot_mrp_del and from ocelot_mrp_del_ring_role? - Why does ocelot not look at the MRM/MRC ring role at all, and it traps all MRP PDUs to the CPU, even those which it could forward as an MRC? I understood from your commit d8ea7ff3995e ("net: mscc: ocelot: Add support for MRP") description that the hardware should be able of forwarding the Test PDUs as a client, however it is obviously not doing that. Reviewed-by: Florian Fainelli --- 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 0a5b06cf4d45..bf82f2aed29a 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -730,6 +730,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 Sun Feb 21 21:33:53 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 386096 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 1DBD2C433E0 for ; Sun, 21 Feb 2021 21:37:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E422264EBE for ; Sun, 21 Feb 2021 21:37:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231190AbhBUVhD (ORCPT ); Sun, 21 Feb 2021 16:37:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231197AbhBUVfk (ORCPT ); Sun, 21 Feb 2021 16:35:40 -0500 Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CDEAC0617AB for ; Sun, 21 Feb 2021 13:34:16 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id g5so26132881ejt.2 for ; Sun, 21 Feb 2021 13:34:16 -0800 (PST) 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=dkeIZN6BvC8G7vw9Xk24CHI2DtH74P7wJKSIqfDVoRc=; b=NRcJgBNrKZSy0AMF/sOoLTQ7vGdlduK6aFw1Lz01EWGy+3pt+x/vFWbn5KxO7gi4kb 9dXtxVkmunAZOBGEV3e+gxtuFn8nrc8IxcuhCuzhKe6yhGeW+t30oFmR/G8OgqcQAKGR 7Buppp9+eR5EK9JYP8mxCUl3WSbDlr7egySDlxPYE+ad3k0/ZAzge/6xS80AvzFmp8Zb 6D1BLNoQtuIQpXDNwIQyRtkI+6+Zuw+TdMbdMOA3tRIHI+1A2Lf7Vh1FoSJhDvp4tVWv kx3LdwcOmuM9YABCpeuTo3cvqf7mZx/IeDHxQzDQV9yhKtxr9tdjhghU3GeHB9zeDlG3 zWJw== 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=dkeIZN6BvC8G7vw9Xk24CHI2DtH74P7wJKSIqfDVoRc=; b=n98y75BbRBxRCZe4yGT90e9vNbJiBPoXktuW8X0Yq4ddbhsDKSTE8/sjyXIPqs/Fi8 yg9O+LwCxMGrejT7IuW6CAefxiPdjJdGDaWKJClOa31ccVi2RSdTSe+FAZjUdDtZaDRA cLiPYn4VXNOIF7NQSmCh+jGHW/dGHaH6XyTxTe4KED9MmxrOIijoeKHEkpMQiXvhkA6W 9NLpfust+aTBUuOuGwYC70A8JH9TREPl9MRHkYyzD6TWcEXlY+5IEc9S7CimhbpWY3AS 6AJ/f/yS676B3pVmIS+9C2WFt97hh4O/WtqJ0Ij0DPyrT0lXDovqn0N1YFMS3IzNdNdX FJBg== X-Gm-Message-State: AOAM532r2RTq4OV1B4w419wFOyJFwSQRyY8o4ByTYo6LbNlENgwEADtg fmLcWYQaCNAPkWPC3U4O8ZHr9O2uBCo= X-Google-Smtp-Source: ABdhPJw5QP0TC9zPjdbGAocgM2Nzu0rm81Y7IX9QZiCnr3guK4/BNafPwsuurM0yTOXVYaF0o0yr9w== X-Received: by 2002:a17:906:fc5:: with SMTP id c5mr17488154ejk.538.1613943255144; Sun, 21 Feb 2021 13:34:15 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:14 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 10/12] Documentation: networking: dsa: add paragraph for the HSR/PRP offload Date: Sun, 21 Feb 2021 23:33:53 +0200 Message-Id: <20210221213355.1241450-11-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Vladimir Oltean Add a short summary of the methods that a driver writer must implement for offloading a HSR/PRP network interface. Cc: George McCollister Signed-off-by: Vladimir Oltean --- 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 bf82f2aed29a..277045346f3a 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -760,6 +760,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 discovering the 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 aren't (therefore, bridging a hsr network interface with +a physical switch port is not supported). + +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 Sun Feb 21 21:33:54 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 385704 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 0FD26C433E0 for ; Sun, 21 Feb 2021 21:37:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C5E4864EBE for ; Sun, 21 Feb 2021 21:37:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230340AbhBUVha (ORCPT ); Sun, 21 Feb 2021 16:37:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231200AbhBUVfk (ORCPT ); Sun, 21 Feb 2021 16:35:40 -0500 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACE08C061356 for ; Sun, 21 Feb 2021 13:34:17 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id lu16so26020980ejb.9 for ; Sun, 21 Feb 2021 13:34:17 -0800 (PST) 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=VWyBnLjrxcoYNbEyrrXUmFWK/GjiLBF50AfbKv+uTK0=; b=fHb52hYFaOIc83RrPndwuf/AcWh31gNxbOqrWbsx7cYI1VnF+2hXSQmfyT92Cb69lx 5GwJU847cJPvPCKksN3Y0iPbJPB0HpRQYqvnG875G2ViXZMSnGZxAOKzeWuXxOVev0Ur ZBPYHa5XzHlJHjb9WEMiQYs5zYDtPsIV680XG/r9YZZCQf5+6oL647Kpqm7SuA+IQVNS 63fquyN2qm4xy0a0hQ0nMUp2DX1aZpWvzgmxbndAt3pZKdQsdGFjZpDvGduMDfCpW97P JzR5+SjydXVqUjD3KOLj+zx14oUJ4zDHF5+1x0TVGM0WdVkQON8XBf/x5GsBZn2NoJUm +KSA== 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=VWyBnLjrxcoYNbEyrrXUmFWK/GjiLBF50AfbKv+uTK0=; b=gFxW8vsr9vN3llX0GQauL02qZ+mbw9b+bMqZQp9vHExXhRGg3G89h2XZh8cPe2C+C6 TL8xP10LMfcCIzW/gX1uOEnk7po8MnsD1wyydIG6hBDAN2NGY5EvZFNX2+elIyDOzoj0 rKyOLblPgvRZPGbGEn1N9+UVdrDBJWOsTRis28IRfc9866NpJ71gOzBNKfrvwi15ZnU0 lFzg+Xm2lMsciW6JH+8QqlQjrFO4hOc5WbD9L0IEUOGElT9RFTz8yIpCsqyVZmCN31gw YZE0OUiY5Usk74DLTZrKf7Sk6NPVpHsqnFPwLq7OjJtvHM4vY/1jzVihLMakIoD3+bdX STtg== X-Gm-Message-State: AOAM5320+dbYbYtbg1Au62nTtpzTXhB/awVYbq/nA+u72ak0DB+cO7Vn cFLnHGo03CHQ5DyFGqi5BrR7sGoDJXo= X-Google-Smtp-Source: ABdhPJzbGOzi0g1g+TcnTgwBNz9BLfTO9Vkh06o29KtMXFT2gBUWbLB//o3S/nB/3VJr2YUpN6d2+w== X-Received: by 2002:a17:907:925:: with SMTP id au5mr6204465ejc.467.1613943256130; Sun, 21 Feb 2021 13:34:16 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:15 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 11/12] Documentation: networking: switchdev: clarify device driver behavior Date: Sun, 21 Feb 2021 23:33:54 +0200 Message-Id: <20210221213355.1241450-12-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Florian Fainelli This patch provides details on the expected behavior of switchdev enabled network devices when operating in a "stand alone" mode, as well as when being bridge members. This clarifies a number of things that recently came up during a bug fixing session on the b53 DSA switch driver. Signed-off-by: Florian Fainelli Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn --- Documentation/networking/switchdev.rst | 120 +++++++++++++++++++++++++ 1 file changed, 120 insertions(+) diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst index ddc3f35775dc..9fb3e0fd39dc 100644 --- a/Documentation/networking/switchdev.rst +++ b/Documentation/networking/switchdev.rst @@ -385,3 +385,123 @@ 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 into +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 only process untagged Ethernet frames. 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). + +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). + +VLAN devices configured on top of a switchdev network device (e.g: sw0p1.100) +which is a bridge port member must also observe the following behavior: + +- with VLAN filtering turned off, enslaving VLAN devices into the bridge might + be allowed provided that there is sufficient separation using e.g.: a + reserved VLAN ID (4095 for instance) for untagged traffic. The VLAN data path + is used to pop/push the VLAN tag such that the bridge's data path only + processes untagged traffic. + +- with VLAN filtering turned on, these VLAN devices can be created as long as + there is not an existing VLAN entry into the bridge with an identical VID and + port membership. These VLAN devices cannot be enslaved into the bridge since + they duplicate functionality/use case with the bridge's VLAN data path + processing. + +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. + +A 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. + +Finally, even when VLAN filtering in the bridge is turned off, the underlying +switch hardware and driver may still configured itself in a VLAN-aware mode +provided that the behavior described above is observed. + +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 Sun Feb 21 21:33:55 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 386095 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 6F1E4C433DB for ; Sun, 21 Feb 2021 21:37:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 387D664EB3 for ; Sun, 21 Feb 2021 21:37:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231197AbhBUVhk (ORCPT ); Sun, 21 Feb 2021 16:37:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231195AbhBUVfk (ORCPT ); Sun, 21 Feb 2021 16:35:40 -0500 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 94EAEC06121C for ; Sun, 21 Feb 2021 13:34:18 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id g5so26132943ejt.2 for ; Sun, 21 Feb 2021 13:34:18 -0800 (PST) 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=VDtq21AQylYrGBFcER9Qx6Te7qXrewv3zQjWDKbFUHA=; b=X6E7hr4cXNDfPVSCtrat1GpPG79NPTIy777v8y56NKc/Cfl6D9u6KrNaKZgKtHzs/P xz49bHTSPJf6oXCXKPZo4QrkCCaY4sBvnrdrVOoX/89U/qafw6ksC1G4SC/B35YtDvhC QV/AyqsUDRIuIsQb+X9+cYVZ70Raj5NuluI4cfHBRbpfIJ33lzhutnVyrzpS3vWwkpgF tSZ3T4jlwNifkI6Wsywmu2BFCL8Rdae3Pakg8M8WiO2GS6Ap7hXF0JQdc76hL1Gs5yD4 1q0dwwFcjmrqoPMq+TemGaZVrubnwY4WN5phuJsW1lm187gpJjUhb01TnmWLD7k4hxae CIUg== 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=VDtq21AQylYrGBFcER9Qx6Te7qXrewv3zQjWDKbFUHA=; b=g/qjkqJF0L3Q1e9i7lzdjvu1nwoR98yalVs8l0Yk/SNTg9A7uTfD007Vd/OX/A5TG7 y4pf0u2RdgLWDvo3iP9j+lMyGF5uQcddyMNkT8KByZuS1kABKsK++2xHE9ggROSCbdZL uLmfA5YkEcbIkbwkeHIb4MKQEXWlqeANL8211OFgo1jnQqiPBszXjFXnSbVG2DyeGBls ZFP6+bywsvWOrEJGcp27NNwhFX29YPylrtNHROxSQ6ZqbP5bhP4NmM7UBJ2okzu/6fEZ xpbjx2s3+kmWkkerodOnVxfFL3xcztOuMmMSr564Gfp30+DKd9JCHu96FIT9mgkXBrXq MSJg== X-Gm-Message-State: AOAM531yaW29x0ldAwsEW20n0D5JNl1l6v/Mi9Tuck/0uf/Ufcp1rFHS XyZV6RSOt6saVMVz7CRm8uu5ic8wYeQ= X-Google-Smtp-Source: ABdhPJwC7B/58QW2vQQQMwGm/+CRPvb4F5v4Xxx+umLZGWkSyEXrjn28gNgjQpiLSpvLWzXaN+C3PA== X-Received: by 2002:a17:906:2652:: with SMTP id i18mr18148817ejc.213.1613943257147; Sun, 21 Feb 2021 13:34:17 -0800 (PST) Received: from localhost.localdomain ([188.25.217.13]) by smtp.gmail.com with ESMTPSA id rh22sm8948779ejb.105.2021.02.21.13.34.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Feb 2021 13:34:16 -0800 (PST) From: Vladimir Oltean To: netdev@vger.kernel.org Cc: Andrew Lunn , Florian Fainelli , Vivien Didelot , Jiri Pirko , Ido Schimmel , DENG Qingfang , Tobias Waldekranz , George McCollister , Horatiu Vultur , Kurt Kanzenbach Subject: [RFC PATCH net-next 12/12] Documentation: networking: switchdev: fix command for static FDB entries Date: Sun, 21 Feb 2021 23:33:55 +0200 Message-Id: <20210221213355.1241450-13-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210221213355.1241450-1-olteanv@gmail.com> References: <20210221213355.1241450-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.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 --- 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 9fb3e0fd39dc..d5afd2caaf91 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::