1. 01 Mar, 2022 2 commits
    • Roopa Prabhu's avatar
      vxlan: move to its own directory · 67653936
      Roopa Prabhu authored
      vxlan.c has grown too long. This patch moves
      it to its own directory. subsequent patches add new
      functionality in new files.
      Signed-off-by: default avatarRoopa Prabhu <roopa@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      67653936
    • Jakub Kicinski's avatar
      Merge branch 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux · f2b77012
      Jakub Kicinski authored
      Saeed Mahameed says:
      
      ====================
      mlx5-next 2022-22-02
      
      The following PR includes updates to mlx5-next branch:
      
      Headlines:
      ==========
      
      1) Jakub cleans up unused static inline functions
      
      2) I did some low level firmware command interface return status changes to
      provide the caller with full visibility on the error/status returned by
      the Firmware.
      
      3) Use the new command interface in RDMA DEVX usecases to avoid flooding
      dmesg with some "expected" user error prone use cases.
      
      4) Moshe also uses the new command interface to grab the specific error
      code from MFRL register command to provide the exact error reason for
      why SW reset couldn't perform internally in FW.
      
      5) From Mark Bloch: Lag, drop packets in hardware when possible
      
      In active-backup mode the inactive interface's packets are dropped by the
      bond device. In switchdev where TC rules are offloaded to the FDB
      this can lead to packets being hit in the FDB where without offload
      they would have been dropped before reaching TC rules in the kernel.
      
      Create a drop rule to make sure packets on inactive ports are dropped
      before reaching the FDB.
      
      Listen on NETDEV_CHANGEUPPER / NETDEV_CHANGEINFODATA events and record
      the inactive state and offload accordingly.
      
      * 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux:
        net/mlx5: Add clarification on sync reset failure
        net/mlx5: Add reset_state field to MFRL register
        RDMA/mlx5: Use new command interface API
        net/mlx5: cmdif, Refactor error handling and reporting of async commands
        net/mlx5: Use mlx5_cmd_do() in core create_{cq,dct}
        net/mlx5: cmdif, Add new api for command execution
        net/mlx5: cmdif, cmd_check refactoring
        net/mlx5: cmdif, Return value improvements
        net/mlx5: Lag, offload active-backup drops to hardware
        net/mlx5: Lag, record inactive state of bond device
        net/mlx5: Lag, don't use magic numbers for ports
        net/mlx5: Lag, use local variable already defined to access E-Switch
        net/mlx5: E-switch, add drop rule support to ingress ACL
        net/mlx5: E-switch, remove special uplink ingress ACL handling
        net/mlx5: E-Switch, reserve and use same uplink metadata across ports
        net/mlx5: Add ability to insert to specific flow group
        mlx5: remove unused static inlines
      ====================
      
      Link: https://lore.kernel.org/r/20220223233930.319301-1-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f2b77012
  2. 28 Feb, 2022 17 commits
  3. 27 Feb, 2022 20 commits
    • David S. Miller's avatar
      Merge branch 'dsa-fdb-isolation' · b42a738e
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      DSA FDB isolation
      
      There are use cases which need FDB isolation between standalone ports
      and bridged ports, as well as isolation between ports of different
      bridges. Most of these use cases are a result of the fact that packets
      can now be partially forwarded by the software bridge, so one port might
      need to send a packet to the CPU but its FDB lookup will see that it can
      forward it directly to a bridge port where that packet was autonomously
      learned. So the source port will attempt to shortcircuit the CPU and
      forward autonomously, which it can't due to the forwarding isolation we
      have in place. So we will have packet drops instead of proper operation.
      
      Additionally, before DSA can implement IFF_UNICAST_FLT for standalone
      ports, we must have control over which database we install FDB entries
      corresponding to port MAC addresses in. We don't want to hinder the
      operation of the bridging layer.
      
      DSA does not have a driver API that encourages FDB isolation, so this
      needs to be created. The basis for this is a new struct dsa_db which
      annotates each FDB and MDB entry with the database it belongs to.
      
      The sja1105 and felix drivers are modified to observe the dsa_db
      argument, and therefore, enforce the FDB isolation.
      
      Compared to the previous RFC patch series from August:
      https://patchwork.kernel.org/project/netdevbpf/cover/20210818120150.892647-1-vladimir.oltean@nxp.com/
      
      what is different is that I stopped trying to make SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE
      blocking, instead I'm making use of the fact that DSA waits for switchdev FDB work
      items to finish before a port leaves the bridge. This is possible since:
      https://patchwork.kernel.org/project/netdevbpf/patch/20211024171757.3753288-7-vladimir.oltean@nxp.com/
      
      Additionally, v2 is also rebased over the DSA LAG FDB work.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b42a738e
    • Vladimir Oltean's avatar
      net: mscc: ocelot: enforce FDB isolation when VLAN-unaware · 54c31984
      Vladimir Oltean authored
      Currently ocelot uses a pvid of 0 for standalone ports and ports under a
      VLAN-unaware bridge, and the pvid of the bridge for ports under a
      VLAN-aware bridge. Standalone ports do not perform learning, but packets
      received on them are still subject to FDB lookups. So if the MAC DA that
      a standalone port receives has been also learned on a VLAN-unaware
      bridge port, ocelot will attempt to forward to that port, even though it
      can't, so it will drop packets.
      
      So there is a desire to avoid that, and isolate the FDBs of different
      bridges from one another, and from standalone ports.
      
      The ocelot switch library has two distinct entry points: the felix DSA
      driver and the ocelot switchdev driver.
      
      We need to code up a minimal bridge_num allocation in the ocelot
      switchdev driver too, this is copied from DSA with the exception that
      ocelot does not care about DSA trees, cross-chip bridging etc. So it
      only looks at its own ports that are already in the same bridge.
      
      The ocelot switchdev driver uses the bridge_num it has allocated itself,
      while the felix driver uses the bridge_num allocated by DSA. They are
      both stored inside ocelot_port->bridge_num by the common function
      ocelot_port_bridge_join() which receives the bridge_num passed by value.
      
      Once we have a bridge_num, we can only use it to enforce isolation
      between VLAN-unaware bridges. As far as I can see, ocelot does not have
      anything like a FID that further makes VLAN 100 from a port be different
      to VLAN 100 from another port with regard to FDB lookup. So we simply
      deny multiple VLAN-aware bridges.
      
      For VLAN-unaware bridges, we crop the 4000-4095 VLAN region and we
      allocate a VLAN for each bridge_num. This will be used as the pvid of
      each port that is under that VLAN-unaware bridge, for as long as that
      bridge is VLAN-unaware.
      
      VID 0 remains only for standalone ports. It is okay if all standalone
      ports use the same VID 0, since they perform no address learning, the
      FDB will contain no entry in VLAN 0, so the packets will always be
      flooded to the only possible destination, the CPU port.
      
      The CPU port module doesn't need to be member of the VLANs to receive
      packets, but if we use the DSA tag_8021q protocol, those packets are
      part of the data plane as far as ocelot is concerned, so there it needs
      to. Just ensure that the DSA tag_8021q CPU port is a member of all
      reserved VLANs when it is created, and is removed when it is deleted.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54c31984
    • Vladimir Oltean's avatar
      net: dsa: sja1105: enforce FDB isolation · 219827ef
      Vladimir Oltean authored
      For sja1105, to enforce FDB isolation simply means to turn on
      Independent VLAN Learning unconditionally, and to remap VLAN-unaware FDB
      and MDB entries towards the private VLAN allocated by tag_8021q for each
      bridge.
      
      Standalone ports each have their own standalone tag_8021q VLAN. No
      learning happens in that VLAN due to:
      - learning being disabled on standalone user ports
      - learning being disabled on the CPU port (we use
        assisted_learning_on_cpu_port which only installs bridge FDBs)
      
      VLAN-aware ports learn FDB entries with the bridge VLANs.
      
      VLAN-unaware bridge ports learn with the tag_8021q VLAN for bridging.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      219827ef
    • Vladimir Oltean's avatar
      net: dsa: pass extack to .port_bridge_join driver methods · 06b9cce4
      Vladimir Oltean authored
      As FDB isolation cannot be enforced between VLAN-aware bridges in lack
      of hardware assistance like extra FID bits, it seems plausible that many
      DSA switches cannot do it. Therefore, they need to reject configurations
      with multiple VLAN-aware bridges from the two code paths that can
      transition towards that state:
      
      - joining a VLAN-aware bridge
      - toggling VLAN awareness on an existing bridge
      
      The .port_vlan_filtering method already propagates the netlink extack to
      the driver, let's propagate it from .port_bridge_join too, to make sure
      that the driver can use the same function for both.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06b9cce4
    • Vladimir Oltean's avatar
      net: dsa: request drivers to perform FDB isolation · c2693363
      Vladimir Oltean authored
      For DSA, to encourage drivers to perform FDB isolation simply means to
      track which bridge does each FDB and MDB entry belong to. It then
      becomes the driver responsibility to use something that makes the FDB
      entry from one bridge not match the FDB lookup of ports from other
      bridges.
      
      The top-level functions where the bridge is determined are:
      - dsa_port_fdb_{add,del}
      - dsa_port_host_fdb_{add,del}
      - dsa_port_mdb_{add,del}
      - dsa_port_host_mdb_{add,del}
      
      aka the pre-crosschip-notifier functions.
      
      Changing the API to pass a reference to a bridge is not superfluous, and
      looking at the passed bridge argument is not the same as having the
      driver look at dsa_to_port(ds, port)->bridge from the ->port_fdb_add()
      method.
      
      DSA installs FDB and MDB entries on shared (CPU and DSA) ports as well,
      and those do not have any dp->bridge information to retrieve, because
      they are not in any bridge - they are merely the pipes that serve the
      user ports that are in one or multiple bridges.
      
      The struct dsa_bridge associated with each FDB/MDB entry is encapsulated
      in a larger "struct dsa_db" database. Although only databases associated
      to bridges are notified for now, this API will be the starting point for
      implementing IFF_UNICAST_FLT in DSA. There, the idea is to install FDB
      entries on the CPU port which belong to the corresponding user port's
      port database. These are supposed to match only when the port is
      standalone.
      
      It is better to introduce the API in its expected final form than to
      introduce it for bridges first, then to have to change drivers which may
      have made one or more assumptions.
      
      Drivers can use the provided bridge.num, but they can also use a
      different numbering scheme that is more convenient.
      
      DSA must perform refcounting on the CPU and DSA ports by also taking
      into account the bridge number. So if two bridges request the same local
      address, DSA must notify the driver twice, once for each bridge.
      
      In fact, if the driver supports FDB isolation, DSA must perform
      refcounting per bridge, but if the driver doesn't, DSA must refcount
      host addresses across all bridges, otherwise it would be telling the
      driver to delete an FDB entry for a bridge and the driver would delete
      it for all bridges. So introduce a bool fdb_isolation in drivers which
      would make all bridge databases passed to the cross-chip notifier have
      the same number (0). This makes dsa_mac_addr_find() -> dsa_db_equal()
      say that all bridge databases are the same database - which is
      essentially the legacy behavior.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c2693363
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: rename dsa_8021q_bridge_tx_fwd_offload_vid · b6362bdf
      Vladimir Oltean authored
      The dsa_8021q_bridge_tx_fwd_offload_vid is no longer used just for
      bridge TX forwarding offload, it is the private VLAN reserved for
      VLAN-unaware bridging in a way that is compatible with FDB isolation.
      
      So just rename it dsa_tag_8021q_bridge_vid.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6362bdf
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: merge RX and TX VLANs · 04b67e18
      Vladimir Oltean authored
      In the old Shared VLAN Learning mode of operation that tag_8021q
      previously used for forwarding, we needed to have distinct concepts for
      an RX and a TX VLAN.
      
      An RX VLAN could be installed on all ports that were members of a given
      bridge, so that autonomous forwarding could still work, while a TX VLAN
      was dedicated for precise packet steering, so it just contained the CPU
      port and one egress port.
      
      Now that tag_8021q uses Independent VLAN Learning and imprecise RX/TX
      all over, those lines have been blurred and we no longer have the need
      to do precise TX towards a port that is in a bridge. As for standalone
      ports, it is fine to use the same VLAN ID for both RX and TX.
      
      This patch changes the tag_8021q format by shifting the VLAN range it
      reserves, and halving it. Previously, our DIR bits were encoding the
      VLAN direction (RX/TX) and were set to either 1 or 2. This meant that
      tag_8021q reserved 2K VLANs, or 50% of the available range.
      
      Change the DIR bits to a hardcoded value of 3 now, which makes tag_8021q
      reserve only 1K VLANs, and a different range now (the last 1K). This is
      done so that we leave the old format in place in case we need to return
      to it.
      
      In terms of code, the vid_is_dsa_8021q_rxvlan and vid_is_dsa_8021q_txvlan
      functions go away. Any vid_is_dsa_8021q is both a TX and an RX VLAN, and
      they are no longer distinct. For example, felix which did different
      things for different VLAN types, now needs to handle the RX and the TX
      logic for the same VLAN.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04b67e18
    • Vladimir Oltean's avatar
      net: dsa: felix: delete workarounds present due to SVL tag_8021q bridging · 08f44db3
      Vladimir Oltean authored
      The felix driver, which also has a tagging protocol implementation based
      on tag_8021q, does not care about adding the RX VLAN that is pvid on one
      port on the other ports that are in the same bridge with it. It simply
      doesn't need that, because in its implementation, the RX VLAN that is
      pvid of a port is only used to install a TCAM rule that pushes that VLAN
      ID towards the CPU port.
      
      Now that tag_8021q no longer performs Shared VLAN Learning based
      forwarding, the RX VLANs are actually segregated into two types:
      standalone VLANs and VLAN-unaware bridging VLANs. Since you actually
      have to call dsa_tag_8021q_bridge_join() to get a bridging VLAN from
      tag_8021q, and felix does not do that because it doesn't need it, it
      means that it only gets standalone port VLANs from tag_8021q. Which is
      perfect because this means it can drop its workarounds that avoid the
      VLANs it does not need.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      08f44db3
    • Vladimir Oltean's avatar
      docs: net: dsa: sja1105: document limitations of tc-flower rule VLAN awareness · d27656d0
      Vladimir Oltean authored
      After change "net: dsa: tag_8021q: replace the SVL bridging with
      VLAN-unaware IVL bridging", tag_8021q enforces two different pvids on a
      port, depending on whether it is standalone or in a VLAN-unaware bridge.
      
      Up until now, there was a single pvid, represented by
      dsa_tag_8021q_rx_vid(), and that was used as the VLAN for VLAN-unaware
      virtual link rules, regardless of whether the port was bridged or
      standalone.
      
      To keep VLAN-unaware virtual links working, we need to follow whether
      the port is in a bridge or not, and update the VLAN ID from those rules.
      
      In fact we can't fully do that. Depending on whether the switch is
      VLAN-aware or not, we can accept Virtual Link rules with just the MAC
      DA, or with a MAC DA and a VID. So we already deny changes to the VLAN
      awareness of the switch. But the VLAN awareness may also change as a
      result of joining or leaving a bridge.
      
      One might say we could just allow the following: a port may leave a
      VLAN-unaware bridge while it has VLAN-unaware VL (tc-flower) rules, and
      the driver will update those with the new tag_8021q pvid for standalone
      mode, but the driver won't accept joining a bridge at all while VL rules
      were installed in standalone mode. This is sort of a compromise made
      because leaving a bridge is an operation that cannot be vetoed.
      But this sort of setup change is not fully supported, either: as
      mentioned, VLAN filtering changes can also be triggered by leaving a
      bridge, therefore, the existing veto we have in place for turning VLAN
      filtering off with VLAN-aware VL rules active still isn't fully
      effective.
      
      I really don't know how to deal with this in a way that produces
      predictable behavior for user space. Since at the moment, keeping this
      feature fully functional on constellation changes (not changing the
      tag_8021q port pvid when joining a bridge) is blocking progress for the
      DSA FDB isolation, I'd rather document it as a (potentially temporary)
      limitation and go on without it.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d27656d0
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: add support for imprecise RX based on the VBID · d7f9787a
      Vladimir Oltean authored
      The sja1105 switch can't populate the PORT field of the tag_8021q header
      when sending a frame to the CPU with a non-zero VBID.
      
      Similar to dsa_find_designated_bridge_port_by_vid() which performs
      imprecise RX for VLAN-aware bridges, let's introduce a helper in
      tag_8021q for performing imprecise RX based on the VLAN that it has
      allocated for a VLAN-unaware bridge.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7f9787a
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: replace the SVL bridging with VLAN-unaware IVL bridging · 91495f21
      Vladimir Oltean authored
      For VLAN-unaware bridging, tag_8021q uses something perhaps a bit too
      tied with the sja1105 switch: each port uses the same pvid which is also
      used for standalone operation (a unique one from which the source port
      and device ID can be retrieved when packets from that port are forwarded
      to the CPU). Since each port has a unique pvid when performing
      autonomous forwarding, the switch must be configured for Shared VLAN
      Learning (SVL) such that the VLAN ID itself is ignored when performing
      FDB lookups. Without SVL, packets would always be flooded, since FDB
      lookup in the source port's VLAN would never find any entry.
      
      First of all, to make tag_8021q more palatable to switches which might
      not support Shared VLAN Learning, let's just use a common VLAN for all
      ports that are under the same bridge.
      
      Secondly, using Shared VLAN Learning means that FDB isolation can never
      be enforced. But if all ports under the same VLAN-unaware bridge share
      the same VLAN ID, it can.
      
      The disadvantage is that the CPU port can no longer perform precise
      source port identification for these packets. But at least we have a
      mechanism which has proven to be adequate for that situation: imprecise
      RX (dsa_find_designated_bridge_port_by_vid), which is what we use for
      termination on VLAN-aware bridges.
      
      The VLAN ID that VLAN-unaware bridges will use with tag_8021q is the
      same one as we were previously using for imprecise TX (bridge TX
      forwarding offload). It is already allocated, it is just a matter of
      using it.
      
      Note that because now all ports under the same bridge share the same
      VLAN, the complexity of performing a tag_8021q bridge join decreases
      dramatically. We no longer have to install the RX VLAN of a newly
      joining port into the port membership of the existing bridge ports.
      The newly joining port just becomes a member of the VLAN corresponding
      to that bridge, and the other ports are already members of it from when
      they joined the bridge themselves. So forwarding works properly.
      
      This means that we can unhook dsa_tag_8021q_bridge_{join,leave} from the
      cross-chip notifier level dsa_switch_bridge_{join,leave}. We can put
      these calls directly into the sja1105 driver.
      
      With this new mode of operation, a port controlled by tag_8021q can have
      two pvids whereas before it could only have one. The pvid for standalone
      operation is different from the pvid used for VLAN-unaware bridging.
      This is done, again, so that FDB isolation can be enforced.
      Let tag_8021q manage this by deleting the standalone pvid when a port
      joins a bridge, and restoring it when it leaves it.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      91495f21
    • David S. Miller's avatar
      Merge branch 'FFungible-ethernet-driver' · 1bb1c5bc
      David S. Miller authored
      Dimitris Michailidis says:
      
      ====================
      new Fungible Ethernet driver
      
      This patch series contains a new network driver for the Ethernet
      functionality of Fungible cards.
      
      It contains two modules. The first one in patch 2 is a library module
      that implements some of the device setup, queue managenent, and support
      for operating an admin queue. These are placed in a separate module
      because the cards provide a number of PCI functions handled by different
      types of drivers and all use the same common means to interact with the
      device. Each of the drivers will be relying on this library module for
      them.
      
      The remaining patches provide the Ethernet driver for the cards.
      
      v2:
      - Fix set_pauseparam, remove get_wol, remove module param (Andrew Lunn)
      - Fix a register poll loop (Andrew)
      - Replace constants defined with 'static const'
      - make W=1 C=1 is clean
      - Remove devlink FW update (Jakub)
      - Remove duplicate ethtool stats covered by structured API (Jakub)
      
      v3:
      - Make TLS stats unconditional (Andrew)
      - Remove inline from .c (Andrew)
      - Replace some ifdef with IS_ENABLED (Andrew)
      - Fix build failure on 32b arches (build robot)
      - Fix build issue with make O= (Jakub)
      
      v4:
      - Fix for newer bpf_warn_invalid_xdp_action() (Jakub)
      - Remove 32b dma_set_mask_and_coherent()
      
      v5:
      - Make XDP enter/exit non-disruptive to active traffic
      - Remove dormant port state
      - Style fixes, unused stuff removal (Jakub)
      
      v6:
      - When changing queue depth or numbers allocate the new queues
        before shutting down the existing ones (Jakub)
      
      v7:
      - Convert IRQ bookeeping to use XArray.
      - Changes to the numbers of Tx/Rx queues are now incremental and
        do not disrupt ongoing traffic.
      - Implement .ndo_eth_ioctl instead of .ndo_do_ioctl.
      - Replace deprecated irq_set_affinity_hint.
      - Remove TLS 1.3 support (Jakub)
      - Remove hwtstamp_config.flags check (Jakub)
      - Add locking in SR-IOV enable/disable. (Jakub)
      
      v8:
      - Remove dropping of <33B packets and the associated counter (Jakub)
      - Report CQE size.
      - Show last MAC stats when the netdev isn't running (Andrew)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1bb1c5bc
    • Dimitris Michailidis's avatar
      net/fungible: Kconfig, Makefiles, and MAINTAINERS · 749efb1e
      Dimitris Michailidis authored
      Hook up the new driver to configuration and build.
      Signed-off-by: default avatarDimitris Michailidis <dmichail@fungible.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      749efb1e
    • Dimitris Michailidis's avatar
      net/funeth: add kTLS TX control part · a3662007
      Dimitris Michailidis authored
      This provides the control pieces for kTLS Tx offload, implementinng the
      offload operations.
      Signed-off-by: default avatarDimitris Michailidis <dmichail@fungible.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a3662007
    • Dimitris Michailidis's avatar
      net/funeth: add the data path · db37bc17
      Dimitris Michailidis authored
      Add the driver's data path. Tx handles skbs, XDP, and kTLS, Rx has skbs
      and XDP. Also included are Rx and Tx queue creation/tear-down and
      tracing.
      Signed-off-by: default avatarDimitris Michailidis <dmichail@fungible.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db37bc17
    • Dimitris Michailidis's avatar
      net/funeth: devlink support · d1d899f2
      Dimitris Michailidis authored
      The devlink part, which is minimal at this time giving just the driver
      name.
      Signed-off-by: default avatarDimitris Michailidis <dmichail@fungible.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d1d899f2
    • Dimitris Michailidis's avatar
      net/funeth: ethtool operations · 21c5ea95
      Dimitris Michailidis authored
      Add ethtool operations, primarily related to queues and ports, as well
      as device statistics.
      Signed-off-by: default avatarDimitris Michailidis <dmichail@fungible.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21c5ea95
    • Dimitris Michailidis's avatar
      net/funeth: probing and netdev ops · ee6373dd
      Dimitris Michailidis authored
      This is the first part of the Fungible ethernet driver. It deals with
      device probing, net_device creation, and netdev ops.
      Signed-off-by: default avatarDimitris Michailidis <dmichail@fungible.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee6373dd
    • Dimitris Michailidis's avatar
      net/fungible: Add service module for Fungible drivers · e1ffcc66
      Dimitris Michailidis authored
      Fungible cards have a number of different PCI functions and thus
      different drivers, all of which use a common method to initialize and
      interact with the device. This commit adds a library module that
      collects these common mechanisms. They mainly deal with device
      initialization, setting up and destroying queues, and operating an admin
      queue. A subset of the FW interface is also included here.
      Signed-off-by: default avatarDimitris Michailidis <dmichail@fungible.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e1ffcc66
    • Dimitris Michailidis's avatar
      PCI: Add Fungible Vendor ID to pci_ids.h · e8eb9e32
      Dimitris Michailidis authored
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: linux-pci@vger.kernel.org
      Signed-off-by: default avatarDimitris Michailidis <dmichail@fungible.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8eb9e32
  4. 26 Feb, 2022 1 commit
    • David S. Miller's avatar
      Merge branch 'ip-neigh-skb-reason' · 4aaa4895
      David S. Miller authored
      Menglong Dong says:
      
      ====================
      net: use kfree_skb_reason() for ip/neighbour
      
      In the series "net: use kfree_skb_reason() for ip/udp packet receive",
      reasons for skb drops are added to the packet receive process of IP
      layer. Link:
      
      https://lore.kernel.org/netdev/20220205074739.543606-1-imagedong@tencent.com/
      
      And in the first patch of this series, skb drop reasons are added to
      the packet egress path of IP layer. As kfree_skb() is not used frequent,
      I commit these changes at once and didn't create a patch for every
      functions that involed. Following functions are handled:
      
      __ip_queue_xmit()
      ip_finish_output()
      ip_mc_finish_output()
      ip6_output()
      ip6_finish_output()
      ip6_finish_output2()
      
      Following new drop reasons are introduced (what they mean can be seen
      in the document of them):
      
      SKB_DROP_REASON_IP_OUTNOROUTES
      SKB_DROP_REASON_BPF_CGROUP_EGRESS
      SKB_DROP_REASON_IPV6DISABLED
      SKB_DROP_REASON_NEIGH_CREATEFAIL
      
      In the 2th and 3th patches, kfree_skb_reason() is used in neighbour
      subsystem instead of kfree_skb(). __neigh_event_send() and
      arp_error_report() are involed, and following new drop reasons are
      introduced:
      
      SKB_DROP_REASON_NEIGH_FAILED
      SKB_DROP_REASON_NEIGH_QUEUEFULL
      SKB_DROP_REASON_NEIGH_DEAD
      
      Changes since v2:
      - fix typo in the 1th patch of 'SKB_DROP_REASON_IPV6DSIABLED' reported
        by Roman
      
      Changes since v1:
      - introduce SKB_DROP_REASON_NEIGH_CREATEFAIL for some path in the 1th
        patch
      - introduce SKB_DROP_REASON_NEIGH_DEAD in the 2th patch
      - simplify the document for the new drop reasons, as David Ahern
        suggested
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4aaa4895