1. 03 Oct, 2017 10 commits
    • Colin Ian King's avatar
      net: dsa: lan9303: make functions lan9303_mdio_phy_{read|write} static · 161ae6b0
      Colin Ian King authored
      The functions lan9303_mdio_phy_write and lan9303_mdio_phy_read are local
      to the source and do not need to be in global scope, so make them static.
      
      Cleans up sparse warnings:
      symbol 'lan9303_mdio_phy_write' was not declared. Should it be static?
      symbol 'lan9303_mdio_phy_read' was not declared. Should it be static?
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      161ae6b0
    • David S. Miller's avatar
      Merge branch 'mlxsw-mc-route-offload' · da885b61
      David S. Miller authored
      Jiri Pirko says:
      
      ====================
      mlxsw: Add support for partial multicast route offload
      
      Yotam says:
      
      Previous patchset introduced support for offloading multicast MFC routes to
      the Spectrum hardware. As described in that patchset, no partial offloading
      is supported, i.e if a route has one output interface which is not a valid
      offloadable device (e.g. pimreg device, dummy device, management NIC), the
      route is trapped to the CPU and the forwarding is done in slow-path.
      
      Add support for partial offloading of multicast routes, by letting the
      hardware to forward the packet to all the in-hardware devices, while the
      kernel ipmr module will continue forwarding to all other interfaces.
      
      Similarly to the bridge, the kernel ipmr module will forward a marked
      packet to an interface only if the interface has a different parent ID than
      the packet's ingress interfaces.
      
      The first patch introduces the offload_mr_fwd_mark skb field, which can be
      used by offloading drivers to indicate that a packet had already gone
      through multicast forwarding in hardware, similarly to the offload_fwd_mark
      field that indicates that a packet had already gone through L2 forwarding
      in hardware.
      
      Patches 2 and 3 change the ipmr module to not forward packets that had
      already been forwarded by the hardware, i.e. packets that are marked with
      offload_mr_fwd_mark and the ingress VIF shares the same parent ID with the
      egress VIF.
      
      Patches 4, 5, 6 and 7 add the support in the mlxsw Spectrum driver for trap
      and forward routes, while marking the trapped packets with the
      offload_mr_fwd_mark.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      da885b61
    • Yotam Gigi's avatar
      mlxsw: spectrum: mr: Support trap-and-forward routes · f60c2549
      Yotam Gigi authored
      Add the support of trap-and-forward route action in the multicast routing
      offloading logic. A route will be set to trap-and-forward action if one (or
      more) of its output interfaces is not offload-able, i.e. does not have a
      valid Spectrum RIF.
      
      This way, a route with mixed output VIFs list, which contains both
      offload-able and un-offload-able devices can go through partial offloading
      in hardware, and the rest will be done in the kernel ipmr module.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f60c2549
    • Yotam Gigi's avatar
      mlxsw: spectrum: mr_tcam: Add trap-and-forward multicast route · 607feade
      Yotam Gigi authored
      In addition to the current multicast route actions, which include trap
      route action and a forward route action, add the trap-and-forward multicast
      route action, and implement it in the multicast routing hardware logic.
      
      To implement that, add a trap-and-forward ACL action as the last action in
      the route flexible action set. The used trap is the ACL2 trap, which marks
      the packets with offload_mr_forward_mark, to prevent the packet from being
      forwarded again by the kernel.
      
      Note: At that stage the offloading logic does not support trap-and-forward
      multicast routes. This patch adds the support only in the hardware logic.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      607feade
    • Yotam Gigi's avatar
      mlxsw: spectrum: Add trap for multicast trap-and-forward routes · a0040c8c
      Yotam Gigi authored
      When a multicast route is configured with trap-and-forward action, the
      packets should be marked with skb->offload_mr_fwd_mark, in order to prevent
      the packets from being forwarded again by the kernel ipmr module.
      
      Due to this, it is not possible to use the already existing multicast trap
      (MLXSW_TRAP_ID_ACL1) as the packet should be marked differently. Add the
      MLXSW_TRAP_ID_ACL2 which is for trap-and-forward multicast routes, and set
      the offload_mr_fwd_mark skb field in its handler.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0040c8c
    • Yotam Gigi's avatar
      mlxsw: acl: Introduce ACL trap and forward action · 26787243
      Yotam Gigi authored
      Use trap/discard flex action to implement trap and forward. The action will
      later be used for multicast routing, as the multicast routing mechanism is
      done using ACL flexible actions in Spectrum hardware. Using that action, it
      will be possible to implement a trap-and-forward route.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26787243
    • Yotam Gigi's avatar
      ipv4: ipmr: Don't forward packets already forwarded by hardware · a5bc9294
      Yotam Gigi authored
      Change the ipmr module to not forward packets if:
       - The packet is marked with the offload_mr_fwd_mark, and
       - Both input interface and output interface share the same parent ID.
      
      This way, a packet can go through partial multicast forwarding in the
      hardware, where it will be forwarded only to the devices that share the
      same parent ID (AKA, reside inside the same hardware). The kernel will
      forward the packet to all other interfaces.
      
      To do this, add the ipmr_offload_forward helper, which per skb, ingress VIF
      and egress VIF, returns whether the forwarding was offloaded to hardware.
      The ipmr_queue_xmit frees the skb and does not forward it if the result is
      a true value.
      
      All the forwarding path code compiles out when the CONFIG_NET_SWITCHDEV is
      not set.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Reviewed-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5bc9294
    • Yotam Gigi's avatar
      ipv4: ipmr: Add the parent ID field to VIF struct · 5d8b3e69
      Yotam Gigi authored
      In order to allow the ipmr module to do partial multicast forwarding
      according to the device parent ID, add the device parent ID field to the
      VIF struct. This way, the forwarding path can use the parent ID field
      without invoking switchdev calls, which requires the RTNL lock.
      
      When a new VIF is added, set the device parent ID field in it by invoking
      the switchdev_port_attr_get call.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5d8b3e69
    • Yotam Gigi's avatar
      skbuff: Add the offload_mr_fwd_mark field · abf4bb6b
      Yotam Gigi authored
      Similarly to the offload_fwd_mark field, the offload_mr_fwd_mark field is
      used to allow partial offloading of MFC multicast routes.
      
      Switchdev drivers can offload MFC multicast routes to the hardware by
      registering to the FIB notification chain. When one of the route output
      interfaces is not offload-able, i.e. has different parent ID, the route
      cannot be fully offloaded by the hardware. Examples to non-offload-able
      devices are a management NIC, dummy device, pimreg device, etc.
      
      Similar problem exists in the bridge module, as one bridge can hold
      interfaces with different parent IDs. At the bridge, the problem is solved
      by the offload_fwd_mark skb field.
      
      Currently, when a route cannot go through full offload, the only solution
      for a switchdev driver is not to offload it at all and let the packet go
      through slow path.
      
      Using the offload_mr_fwd_mark field, a driver can indicate that a packet
      was already forwarded by hardware to all the devices with the same parent
      ID as the input device. Further patches in this patch-set are going to
      enhance ipmr to skip multicast forwarding to devices with the same parent
      ID if a packets is marked with that field.
      
      The reason why the already existing "offload_fwd_mark" bit cannot be used
      is that a switchdev driver would want to make the distinction between a
      packet that has already gone through L2 forwarding but did not go through
      multicast forwarding, and a packet that has already gone through both L2
      and multicast forwarding.
      
      For example: when a packet is ingressing from a switchport enslaved to a
      bridge, which is configured with multicast forwarding, the following
      scenarios are possible:
       - The packet can be trapped to the CPU due to exception while multicast
         forwarding (for example, MTU error). In that case, it had already gone
         through L2 forwarding in the hardware, thus A switchdev driver would
         want to set the skb->offload_fwd_mark and not the
         skb->offload_mr_fwd_mark.
       - The packet can also be trapped due to a pimreg/dummy device used as one
         of the output interfaces. In that case, it can go through both L2 and
         (partial) multicast forwarding inside the hardware, thus a switchdev
         driver would want to set both the skb->offload_fwd_mark and
         skb->offload_mr_fwd_mark.
      Signed-off-by: default avatarYotam Gigi <yotamg@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellaox.com>
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      abf4bb6b
    • Arjun Vynipadath's avatar
      cxgb4: Update comment for min_mtu · a047fbae
      Arjun Vynipadath authored
      We have lost a comment for minimum mtu value set for netdevice with
      'commit d894be57 ("ethernet: use net core MTU range checking in
      more drivers"). Updating it accordingly.
      Signed-off-by: default avatarArjun Vynipadath <arjun@chelsio.com>
      Signed-off-by: default avatarGanesh Goudar <ganeshgr@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a047fbae
  2. 02 Oct, 2017 30 commits