From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 71802C43381 for ; Tue, 26 Mar 2019 02:21:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 379E520823 for ; Tue, 26 Mar 2019 02:21:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="N/d6OQaf" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731042AbfCZCVl (ORCPT ); Mon, 25 Mar 2019 22:21:41 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:38450 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730533AbfCZCVl (ORCPT ); Mon, 25 Mar 2019 22:21:41 -0400 Received: by mail-pg1-f195.google.com with SMTP id j26so5491142pgl.5 for ; Mon, 25 Mar 2019 19:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3RP0vRoLXC3ki5b7sfCqG5j0f4hJiTuubrCPSmvk0/0=; b=N/d6OQafGPX/bYiocv127FcPNGZS0TyINhyNU+h1XCJVi7cAzZ3937JL73Jn5uMuIY GyFC8ftbQQ8OwqSQbD34u1WqQuh6XsLIyUuwFK4kVVYbufDJKyw/Kdy/BYRTl2Ew5arm 6iJyMNfExX5nnX96eE9SjXoeWilkpA5SyvkkqWJHdmImhjAUJUU2VUfvK3TkSXHaXizT 39TlLLRY1a09caS52U/VS5OswWgRoepe6wu6lqq8fcBHiwL8wu0hGZmAs1ohjs9WA0w4 tXyJlFCPNNgkdwcmPmUDjIbAnzwIYI2YF8ndXsh/ZISclyC+htaai+BavagurAsn9EOb lShA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3RP0vRoLXC3ki5b7sfCqG5j0f4hJiTuubrCPSmvk0/0=; b=shuTMtp0VYHC2M+rO1dl6vA9i10vRVVyhhCAU4o2QpbTwl5wMTPMCFATO7tNlpD9ps pJFG5hPsi7aXcyqNXqoBtq9gSSntLTghq1nS0Vetyzxu6X7oS21E+VlZtyMClFh9SG55 qdGWqsUVpfWNXm8uvo+BeFZ7L/tjVP4rBnTSBF3T10TAjaJLExREzbs74QkHABstZ1zR o3wRl14mr2tCM/+PGfIMqEczyQJmZjGXCoFD6L4vhr96uvSEvPeKuMUfQrkAmj/ZlmvW VGATalqzbH7lPOFvrlJ/Kh6BPasudQtq9un6SDddtqTSqYNbShCWmpbcZlEQfFxDKlLO acIw== X-Gm-Message-State: APjAAAWWNpnhum0iUsDHQyLdAmFVzXy0K/bo64Qv6+PDrInE/UPKQ6he +N8hokdLkbG/lYJF7mvAY+WIvkHY X-Google-Smtp-Source: APXvYqydbYr8DrvTYfRGlDSM3lAaxG6yV+ERcfX599k3VaclrGeuatiGE7Wj6/22ONzcqnpSWIupwA== X-Received: by 2002:a63:7d03:: with SMTP id y3mr14246879pgc.8.1553566900458; Mon, 25 Mar 2019 19:21:40 -0700 (PDT) Received: from [192.168.1.3] (ip68-101-123-102.oc.oc.cox.net. [68.101.123.102]) by smtp.gmail.com with ESMTPSA id d11sm2988085pgq.6.2019.03.25.19.21.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 19:21:39 -0700 (PDT) Subject: Re: [RFC PATCH net-next 05/13] net: dsa: Optional VLAN-based port separation for switches without tagging To: Vladimir Oltean , davem@davemloft.net, netdev@vger.kernel.org Cc: andrew@lunn.ch, vivien.didelot@gmail.com, linus.walleij@linaro.org References: <20190324032346.32394-1-olteanv@gmail.com> <20190324032346.32394-6-olteanv@gmail.com> From: Florian Fainelli Openpgp: preference=signencrypt Message-ID: <12218a77-b675-6f5d-0116-d23e89a0e1b0@gmail.com> Date: Mon, 25 Mar 2019 19:21:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <20190324032346.32394-6-olteanv@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 3/23/2019 8:23 PM, Vladimir Oltean wrote: > This patch provides generic DSA code for using VLAN (802.1Q) tags for > the same purpose as a dedicated switch tag for injection/extraction. > It is based on the discussions and interest that has been so far > expressed in https://www.spinics.net/lists/netdev/msg556125.html. > > Unlike all other DSA-supported tagging protocols, CONFIG_NET_DSA_TAG_8021Q > does not offer a complete solution for drivers (nor can it). Instead, it > provides generic code that driver can opt into calling: > - dsa_8021q_xmit: Inserts a VLAN header with the specified contents. > Currently a few driver are inserting headers that are simply 802.1Q > with custom fields. Can be called from another tagging protocol's xmit > function. > - dsa_8021q_rcv: Retrieves the TPID and TCI from a VLAN-tagged skb. > Removing the VLAN header is left as a decision for the caller to make. > - dsa_port_setup_8021q_tagging: For each user port, installs an Rx VID > and a Tx VID, for proper untagged traffic identification on ingress > and steering on egress. Also sets up the VLAN trunk on the upstream > (CPU or DSA) port. Drivers are intentionally left to call this > function explicitly, depending on the context and hardware support. > The expected switch behavior and VLAN semantics should not be violated > under any conditions. That is, after calling > dsa_port_setup_8021q_tagging, the hardware should still pass all > ingress traffic, be it tagged or untagged. > > This only works when switch ports are standalone, or when they are added > to a VLAN-unaware bridge. It will probably remain this way for the > reasons below. > > When added to a bridge that has vlan_filtering 1, the bridge core will > install its own VLANs and reset the pvids through switchdev. For the > bridge core, switchdev is a write-only pipe. All VLAN-related state is > kept in the bridge core and nothing is read from DSA/switchdev or from > the driver. So the bridge core will break this port separation because > it will install the vlan_default_pvid into all switchdev ports. > > Even if we could teach the bridge driver about switchdev preference of a > certain vlan_default_pvid, there would still exist many other challenges. > > Firstly, in the DSA rcv callback, a driver would have to perform an > iterative reverse lookup to find the correct switch port. That is > because the port is a bridge slave, so its Rx VID (port PVID) is subject > to user configuration. How would we ensure that the user doesn't reset > the pvid to a different value, or to a non-unique value within this DSA > switch tree? > > Finally, not all switch ports are equal in DSA, and that makes it > difficult for the bridge to be completely aware of this anyway. > The CPU port needs to transmit tagged packets (VLAN trunk) in order for > the DSA rcv code to be able to decode source information. > But the bridge code has absolutely no idea which switch port is the CPU > port, if nothing else then just because there is no netdevice registered > by DSA for the CPU port. That is true, although we can use the bridge master device as a substitute for targeting the CPU port (we don't have any for the DSA ports though, so they will have to remain in a mode where they forward all VIDs), see . We don't support that just yet in DSA though. > Also DSA does not currently allow the user to specify that they want the > CPU port to do VLAN trunking anyway. VLANs are added to the CPU port > using the same flags as they were added on the user port. > > So the VLANs installed by dsa_port_setup_8021q_tagging per driver > request should remain private from the bridge's and user's perspective, > and should not alter the hardware's behavior with VLAN-tagged traffic. > If the hardware cannot handle VLAN tag stacking, it should also disable > this port separation when added as slave to a vlan_filtering bridge. > If the hardware does support VLAN tag stacking, it should somehow back > up its private VLAN settings when the bridge tries to override them. This is an excellent commit message and it captures really well the challenges involved in trying to coerce 802.1Q only switches into offering separate DSA slave network devices. Here are a few ideas on how this can be solved now or later, with possibly a reduction in functionality: - if the switch internally performs double VLAN tag normalization, then we could dedicate an outer tag per bridge device, which would allow identical inner tag VID numbers to co-exist, yet preserve broadcast domain isolation - when only 802.1Q is supported (single tagging), we could somehow enforce that all ports must be part of a VLAN aware bridge, which would eliminate the need to have standalone DSA network devices alongside bridged DSA network devices Your solution clearly works and is a clever way to solve that problem. [snip] > +config NET_DSA_TAG_8021Q > + bool > + help This probably needs a depends on/select VLAN_8021Q to be functional. > @@ -0,0 +1,185 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* Copyright (c) 2019, Vladimir Oltean > + */ > +#include > +#include > + > +#include "dsa_priv.h" > + > +#define DSA_TAGGING_VID_RANGE (DSA_MAX_SWITCHES * DSA_MAX_PORTS) > +#define DSA_TAGGING_VID_BASE (VLAN_N_VID - 2 * DSA_TAGGING_VID_RANGE - 1) VLAN_N_VID may not be a range supported on all switches (e.g.: the ones that were once popular 15 years ago, like BCM5325/5365) but that can be changed later on to incorporate per-switch VLAN range limitations. I would add a comment about why you reserving two times the space, for which you provide an explanation down below. With the Kconfig changed: Reviewed-by: Florian Fainelli -- Florian