1. 07 5月, 2020 1 次提交
  2. 22 4月, 2020 4 次提交
  3. 16 4月, 2020 1 次提交
    • V
      net: mscc: ocelot: fix untagged packet drops when enslaving to vlan aware bridge · 87b0f983
      Vladimir Oltean 提交于
      To rehash a previous explanation given in commit 1c44ce56 ("net:
      mscc: ocelot: fix vlan_filtering when enslaving to bridge before link is
      up"), the switch driver operates the in a mode where a single VLAN can
      be transmitted as untagged on a particular egress port. That is the
      "native VLAN on trunk port" use case.
      
      The configuration for this native VLAN is driven in 2 ways:
       - Set the egress port rewriter to strip the VLAN tag for the native
         VID (as it is egress-untagged, after all).
       - Configure the ingress port to drop untagged and priority-tagged
         traffic, if there is no native VLAN. The intention of this setting is
         that a trunk port with no native VLAN should not accept untagged
         traffic.
      
      Since both of the above configurations for the native VLAN should only
      be done if VLAN awareness is requested, they are actually done from the
      ocelot_port_vlan_filtering function, after the basic procedure of
      toggling the VLAN awareness flag of the port.
      
      But there's a problem with that simplistic approach: we are trying to
      juggle with 2 independent variables from a single function:
       - Native VLAN of the port - its value is held in port->vid.
       - VLAN awareness state of the port - currently there are some issues
         here, more on that later*.
      The actual problem can be seen when enslaving the switch ports to a VLAN
      filtering bridge:
       0. The driver configures a pvid of zero for each port, when in
          standalone mode. While the bridge configures a default_pvid of 1 for
          each port that gets added as a slave to it.
       1. The bridge calls ocelot_port_vlan_filtering with vlan_aware=true.
          The VLAN-filtering-dependent portion of the native VLAN
          configuration is done, considering that the native VLAN is 0.
       2. The bridge calls ocelot_vlan_add with vid=1, pvid=true,
          untagged=true. The native VLAN changes to 1 (change which gets
          propagated to hardware).
       3. ??? - nobody calls ocelot_port_vlan_filtering again, to reapply the
          VLAN-filtering-dependent portion of the native VLAN configuration,
          for the new native VLAN of 1. One can notice that after toggling "ip
          link set dev br0 type bridge vlan_filtering 0 && ip link set dev br0
          type bridge vlan_filtering 1", the new native VLAN finally makes it
          through and untagged traffic finally starts flowing again. But
          obviously that shouldn't be needed.
      
      So it is clear that 2 independent variables need to both re-trigger the
      native VLAN configuration. So we introduce the second variable as
      ocelot_port->vlan_aware.
      
      *Actually both the DSA Felix driver and the Ocelot driver already had
      each its own variable:
       - Ocelot: ocelot_port_private->vlan_aware
       - Felix: dsa_port->vlan_filtering
      but the common Ocelot library needs to work with a single, common,
      variable, so there is some refactoring done to move the vlan_aware
      property from the private structure into the common ocelot_port
      structure.
      
      Fixes: 97bb69e1 ("net: mscc: ocelot: break apart ocelot_vlan_port_apply")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87b0f983
  4. 31 3月, 2020 2 次提交
  5. 28 3月, 2020 1 次提交
  6. 05 3月, 2020 2 次提交
    • V
      net: dsa: felix: Allow unknown unicast traffic towards the CPU port module · 1cf3299b
      Vladimir Oltean 提交于
      Compared to other DSA switches, in the Ocelot cores, the RX filtering is
      a much more important concern.
      
      Firstly, the primary use case for Ocelot is non-DSA, so there isn't any
      secondary Ethernet MAC [the DSA master's one] to implicitly drop frames
      having a DMAC we are not interested in.  So the switch driver itself
      needs to install FDB entries towards the CPU port module (PGID_CPU) for
      the MAC address of each switch port, in each VLAN installed on the port.
      Every address that is not whitelisted is implicitly dropped. This is in
      order to achieve a behavior similar to N standalone net devices.
      
      Secondly, even in the secondary use case of DSA, such as illustrated by
      Felix with the NPI port mode, that secondary Ethernet MAC is present,
      but its RX filter is bypassed. This is because the DSA tags themselves
      are placed before Ethernet, so the DMAC that the switch ports see is
      not seen by the DSA master too (since it's shifter to the right).
      
      So RX filtering is pretty important. A good RX filter won't bother the
      CPU in case the switch port receives a frame that it's not interested
      in, and there exists no other line of defense.
      
      Ocelot is pretty strict when it comes to RX filtering: non-IP multicast
      and broadcast traffic is allowed to go to the CPU port module, but
      unknown unicast isn't. This means that traffic reception for any other
      MAC addresses than the ones configured on each switch port net device
      won't work. This includes use cases such as macvlan or bridging with a
      non-Ocelot (so-called "foreign") interface. But this seems to be fine
      for the scenarios that the Linux system embedded inside an Ocelot switch
      is intended for - it is simply not interested in unknown unicast
      traffic, as explained in Allan Nielsen's presentation [0].
      
      On the other hand, the Felix DSA switch is integrated in more
      general-purpose Linux systems, so it can't afford to drop that sort of
      traffic in hardware, even if it will end up doing so later, in software.
      
      Actually, unknown unicast means more for Felix than it does for Ocelot.
      Felix doesn't attempt to perform the whitelisting of switch port MAC
      addresses towards PGID_CPU at all, mainly because it is too complicated
      to be feasible: while the MAC addresses are unique in Ocelot, by default
      in DSA all ports are equal and inherited from the DSA master. This adds
      into account the question of reference counting MAC addresses (delayed
      ocelot_mact_forget), not to mention reference counting for the VLAN IDs
      that those MAC addresses are installed in. This reference counting
      should be done in the DSA core, and the fact that it wasn't needed so
      far is due to the fact that the other DSA switches don't have the DSA
      tag placed before Ethernet, so the DSA master is able to whitelist the
      MAC addresses in hardware.
      
      So this means that even regular traffic termination on a Felix switch
      port happens through flooding (because neither Felix nor Ocelot learn
      source MAC addresses from CPU-injected frames).
      
      So far we've explained that whitelisting towards PGID_CPU:
      - helps to reduce the likelihood of spamming the CPU with frames it
        won't process very far anyway
      - is implemented in the ocelot driver
      - is sufficient for the ocelot use cases
      - is not feasible in DSA
      - breaks use cases in DSA, in the current status (whitelisting enabled
        but no MAC address whitelisted)
      
      So the proposed patch allows unknown unicast frames to be sent to the
      CPU port module. This is done for the Felix DSA driver only, as Ocelot
      seems to be happy without it.
      
      [0]: https://www.youtube.com/watch?v=B1HhxEcU7JgSuggested-by: NAllan W. Nielsen <allan.nielsen@microchip.com>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NAllan W. Nielsen <allan.nielsen@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1cf3299b
    • V
      net: mscc: ocelot: eliminate confusion between CPU and NPI port · 69df578c
      Vladimir Oltean 提交于
      Ocelot has the concept of a CPU port. The CPU port is represented in the
      forwarding and the queueing system, but it is not a physical device. The
      CPU port can either be accessed via register-based injection/extraction
      (which is the case of Ocelot), via Frame-DMA (similar to the first one),
      or "connected" to a physical Ethernet port (called NPI in the datasheet)
      which is the case of the Felix DSA switch.
      
      In Ocelot the CPU port is at index 11.
      In Felix the CPU port is at index 6.
      
      The CPU bit is treated special in the forwarding, as it is never cleared
      from the forwarding port mask (once added to it). Other than that, it is
      treated the same as a normal front port.
      
      Both Felix and Ocelot should use the CPU port in the same way. This
      means that Felix should not use the NPI port directly when forwarding to
      the CPU, but instead use the CPU port.
      
      This patch is fixing this such that Felix will use port 6 as its CPU
      port, and just use the NPI port to carry the traffic.
      
      Therefore, eliminate the "ocelot->cpu" variable which was holding the
      index of the NPI port for Felix, and the index of the CPU port module
      for Ocelot, so the variable was actually configuring different things
      for different drivers and causing at least part of the confusion.
      
      Also remove the "ocelot->num_cpu_ports" variable, which is the result of
      another confusion. The 2 CPU ports mentioned in the datasheet are
      because there are two frame extraction channels (register based or DMA
      based). This is of no relevance to the driver at the moment, and
      invisible to the analyzer module.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Suggested-by: NAllan W. Nielsen <allan.nielsen@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69df578c
  7. 04 3月, 2020 5 次提交
  8. 06 1月, 2020 1 次提交
  9. 28 11月, 2019 1 次提交
  10. 22 11月, 2019 3 次提交
  11. 16 11月, 2019 6 次提交
  12. 12 11月, 2019 2 次提交
    • V
      net: mscc: ocelot: split assignment of the cpu port into a separate function · 21468199
      Vladimir Oltean 提交于
      Now that the places that configure routing destinations for the CPU port
      have been marked as such, allow callers to specify their own CPU port
      that is different than ocelot->num_phys_ports. A user will be the Felix
      DSA driver, where the CPU port is one of the physical ports (NPI mode).
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21468199
    • V
      net: mscc: ocelot: separate net_device related items out of ocelot_port · 004d44f6
      Vladimir Oltean 提交于
      The ocelot and ocelot_port structures will be used by a new DSA driver,
      so the ocelot_board.c file will have to allocate and work with a private
      structure (ocelot_port_private), which embeds the generic struct
      ocelot_port. This is because in DSA, at least one interface does not
      have a net_device, and the DSA driver API does not interact with that
      anyway.
      
      The ocelot_port structure is equivalent to dsa_port, and ocelot to
      dsa_switch. The members of ocelot_port which have an equivalent in
      dsa_port (such as dp->vlan_filtering) have been moved to
      ocelot_port_private.
      
      We want to enforce the coding convention that "ocelot_port" refers to
      the structure, and "port" refers to the integer index. One can retrieve
      the structure at any time from ocelot->ports[port].
      
      The patch is large but only contains variable renaming and mechanical
      movement of fields from one structure to another.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      004d44f6
  13. 07 11月, 2019 1 次提交
  14. 16 8月, 2019 3 次提交
  15. 03 6月, 2019 1 次提交
  16. 30 5月, 2019 1 次提交
  17. 23 5月, 2019 1 次提交
  18. 28 2月, 2019 1 次提交
  19. 24 11月, 2018 1 次提交
    • P
      ocelot: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL · 0e332c85
      Petr Machata 提交于
      Following patches will change the way of distributing port object
      changes from a switchdev operation to a switchdev notifier. The
      switchdev code currently recursively descends through layers of lower
      devices, eventually calling the op on a front-panel port device. The
      notifier will instead be sent referencing the bridge port device, which
      may be a stacking device that's one of front-panel ports uppers, or a
      completely unrelated device.
      
      Dispatch the new events to ocelot_port_obj_add() resp. _del() to
      maintain the same behavior that the switchdev operation based code
      currently has. Pass through switchdev_handle_port_obj_add() / _del() to
      handle the recursive descend, because Ocelot supports LAG uppers.
      
      Register to the new switchdev blocking notifier chain to get the new
      events when they start getting distributed.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e332c85
  20. 06 10月, 2018 2 次提交