1. 07 May, 2019 7 commits
    • David S. Miller's avatar
      Merge branch 'net-dsa-lantiq-Add-bridge-offloading' · 09934b03
      David S. Miller authored
      Hauke Mehrtens says:
      
      ====================
      net: dsa: lantiq: Add bridge offloading
      
      This adds bridge offloading for the Intel / Lantiq GSWIP 2.1 switch.
      
      Changes since:
      v2:
       - Added Fixes tag to patch 1
       - Fixed typo
       - added GSWIP_TABLE_MAC_BRIDGE_STATIC and made use of it
       - used GSWIP_TABLE_MAC_BRIDGE in more places
      
      v1:
       - fix typo signle -> single
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      09934b03
    • Hauke Mehrtens's avatar
      net: dsa: lantiq: Add Forwarding Database access · 58c59ef9
      Hauke Mehrtens authored
      This adds functions to add and remove static entries to and from the
      forwarding database and dump the full forwarding database.
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58c59ef9
    • Hauke Mehrtens's avatar
      net: dsa: lantiq: Add fast age function · 45813481
      Hauke Mehrtens authored
      Fast aging per port is not supported directly by the hardware, it is
      only possible to configure a global aging time.
      
      Do the fast aging by iterating over the MAC forwarding table and remove
      all dynamic entries for a given port.
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      45813481
    • Hauke Mehrtens's avatar
      net: dsa: lantiq: Add VLAN aware bridge offloading · 9bbb1c05
      Hauke Mehrtens authored
      The VLAN aware bridge offloading is similar to the VLAN unaware
      offloading, this makes it possible to offload the VLAN bridge
      functionalities.
      
      The hardware supports up to 64 VLAN bridge entries, we already use one
      entry for each LAN port to prevent forwarding of packets between the
      ports when the ports are not in a bridge, so in the end we have 57
      possible VLANs.
      
      The VLAN filtering is currently only active when the ports are in a
      bridge, VLAN filtering for ports not in a bridge is not implemented.
      
      It is currently not possible to change between VLAN filtering and not
      filtering while the port is already in a bridge, this would make the
      driver more complicated.
      
      The VLANs are only defined on bridge entries, so we will not add
      anything into the hardware when the port joins a bridge if it is doing
      VLAN filtering, but only when an allowed VLAN is added.
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9bbb1c05
    • Hauke Mehrtens's avatar
      net: dsa: lantiq: Add VLAN unaware bridge offloading · 8206e0ce
      Hauke Mehrtens authored
      This allows to offload bridges with DSA to the switch hardware and do
      the packet forwarding in hardware.
      
      This implements generic functions to access the switch hardware tables,
      which are used to control many features of the switch.
      
      This patch activates the MAC learning by removing the MAC address table
      lock, to prevent uncontrolled forwarding of packets between all the LAN
      ports, they are added into individual bridge tables entries with
      individual flow ids and the switch will do the MAC learning for each
      port separately before they are added to a real bridge.
      
      Each bridge consist of an entry in the active VLAN table and the VLAN
      mapping table, table entries with the same index are matching. In the
      VLAN unaware mode we configure everything with VLAN ID 0, but we use
      different flow IDs, the switch should handle all VLANs as normal payload
      and ignore them. When the hardware looks for the port of the destination
      MAC address it only takes the entries which have the same flow ID of the
      ingress packet.
      
      The bridges are configured with 64 possible entries with these
      information:
      Table Index, 0...63
      VLAN ID, 0...4095: VLAN ID 0 is untagged
      flow ID, 0..63: Same flow IDs share entries in MAC learning table
      port map, one bit for each port number
      tagged port map, one bit for each port number
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8206e0ce
    • Hauke Mehrtens's avatar
      net: dsa: lantiq: Allow special tags only on CPU port · 30d89383
      Hauke Mehrtens authored
      Allow the special tag in ingress only on the CPU port and not on all
      ports. A packet with a special tag could circumvent the hardware
      forwarding and should only be allowed on the CPU port where Linux
      controls the port.
      
      Fixes: 14fceff4 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200)"
      Signed-off-by: default avatarHauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      30d89383
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · 14cfbdac
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf-next 2019-05-06
      
      The following pull-request contains BPF updates for your *net-next* tree.
      
      The main changes are:
      
      1) Two AF_XDP libbpf fixes for socket teardown; first one an invalid
         munmap and the other one an invalid skmap cleanup, both from Björn.
      
      2) More graceful CONFIG_DEBUG_INFO_BTF handling when pahole is not
         present in the system to generate vmlinux btf info, from Andrii.
      
      3) Fix libbpf and thus fix perf build error with uClibc on arc
         architecture, from Vineet.
      
      4) Fix missing libbpf_util.h header install in libbpf, from William.
      
      5) Exclude bash-completion/bpftool from .gitignore pattern, from Masahiro.
      
      6) Fix up rlimit in test_libbpf_open kselftest test case, from Yonghong.
      
      7) Minor misc cleanups.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      14cfbdac
  2. 06 May, 2019 33 commits
    • Björn Töpel's avatar
      libbpf: remove unnecessary cast-to-void · d24ed99b
      Björn Töpel authored
      The patches with fixes tags added a cast-to-void in the places when
      the return value of a function was ignored.
      
      This is not common practice in the kernel, and is therefore removed in
      this patch.
      Reported-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Fixes: 5750902a ("libbpf: proper XSKMAP cleanup")
      Fixes: 0e6741f0 ("libbpf: fix invalid munmap call")
      Signed-off-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      d24ed99b
    • Andrii Nakryiko's avatar
      kbuild: tolerate missing pahole when generating BTF · 581b31c3
      Andrii Nakryiko authored
      When BTF generation is enabled through CONFIG_DEBUG_INFO_BTF,
      scripts/link-vmlinux.sh detects if pahole version is too old and
      gracefully continues build process, skipping BTF generation build step.
      But if pahole is not available, build will still fail. This patch adds
      check for whether pahole exists at all and bails out gracefully, if not.
      
      Cc: Alexei Starovoitov <ast@fb.com>
      Reported-by: default avatarYonghong Song <yhs@fb.com>
      Fixes: e83b9f55 ("kbuild: add ability to generate BTF type info for vmlinux")
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      581b31c3
    • David S. Miller's avatar
      Merge branch 'r8169-replace-some-magic-with-more-speaking-functions' · 54516da1
      David S. Miller authored
      Heiner Kallweit says:
      
      ====================
      r8169: replace some magic with more speaking functions
      
      Based on info from Realtek replace some magic with speaking functions
      even though the exact meaning of certain values isn't known.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54516da1
    • Heiner Kallweit's avatar
      r8169: add rtl8168g_set_pause_thresholds · 0ebacd12
      Heiner Kallweit authored
      Based on info from Realtek add a function for defining the thresholds
      controlling ethernet flow control.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0ebacd12
    • Heiner Kallweit's avatar
      r8169: add rtl_set_fifo_size · 6b1bd242
      Heiner Kallweit authored
      Based on info from Realtek replace FIFO size config magic with
      a function.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b1bd242
    • David S. Miller's avatar
      Merge branch 'mlxsw-spectrum-Implement-loopback-ethtool-feature' · 3a972364
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: spectrum: Implement loopback ethtool feature
      
      This patchset from Jiri allows users to enable loopback feature for
      individual ports using ethtool. The loopback feature is useful for
      testing purposes and will also be used by upcoming patchsets to enable
      the monitoring of buffer drops.
      
      Patch #1 adds the relevant device register.
      
      Patch #2 Implements support in the driver.
      
      Patch #3 adds a selftest.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a972364
    • Jiri Pirko's avatar
      selftests: Add loopback test · ad113409
      Jiri Pirko authored
      Add selftest for loopback feature
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ad113409
    • Jiri Pirko's avatar
      mlxsw: spectrum: Implement loopback ethtool feature · 8e44c0ce
      Jiri Pirko authored
      Allow user to enable loopback feature for individual ports using ethtool.
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e44c0ce
    • Jiri Pirko's avatar
      mlxsw: reg: Add Port Physical Loopback Register · a0c25387
      Jiri Pirko authored
      The PPLR register allows configuration of the port's loopback mode.
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0c25387
    • Cong Wang's avatar
      sch_htb: redefine htb qdisc overlimits · b362487a
      Cong Wang authored
      In commit 3c75f6ee ("net_sched: sch_htb: add per class overlimits counter")
      we added an overlimits counter for each HTB class which could
      properly reflect how many times we use up all the bandwidth
      on each class. However, the overlimits counter in HTB qdisc
      does not, it is way bigger than the sum of each HTB class.
      In fact, this qdisc overlimits counter increases when we have
      no skb to dequeue, which happens more often than we run out of
      bandwidth.
      
      It makes more sense to make this qdisc overlimits counter just
      be a sum of each HTB class, in case people still get confused.
      
      I have verified this patch with one single HTB class, where HTB
      qdisc counters now always match HTB class counters as expected.
      
      Eric suggested we could fold this field into 'direct_pkts' as
      we only use its 32bit on 64bit CPU, this saves one cache line.
      
      Cc: Eric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b362487a
    • Heiner Kallweit's avatar
      r8169: move EEE LED config to rtl8168_config_eee_mac · f452825d
      Heiner Kallweit authored
      Move adjusting the EEE LED frequency to rtl8168_config_eee_mac.
      Exclude RTL8411 (version 38) like in the existing code.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f452825d
    • Heiner Kallweit's avatar
      r8169: simplify rtl_writephy_batch and rtl_ephy_init · 1791ad50
      Heiner Kallweit authored
      Make both functions macros to allow omitting the ARRAY_SIZE(x) argument.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1791ad50
    • David S. Miller's avatar
      Merge branch 'Traffic-support-for-SJA1105-DSA-driver' · 0e5ef5a2
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Traffic support for SJA1105 DSA driver
      
      This patch set is a continuation of the "NXP SJA1105 DSA driver" v3
      series, which was split in multiple pieces for easier review.
      
      Supporting a fully-featured (traffic-capable) driver for this switch
      requires some rework in DSA and also leaves behind a more generic
      infrastructure for other dumb switches that rely on 802.1Q pseudo-switch
      tagging for port separation. Among the DSA changes required are:
      
      * Generic xmit and rcv functions for pushing/popping 802.1Q tags on
        skb's. These are modeled as a tagging protocol of its own but which
        must be customized by drivers to fit their own hardware possibilities.
      
      * Permitting the .setup callback to invoke switchdev operations that
        will loop back into the driver through the switchdev notifier chain.
      
      The SJA1105 driver then proceeds to extend this 8021q switch tagging
      protocol while adding its own (tag_sja1105). This is done because
      the driver actually implements a "dual tagger":
      
      * For normal traffic it uses 802.1Q tags
      
      * For management (multicast DMAC) frames the switch has native support
        for recognizing and annotating these with source port and switch id
        information.
      
      Because this is a "dual tagger", decoding of management frames should
      still function when regular traffic can't (under a bridge with VLAN
      filtering).
      There was intervention in the DSA receive hotpath, where a new
      filtering function called from eth_type_trans() is needed. This is
      useful in the general sense for switches that might actually have some
      limited means of source port decoding, such as only for management
      traffic, but not for everything.
      In order for the 802.1Q tagging protocol (which cannot be enabled under
      all conditions, unlike the management traffic decoding) to not be an
      all-or-nothing choice, the filtering function matches everything that
      can be decoded, and everything else is left to pass to the master
      netdevice.
      
      Lastly, DSA core support was added for drivers to request skb deferral.
      SJA1105 needs this for SPI intervention during transmission of link-local
      traffic. This is not done from within the tagger.
      
      Some patches were carried over unchanged from the previous patchset
      (01/09). Others were slightly reworked while adapting to the recent
      changes in "Make DSA tag drivers kernel modules" (02/09).
      
      The introduction of some structures (DSA_SKB_CB, dp->priv) may seem a
      little premature at this point and the new structures under-utilized.
      The reason is that traffic support has been rewritten with PTP
      timestamping in mind, and then I removed the timestamping code from the
      current submission (1. it is a different topic, 2. it does not work very
      well yet). On demand I can provide the timestamping patchset as a RFC
      though.
      
      "NXP SJA1105 DSA driver" v3 patchset can be found at:
      https://lkml.org/lkml/2019/4/12/978
      
      v1 patchset can be found at:
      https://lkml.org/lkml/2019/5/3/877
      
      Changes in v2:
      
      * Made the deferred xmit workqueue also be drained on the netdev suspend
        callback, not just on ndo_stop.
      
      * Added clarification about how other netdevices may be bridged with the
        switch ports.
      
      v2 patchset can be found at:
      https://www.spinics.net/lists/netdev/msg568818.html
      
      Changes in v3:
      
      * Exported the dsa_port_vid_add and dsa_port_vid_del symbols to fix an
        error reported by the kbuild test robot
      
      * Fixed the following checkpatch warnings in 05/10:
        Macro argument reuse 'skb' - possible side-effects?
        Macro argument reuse 'clone' - possible side-effects?
      
      * Added a commit description to the documentation patch (10/10)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0e5ef5a2
    • Vladimir Oltean's avatar
      Documentation: net: dsa: sja1105: Add info about supported traffic modes · 0a58d471
      Vladimir Oltean authored
      This adds a table which illustrates what combinations of management /
      regular traffic work depending on the state the switch ports are in.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0a58d471
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Add support for Spanning Tree Protocol · 640f763f
      Vladimir Oltean authored
      While not explicitly documented as supported in UM10944, compliance with
      the STP states can be obtained by manipulating 3 settings at the
      (per-port) MAC config level: dynamic learning, inhibiting reception of
      regular traffic, and inhibiting transmission of regular traffic.
      
      In all these modes, transmission and reception of special BPDU frames
      from the stack is still enabled (not inhibited by the MAC-level
      settings).
      
      On ingress, BPDUs are classified by the MAC filter as link-local
      (01-80-C2-00-00-00) and forwarded to the CPU port.  This mechanism works
      under all conditions (even without the custom 802.1Q tagging) because
      the switch hardware inserts the source port and switch ID into bytes 4
      and 5 of the MAC-filtered frames. Then the DSA .rcv handler needs to put
      back zeroes into the MAC address after decoding the source port
      information.
      
      On egress, BPDUs are transmitted using management routes from the xmit
      worker thread. Again this does not require switch tagging, as the switch
      port is programmed through SPI to hold a temporary (single-fire) route
      for a frame with the programmed destination MAC (01-80-C2-00-00-00).
      
      STP is activated using the following commands and was tested by
      connecting two front-panel ports together and noticing that switching
      loops were prevented (one port remains in the blocking state):
      
      $ ip link add name br0 type bridge stp_state 1 && ip link set br0 up
      $ for eth in $(ls /sys/devices/platform/soc/2100000.spi/spi_master/spi0/spi0.1/net/);
        do ip link set ${eth} master br0 && ip link set ${eth} up; done
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      640f763f
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Add support for traffic through standalone ports · 227d07a0
      Vladimir Oltean authored
      In order to support this, we are creating a make-shift switch tag out of
      a VLAN trunk configured on the CPU port. Termination of normal traffic
      on switch ports only works when not under a vlan_filtering bridge.
      Termination of management (PTP, BPDU) traffic works under all
      circumstances because it uses a different tagging mechanism
      (incl_srcpt). We are making use of the generic CONFIG_NET_DSA_TAG_8021Q
      code and leveraging it from our own CONFIG_NET_DSA_TAG_SJA1105.
      
      There are two types of traffic: regular and link-local.
      
      The link-local traffic received on the CPU port is trapped from the
      switch's regular forwarding decisions because it matched one of the two
      DMAC filters for management traffic.
      
      On transmission, the switch requires special massaging for these
      link-local frames. Due to a weird implementation of the switching IP, by
      default it drops link-local frames that originate on the CPU port.
      It needs to be told where to forward them to, through an SPI command
      ("management route") that is valid for only a single frame.
      So when we're sending link-local traffic, we are using the
      dsa_defer_xmit mechanism.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      227d07a0
    • Vladimir Oltean's avatar
      net: dsa: Add a private structure pointer to dsa_port · c362beb0
      Vladimir Oltean authored
      This is supposed to share information between the driver and the tagger,
      or used by the tagger to keep some state. Its use is optional.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c362beb0
    • Vladimir Oltean's avatar
      net: dsa: Add support for deferred xmit · 97a69a0d
      Vladimir Oltean authored
      Some hardware needs to take work to get convinced to receive frames on
      the CPU port (such as the sja1105 which takes temporary L2 forwarding
      rules over SPI that last for a single frame). Such work needs a
      sleepable context, and because the regular .ndo_start_xmit is atomic,
      this cannot be done in the tagger. So introduce a generic DSA mechanism
      that sets up a transmit skb queue and a workqueue for deferred
      transmission.
      
      The new driver callback (.port_deferred_xmit) is in dsa_switch and not
      in the tagger because the operations that require sleeping typically
      also involve interacting with the hardware, and not simply skb
      manipulations. Therefore having it there simplifies the structure a bit
      and makes it unnecessary to export functions from the driver to the
      tagger.
      
      The driver is responsible of calling dsa_enqueue_skb which transfers it
      to the master netdevice. This is so that it has a chance of performing
      some more work afterwards, such as cleanup or TX timestamping.
      
      To tell DSA that skb xmit deferral is required, I have thought about
      changing the return type of the tagger .xmit from struct sk_buff * into
      a enum dsa_tx_t that could potentially encode a DSA_XMIT_DEFER value.
      
      But the trailer tagger is reallocating every skb on xmit and therefore
      making a valid use of the pointer return value. So instead of reworking
      the API in complicated ways, right now a boolean property in the newly
      introduced DSA_SKB_CB is set.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97a69a0d
    • Vladimir Oltean's avatar
      net: dsa: Keep private info in the skb->cb · b68b0dd0
      Vladimir Oltean authored
      Map a DSA structure over the 48-byte control block that will hold
      skb info on transmit and receive. This is only for use within the DSA
      processing layer (e.g. communicating between DSA core and tagger) and
      not for passing info around with other layers such as the master net
      device.
      
      Also add a DSA_SKB_CB_PRIV() macro which retrieves a pointer to the
      space up to 48 bytes that the DSA structure does not use. This space can
      be used for drivers to add their own private info.
      
      One use is for the PTP timestamping code path. When cloning a skb,
      annotate the original with a pointer to the clone, which the driver can
      then find easily and place the timestamp to. This avoids the need of a
      separate queue to hold clones and a way to match an original to a cloned
      skb.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b68b0dd0
    • Vladimir Oltean's avatar
      net: dsa: Allow drivers to filter packets they can decode source port from · cc1939e4
      Vladimir Oltean authored
      Frames get processed by DSA and redirected to switch port net devices
      based on the ETH_P_XDSA multiplexed packet_type handler found by the
      network stack when calling eth_type_trans().
      
      The running assumption is that once the DSA .rcv function is called, DSA
      is always able to decode the switch tag in order to change the skb->dev
      from its master.
      
      However there are tagging protocols (such as the new DSA_TAG_PROTO_SJA1105,
      user of DSA_TAG_PROTO_8021Q) where this assumption is not completely
      true, since switch tagging piggybacks on the absence of a vlan_filtering
      bridge. Moreover, management traffic (BPDU, PTP) for this switch doesn't
      rely on switch tagging, but on a different mechanism. So it would make
      sense to at least be able to terminate that.
      
      Having DSA receive traffic it can't decode would put it in an impossible
      situation: the eth_type_trans() function would invoke the DSA .rcv(),
      which could not change skb->dev, then eth_type_trans() would be invoked
      again, which again would call the DSA .rcv, and the packet would never
      be able to exit the DSA filter and would spiral in a loop until the
      whole system dies.
      
      This happens because eth_type_trans() doesn't actually look at the skb
      (so as to identify a potential tag) when it deems it as being
      ETH_P_XDSA. It just checks whether skb->dev has a DSA private pointer
      installed (therefore it's a DSA master) and that there exists a .rcv
      callback (everybody except DSA_TAG_PROTO_NONE has that). This is
      understandable as there are many switch tags out there, and exhaustively
      checking for all of them is far from ideal.
      
      The solution lies in introducing a filtering function for each tagging
      protocol. In the absence of a filtering function, all traffic is passed
      to the .rcv DSA callback. The tagging protocol should see the filtering
      function as a pre-validation that it can decode the incoming skb. The
      traffic that doesn't match the filter will bypass the DSA .rcv callback
      and be left on the master netdevice, which wasn't previously possible.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc1939e4
    • Vladimir Oltean's avatar
      net: dsa: Optional VLAN-based port separation for switches without tagging · f9bbe447
      Vladimir Oltean authored
      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.
        Can be called from another tagging protocol's xmit function.
        Currently the LAN9303 driver is inserting headers that are simply
        802.1Q with custom fields, so this is an opportunity for code reuse.
      - 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.
      
      For uniformity with the other tagging protocols, a module for the
      dsa_8021q_netdev_ops structure is registered, but the typical usage is
      to set up another tagging protocol which selects CONFIG_NET_DSA_TAG_8021Q,
      and calls the API from tag_8021q.h. Null function definitions are also
      provided so that a "depends on" is not forced in the Kconfig.
      
      This tagging protocol 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 (task difficult in itself since the current
      setting is per-bridge but we would need it per-port), 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 (which would make an O(1) translation
      impossible), or to a non-unique value within this DSA switch tree (which
      would make any translation impossible)?
      
      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.
      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 VLAN semantics observed by the user.
      
      In the current implementation a VLAN range ending at 4095 (VLAN_N_VID)
      is reserved for this purpose. Each port receives a unique Rx VLAN and a
      unique Tx VLAN. Separate VLANs are needed for Rx and Tx because they
      serve different purposes: on Rx the switch must process traffic as
      untagged and process it with a port-based VLAN, but with care not to
      hinder bridging. On the other hand, the Tx VLAN is where the
      reachability restrictions are imposed, since by tagging frames in the
      xmit callback we are telling the switch onto which port to steer the
      frame.
      
      Some general guidance on how this support might be employed for
      real-life hardware (some comments made by Florian Fainelli):
      
      - If the hardware supports VLAN tag stacking, it should somehow back
        up its private VLAN settings when the bridge tries to override them.
        Then the driver could re-apply them as outer tags. Dedicating an outer
        tag per bridge device would allow identical inner tag VID numbers to
        co-exist, yet preserve broadcast domain isolation.
      
      - If the switch cannot handle VLAN tag stacking, it should disable this
        port separation when added as slave to a vlan_filtering bridge, in
        that case having reduced functionality.
      
      - Drivers for old switches that don't support the entire VLAN_N_VID
        range will need to rework the current range selection mechanism.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9bbe447
    • Vladimir Oltean's avatar
      net: dsa: Export symbols for dsa_port_vid_{add, del} · 146c1bed
      Vladimir Oltean authored
      This is needed so that the newly introduced tag_8021q may access these
      core DSA functions when built as a module.
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      146c1bed
    • Vladimir Oltean's avatar
      net: dsa: Call driver's setup callback after setting up its switchdev notifier · b2243b36
      Vladimir Oltean authored
      This allows the driver to perform some manipulations of its own during
      setup, using generic switchdev calls. Having the notifiers registered at
      setup time is important because otherwise any switchdev transaction
      emitted during this time would be ignored (dispatched to an empty call
      chain).
      
      One current usage scenario is for the driver to request DSA to set up
      802.1Q based switch tagging for its ports.
      
      There is no danger for the driver setup code to start racing now with
      switchdev events emitted from the network stack (such as bridge core)
      even if the notifier is registered earlier. This is because the network
      stack needs a net_device as a vehicle to perform switchdev operations,
      and the slave net_devices are registered later than the core driver
      setup anyway (ds->ops->setup in dsa_switch_setup vs dsa_port_setup).
      
      Luckily DSA doesn't need a net_device to carry out switchdev callbacks,
      and therefore drivers shouldn't assume either that net_devices are
      available at the time their switchdev callbacks get invoked.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>-
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b2243b36
    • Vivien Didelot's avatar
      net: dsa: mv88e6xxx: refine SMI support · e7ba0fad
      Vivien Didelot authored
      The Marvell SOHO switches have several ways to access the internal
      registers. One of them being the System Management Interface (SMI),
      using the MDC and MDIO pins, with direct and indirect variants.
      
      In preparation for adding support for other register accesses, move
      the SMI code into its own files. At the same time, refine the code
      to make it clear that the indirect variant is implemented using the
      direct variant accessing only two registers for command and data.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e7ba0fad
    • David S. Miller's avatar
      Merge branch 'net-act_police-offload-support' · 7e6a95d3
      David S. Miller authored
      Jakub Kicinski says:
      
      ===================
      net: act_police offload support
      
      this set starts by converting cls_matchall to the new flow offload
      infrastructure. It so happens that all drivers implementing cls_matchall
      offload today also offload cls_flower, so its a little easier for
      them to handle the actions in unified flow_rule format, even though
      in cls_matchall there is no flow to speak of. If a driver ever appears
      which would prefer the old, direct access to TC exts, we can add the
      pointer in the offload structure back and support both.
      
      Next the act_police is added to actions supported by flow offload API.
      
      NFP support for act_police offload is added as the final step.  The flower
      firmware is configured to perform TX rate limiting in a way which matches
      act_police's behaviour.  It does not use DMA.IN back pressure, and
      instead	drops packets after they had been already DMAed into the NIC.
      IOW it uses our standard traffic policing implementation, future patches
      will extend it to other ports and traffic directions.
      ===================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e6a95d3
    • Pieter Jansen van Vuuren's avatar
      nfp: flower: add qos offload stats request and reply · 5fb5c395
      Pieter Jansen van Vuuren authored
      Add stats request function that sends a stats request message to hw for
      a specific police-filter. Process stats reply from hw and update the
      stored qos structure.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5fb5c395
    • Pieter Jansen van Vuuren's avatar
      nfp: flower: add qos offload install and remove functionality. · 49cbef13
      Pieter Jansen van Vuuren authored
      Add install and remove offload functionality for qos offloads. We
      first check that a police filter can be implemented by the VF rate
      limiting feature in hw, then we install the filter via the qos
      infrastructure. Finally we implement the mechanism for removing
      these types of filters.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49cbef13
    • Pieter Jansen van Vuuren's avatar
      nfp: flower: add qos offload framework · b66d035e
      Pieter Jansen van Vuuren authored
      Introduce matchall filter offload infrastructure that is needed to
      offload qos features like policing. Subsequent patches will make
      use of police-filters for ingress rate limiting.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b66d035e
    • Pieter Jansen van Vuuren's avatar
      net/sched: add block pointer to tc_cls_common_offload structure · 88c44a52
      Pieter Jansen van Vuuren authored
      Some actions like the police action are stateful and could share state
      between devices. This is incompatible with offloading to multiple devices
      and drivers might want to test for shared blocks when offloading.
      Store a pointer to the tcf_block structure in the tc_cls_common_offload
      structure to allow drivers to determine when offloads apply to a shared
      block.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      88c44a52
    • Pieter Jansen van Vuuren's avatar
      net/sched: allow stats updates from offloaded police actions · 12f02b6b
      Pieter Jansen van Vuuren authored
      Implement the stats_update callback for the police action that
      will be used by drivers for hardware offload.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      12f02b6b
    • Pieter Jansen van Vuuren's avatar
      net/sched: extend matchall offload for hardware statistics · b7fe4ab8
      Pieter Jansen van Vuuren authored
      Introduce a new command for matchall classifiers that allows hardware
      to update statistics.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7fe4ab8
    • Pieter Jansen van Vuuren's avatar
      net/sched: add police action to the hardware intermediate representation · 8c8cfc6e
      Pieter Jansen van Vuuren authored
      Add police action to the hardware intermediate representation which
      would subsequently allow it to be used by drivers for offload.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c8cfc6e
    • Pieter Jansen van Vuuren's avatar
      net/sched: move police action structures to header · fa762da9
      Pieter Jansen van Vuuren authored
      Move tcf_police_params, tcf_police and tc_police_compat structures to a
      header. Making them usable to other code for example drivers that would
      offload police actions to hardware.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa762da9