1. 12 Mar, 2021 32 commits
    • Tong Zhang's avatar
      isdn: remove extra spaces in the header file · 8176f8c0
      Tong Zhang authored
      fix some coding style issues in the isdn header
      Signed-off-by: default avatarTong Zhang <ztong0001@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8176f8c0
    • Hoang Huu Le's avatar
      tipc: clean up warnings detected by sparse · 97bc84bb
      Hoang Huu Le authored
      This patch fixes the following warning from sparse:
      
      net/tipc/monitor.c:263:35: warning: incorrect type in assignment (different base types)
      net/tipc/monitor.c:263:35:    expected unsigned int
      net/tipc/monitor.c:263:35:    got restricted __be32 [usertype]
      [...]
      net/tipc/node.c:374:13: warning: context imbalance in 'tipc_node_read_lock' - wrong count at exit
      net/tipc/node.c:379:13: warning: context imbalance in 'tipc_node_read_unlock' - unexpected unlock
      net/tipc/node.c:384:13: warning: context imbalance in 'tipc_node_write_lock' - wrong count at exit
      net/tipc/node.c:389:13: warning: context imbalance in 'tipc_node_write_unlock_fast' - unexpected unlock
      net/tipc/node.c:404:17: warning: context imbalance in 'tipc_node_write_unlock' - unexpected unlock
      [...]
      net/tipc/crypto.c:1201:9: warning: incorrect type in initializer (different address spaces)
      net/tipc/crypto.c:1201:9:    expected struct tipc_aead [noderef] __rcu *__tmp
      net/tipc/crypto.c:1201:9:    got struct tipc_aead *
      [...]
      Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
      Signed-off-by: default avatarHoang Huu Le <hoang.h.le@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97bc84bb
    • Hoang Le's avatar
      tipc: convert dest node's address to network order · 1980d375
      Hoang Le authored
      (struct tipc_link_info)->dest is in network order (__be32), so we must
      convert the value to network order before assigning. The problem detected
      by sparse:
      
      net/tipc/netlink_compat.c:699:24: warning: incorrect type in assignment (different base types)
      net/tipc/netlink_compat.c:699:24:    expected restricted __be32 [usertype] dest
      net/tipc/netlink_compat.c:699:24:    got int
      Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
      Signed-off-by: default avatarHoang Le <hoang.h.le@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1980d375
    • David S. Miller's avatar
      Merge branch 'mlxsw-Implement-sampling-using-mirroring' · 1520929e
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Implement sampling using mirroring
      
      So far, sampling was implemented using a dedicated sampling mechanism
      that is available on all Spectrum ASICs. Spectrum-2 and later ASICs
      support sampling by mirroring packets to the CPU port with probability.
      This method has a couple of advantages compared to the legacy method:
      
      * Extra metadata per-packet: Egress port, egress traffic class, traffic
        class occupancy and end-to-end latency
      * Ability to sample packets on egress / per-flow as opposed to only
        ingress
      
      This series should not result in any user-visible changes and its aim is
      to convert Spectrum-2 and later ASICs to perform sampling by mirroring
      to the CPU port with probability. Future submissions will expose the
      additional metadata and enable sampling using more triggers (e.g.,
      egress).
      
      Series overview:
      
      Patches #1-#3 extend the SPAN (mirroring) module to accept new
      parameters required for sampling. See individual commit messages for
      detailed explanation.
      
      Patch #4-#5 split sampling support between Spectrum-1 and later ASIC while
      still using the legacy method for all ASIC generations.
      
      Patch #6 converts Spectrum-2 and later ASICs to perform sampling by
      mirroring to the CPU port with probability.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1520929e
    • Ido Schimmel's avatar
      mlxsw: spectrum_matchall: Implement sampling using mirroring · cf31190a
      Ido Schimmel authored
      Spectrum-2 and later ASICs support sampling of packets by mirroring to
      the CPU with probability. There are several advantages compared to the
      legacy dedicated sampling mechanism:
      
      * Extra metadata per-packet: Egress port, egress traffic class, traffic
        class occupancy and end-to-end latency
      * Ability to sample packets on egress / per-flow
      
      Convert Spectrum-2 and later ASICs to perform sampling by mirroring to
      the CPU with probability.
      
      Subsequent patches will add support for egress / per-flow sampling and
      expose the extra metadata.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf31190a
    • Ido Schimmel's avatar
      mlxsw: spectrum_trap: Split sampling traps between ASICs · 34a27721
      Ido Schimmel authored
      Sampling of ingress packets is supported using a dedicated sampling
      mechanism on all Spectrum ASICs. However, Spectrum-2 and later ASICs
      support more sophisticated sampling by mirroring packets to the CPU.
      
      As a preparation for more advanced sampling configurations, split the trap
      configuration used for sampled packets between Spectrum-1 and later ASICs.
      
      This is needed since packets that are mirrored to the CPU are trapped
      via a different trap identifier compared to packets that are sampled
      using the dedicated sampling mechanism.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34a27721
    • Ido Schimmel's avatar
      mlxsw: spectrum_matchall: Split sampling support between ASICs · 20afb9bc
      Ido Schimmel authored
      Sampling of ingress packets is supported using a dedicated sampling
      mechanism on all Spectrum ASICs. However, Spectrum-2 and later ASICs
      support more sophisticated sampling by mirroring packets to the CPU.
      
      As a preparation for more advanced sampling configurations, split the
      sampling operations between Spectrum-1 and later ASICs.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20afb9bc
    • Ido Schimmel's avatar
      mlxsw: spectrum_span: Add SPAN probability rate support · 2dcbd920
      Ido Schimmel authored
      Currently, every packet that matches a mirroring trigger (e.g., received
      packets, buffer dropped packets) is mirrored. Spectrum-2 and later ASICs
      support mirroring with probability, where every 1 in N matched packets
      is mirrored.
      
      Extend the API that creates the binding between the trigger and the SPAN
      agent with a probability rate parameter, which is an attribute of the
      trigger. Set it to '1' to maintain existing behavior.
      
      Subsequent patches will use it to perform more sophisticated sampling,
      by mirroring packets to the CPU with probability.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2dcbd920
    • Ido Schimmel's avatar
      mlxsw: reg: Extend mirroring registers with probability rate field · fa3faeb7
      Ido Schimmel authored
      The MPAR and MPAGR registers are used to configure the binding between
      the mirroring trigger (e.g., received packet) and the SPAN agent. Add
      probability rate field, which will allow us to support sampling by
      mirroring to the CPU.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa3faeb7
    • Ido Schimmel's avatar
      mlxsw: spectrum_span: Add SPAN session identifier support · 5c7659eb
      Ido Schimmel authored
      When packets are mirrored to the CPU, the trap identifier with which the
      packets are trapped is determined according to the session identifier of
      the SPAN agent performing the mirroring. Packets that are trapped for
      the same logical reason (e.g., buffer drops) should use the same session
      identifier.
      
      Currently, a single session is implicitly supported (identifier 0) and
      is used for packets that are mirrored to the CPU due to buffer drops
      (e.g., early drop).
      
      Subsequent patches are going to mirror packets to the CPU due to
      sampling, which will require a different session identifier.
      
      Prepare for that by making the session identifier an attribute of the
      SPAN agent.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c7659eb
    • David S. Miller's avatar
      Merge tag 'mlx5-updates-2021-03-11' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 1bc61c9d
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      This series provides some cleanups to mlx5 driver
      For more information please see tag log below.
      
      Please pull and let me know if there is any problem.
      
      mlx5-updates-2021-03-11
      
      Cleanups for mlx5 driver
      
      1) Fix build warnings form Arnd and Vlad
      2) Leon improves locking for driver load/unload flows
      3) From Roi, Lockdep false dependency warning
      4) Other trivial cleanups
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1bc61c9d
    • David S. Miller's avatar
      Merge branch 'nexthop-Resilient-next-hop-groups' · 2a0186a3
      David S. Miller authored
      Petr Machata says:
      
      ====================
      nexthop: Resilient next-hop groups
      
      At this moment, there is only one type of next-hop group: an mpath group.
      Mpath groups implement the hash-threshold algorithm, described in RFC
      2992[1].
      
      To select a next hop, hash-threshold algorithm first assigns a range of
      hashes to each next hop in the group, and then selects the next hop by
      comparing the SKB hash with the individual ranges. When a next hop is
      removed from the group, the ranges are recomputed, which leads to
      reassignment of parts of hash space from one next hop to another. RFC 2992
      illustrates it thus:
      
                   +-------+-------+-------+-------+-------+
                   |   1   |   2   |   3   |   4   |   5   |
                   +-------+-+-----+---+---+-----+-+-------+
                   |    1    |    2    |    4    |    5    |
                   +---------+---------+---------+---------+
      
                    Before and after deletion of next hop 3
      	      under the hash-threshold algorithm.
      
      Note how next hop 2 gave up part of the hash space in favor of next hop 1,
      and 4 in favor of 5. While there will usually be some overlap between the
      previous and the new distribution, some traffic flows change the next hop
      that they resolve to.
      
      If a multipath group is used for load-balancing between multiple servers,
      this hash space reassignment causes an issue that packets from a single
      flow suddenly end up arriving at a server that does not expect them, which
      may lead to TCP reset.
      
      If a multipath group is used for load-balancing among available paths to
      the same server, the issue is that different latencies and reordering along
      the way causes the packets to arrive in the wrong order.
      
      Resilient hashing is a technique to address the above problem. Resilient
      next-hop group has another layer of indirection between the group itself
      and its constituent next hops: a hash table. The selection algorithm uses a
      straightforward modulo operation on the SKB hash to choose a hash table
      bucket, then reads the next hop that this bucket contains, and forwards
      traffic there.
      
      This indirection brings an important feature. In the hash-threshold
      algorithm, the range of hashes associated with a next hop must be
      continuous. With a hash table, mapping between the hash table buckets and
      the individual next hops is arbitrary. Therefore when a next hop is deleted
      the buckets that held it are simply reassigned to other next hops:
      
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |1|1|1|1|2|2|2|2|3|3|3|3|4|4|4|4|5|5|5|5|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      	                      v v v v
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |1|1|1|1|2|2|2|2|1|2|4|5|4|4|4|4|5|5|5|5|
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
                    Before and after deletion of next hop 3
      	      under the resilient hashing algorithm.
      
      When weights of next hops in a group are altered, it may be possible to
      choose a subset of buckets that are currently not used for forwarding
      traffic, and use those to satisfy the new next-hop distribution demands,
      keeping the "busy" buckets intact. This way, established flows are ideally
      kept being forwarded to the same endpoints through the same paths as before
      the next-hop group change.
      
      This patch set adds the implementation of resilient next-hop groups.
      
      In a nutshell, the algorithm works as follows. Each next hop has a number
      of buckets that it wants to have, according to its weight and the number of
      buckets in the hash table. In case of an event that might cause bucket
      allocation change, the numbers for individual next hops are updated,
      similarly to how ranges are updated for mpath group next hops. Following
      that, a new "upkeep" algorithm runs, and for idle buckets that belong to a
      next hop that is currently occupying more buckets than it wants (it is
      "overweight"), it migrates the buckets to one of the next hops that has
      fewer buckets than it wants (it is "underweight"). If, after this, there
      are still underweight next hops, another upkeep run is scheduled to a
      future time.
      
      Chances are there are not enough "idle" buckets to satisfy the new demands.
      The algorithm has knobs to select both what it means for a bucket to be
      idle, and for whether and when to forcefully migrate buckets if there keeps
      being an insufficient number of idle ones.
      
      To illustrate the usage, consider the following commands:
      
       # ip nexthop add id 1 via 192.0.2.2 dev dummy1
       # ip nexthop add id 2 via 192.0.2.3 dev dummy1
       # ip nexthop add id 10 group 1/2 type resilient \
      	buckets 8 idle_timer 60 unbalanced_timer 300
      
      The last command creates a resilient next-hop group. It will have 8
      buckets, each bucket will be considered idle when no traffic hits it for at
      least 60 seconds, and if the table remains out of balance for 300 seconds,
      it will be forcefully brought into balance.
      
      If not present in netlink message, the idle timer defaults to 120 seconds,
      and there is no unbalanced timer, meaning the group may remain unbalanced
      indefinitely. The value of 120 is the default in Cumulus implementation of
      resilient next-hop groups. To a degree the default is arbitrary, the only
      value that certainly does not make sense is 0. Therefore going with an
      existing deployed implementation is reasonable.
      
      Unbalanced time, i.e. how long since the last time that all nexthops had as
      many buckets as they should according to their weights, is reported when
      the group is dumped:
      
       # ip nexthop show id 10
       id 10 group 1/2 type resilient buckets 8 idle_timer 60 unbalanced_timer 300 unbalanced_time 0
      
      When replacing next hops or changing weights, if one does not specify some
      parameters, their value is left as it was:
      
       # ip nexthop replace id 10 group 1,2/2 type resilient
       # ip nexthop show id 10
       id 10 group 1,2/2 type resilient buckets 8 idle_timer 60 unbalanced_timer 300 unbalanced_time 0
      
      It is also possible to do a dump of individual buckets (and now you know
      why there were only 8 of them in the example above):
      
       # ip nexthop bucket show id 10
       id 10 index 0 idle_time 5.59 nhid 1
       id 10 index 1 idle_time 5.59 nhid 1
       id 10 index 2 idle_time 8.74 nhid 2
       id 10 index 3 idle_time 8.74 nhid 2
       id 10 index 4 idle_time 8.74 nhid 1
       id 10 index 5 idle_time 8.74 nhid 1
       id 10 index 6 idle_time 8.74 nhid 1
       id 10 index 7 idle_time 8.74 nhid 1
      
      Note the two buckets that have a shorter idle time. Those are the ones that
      were migrated after the nexthop replace command to satisfy the new demand
      that nexthop 1 be given 6 buckets instead of 4.
      
      The patchset proceeds as follows:
      
      - Patches #1 and #2 are small refactoring patches.
      
      - Patch #3 adds a new flag to struct nh_group, is_multipath. This flag is
        meant to be set for all nexthop groups that in general have several
        nexthops from which they choose, and avoids a more expensive dispatch
        based on reading several flags, one for each nexthop group type.
      
      - Patch #4 contains defines of new UAPI attributes and the new next-hop
        group type. At this point, the nexthop code is made to bounce the new
        type. As the resilient hashing code is gradually added in the following
        patch sets, it will remain dead. The last patch will make it accessible.
      
        This patch also adds a suite of new messages related to next hop buckets.
        This approach was taken instead of overloading the information on the
        existing RTM_{NEW,DEL,GET}NEXTHOP messages for the following reasons.
      
        First, a next-hop group can contain a large number of next-hop buckets
        (4k is not unheard of). This imposes limits on the amount of information
        that can be encoded for each next-hop bucket given a netlink message is
        limited to 64k bytes.
      
        Second, while RTM_NEWNEXTHOPBUCKET is only used for notifications at this
        point, in the future it can be extended to provide user space with
        control over next-hop buckets configuration.
      
      - Patch #5 contains the meat of the resilient next-hop group support.
      
      - Patches #6 and #7 implement support for notifications towards the
        drivers.
      
      - Patch #8 adds an interface for the drivers to report resilient hash
        table bucket activity. Drivers will be able to report through this
        interface whether traffic is hitting a given bucket.
      
      - Patch #9 adds an interface for the drivers to report whether a given
        hash table bucket is offloaded or trapping traffic.
      
      - In patches #10, #11, #12 and #13, UAPI is implemented. This includes all
        the code necessary for creation of resilient groups, bucket dumping and
        getting, and bucket migration notifications.
      
      - In patch #14 the next-hop groups are finally made available.
      
      The overall plan is to contribute approximately the following patchsets:
      
      1) Nexthop policy refactoring (already pushed)
      2) Preparations for resilient next-hop groups (already pushed)
      3) Implementation of resilient next-hop groups (this patchset)
      4) Netdevsim offload plus a suite of selftests
      5) Preparations for mlxsw offload of resilient next-hop groups
      6) mlxsw offload including selftests
      
      Interested parties can look at the current state of the code at [2] and
      [3].
      
      [1] https://tools.ietf.org/html/rfc2992
      [2] https://github.com/idosch/linux/commits/submit/res_integ_v1
      [3] https://github.com/idosch/iproute2/commits/submit/res_v1
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a0186a3
    • Petr Machata's avatar
      nexthop: Enable resilient next-hop groups · 15e1dd57
      Petr Machata authored
      Now that all the code is in place, stop rejecting requests to create
      resilient next-hop groups.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15e1dd57
    • Petr Machata's avatar
      nexthop: Notify userspace about bucket migrations · 0b4818aa
      Petr Machata authored
      Nexthop replacements et.al. are notified through netlink, but if a delayed
      work migrates buckets on the background, userspace will stay oblivious.
      Notify these as RTM_NEWNEXTHOPBUCKET events.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b4818aa
    • Petr Machata's avatar
      nexthop: Add netlink handlers for bucket get · 187d4c6b
      Petr Machata authored
      Allow getting (but not setting) individual buckets to inspect the next hop
      mapped therein, idle time, and flags.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      187d4c6b
    • Petr Machata's avatar
      nexthop: Add netlink handlers for bucket dump · 8a1bbabb
      Petr Machata authored
      Add a dump handler for resilient next hop buckets. When next-hop group ID
      is given, it walks buckets of that group, otherwise it walks buckets of all
      groups. It then dumps the buckets whose next hops match the given filtering
      criteria.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a1bbabb
    • Petr Machata's avatar
      nexthop: Add netlink handlers for resilient nexthop groups · a2601e2b
      Petr Machata authored
      Implement the netlink messages that allow creation and dumping of resilient
      nexthop groups.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2601e2b
    • Ido Schimmel's avatar
      nexthop: Allow reporting activity of nexthop buckets · cfc15c1d
      Ido Schimmel authored
      The kernel periodically checks the idle time of nexthop buckets to
      determine if they are idle and can be re-populated with a new nexthop.
      
      When the resilient nexthop group is offloaded to hardware, the kernel
      will not see activity on nexthop buckets unless it is reported from
      hardware.
      
      Add a function that can be periodically called by device drivers to
      report activity on nexthop buckets after querying it from the underlying
      device.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cfc15c1d
    • Ido Schimmel's avatar
      nexthop: Allow setting "offload" and "trap" indication of nexthop buckets · 56ad5ba3
      Ido Schimmel authored
      Add a function that can be called by device drivers to set "offload" or
      "trap" indication on nexthop buckets following nexthop notifications and
      other changes such as a neighbour becoming invalid.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56ad5ba3
    • Petr Machata's avatar
      nexthop: Implement notifiers for resilient nexthop groups · 7c37c7e0
      Petr Machata authored
      Implement the following notifications towards drivers:
      
      - NEXTHOP_EVENT_REPLACE, when a resilient nexthop group is created.
      
      - NEXTHOP_EVENT_BUCKET_REPLACE any time there is a change in assignment of
        next hops to hash table buckets. That includes replacements, deletions,
        and delayed upkeep cycles. Some bucket notifications can be vetoed by the
        driver, to make it possible to propagate bucket busy-ness flags from the
        HW back to the algorithm. Some are however forced, e.g. if a next hop is
        deleted, all buckets that use this next hop simply must be migrated,
        whether the HW wishes so or not.
      
      - NEXTHOP_EVENT_RES_TABLE_PRE_REPLACE, before a resilient nexthop group is
        replaced. Usually the driver will get the bucket notifications as well,
        and could veto those. But in some cases, a bucket may not be migrated
        immediately, but during delayed upkeep, and that is too late to roll the
        transaction back. This notification allows the driver to take a look and
        veto the new proposed group up front, before anything is committed.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7c37c7e0
    • Ido Schimmel's avatar
      nexthop: Add data structures for resilient group notifications · b8f090d0
      Ido Schimmel authored
      Add data structures that will be used for in-kernel notifications about
      addition / deletion of a resilient nexthop group and about changes to a
      hash bucket within a resilient group.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8f090d0
    • Petr Machata's avatar
      nexthop: Add implementation of resilient next-hop groups · 283a72a5
      Petr Machata authored
      At this moment, there is only one type of next-hop group: an mpath group,
      which implements the hash-threshold algorithm.
      
      To select a next hop, hash-threshold algorithm first assigns a range of
      hashes to each next hop in the group, and then selects the next hop by
      comparing the SKB hash with the individual ranges. When a next hop is
      removed from the group, the ranges are recomputed, which leads to
      reassignment of parts of hash space from one next hop to another. While
      there will usually be some overlap between the previous and the new
      distribution, some traffic flows change the next hop that they resolve to.
      That causes problems e.g. as established TCP connections are reset, because
      the traffic is forwarded to a server that is not familiar with the
      connection.
      
      Resilient hashing is a technique to address the above problem. Resilient
      next-hop group has another layer of indirection between the group itself
      and its constituent next hops: a hash table. The selection algorithm uses a
      straightforward modulo operation to choose a hash bucket, and then reads
      the next hop that this bucket contains, and forwards traffic there.
      
      This indirection brings an important feature. In the hash-threshold
      algorithm, the range of hashes associated with a next hop must be
      continuous. With a hash table, mapping between the hash table buckets and
      the individual next hops is arbitrary. Therefore when a next hop is deleted
      the buckets that held it are simply reassigned to other next hops. When
      weights of next hops in a group are altered, it may be possible to choose a
      subset of buckets that are currently not used for forwarding traffic, and
      use those to satisfy the new next-hop distribution demands, keeping the
      "busy" buckets intact. This way, established flows are ideally kept being
      forwarded to the same endpoints through the same paths as before the
      next-hop group change.
      
      In a nutshell, the algorithm works as follows. Each next hop has a number
      of buckets that it wants to have, according to its weight and the number of
      buckets in the hash table. In case of an event that might cause bucket
      allocation change, the numbers for individual next hops are updated,
      similarly to how ranges are updated for mpath group next hops. Following
      that, a new "upkeep" algorithm runs, and for idle buckets that belong to a
      next hop that is currently occupying more buckets than it wants (it is
      "overweight"), it migrates the buckets to one of the next hops that has
      fewer buckets than it wants (it is "underweight"). If, after this, there
      are still underweight next hops, another upkeep run is scheduled to a
      future time.
      
      Chances are there are not enough "idle" buckets to satisfy the new demands.
      The algorithm has knobs to select both what it means for a bucket to be
      idle, and for whether and when to forcefully migrate buckets if there keeps
      being an insufficient number of idle buckets.
      
      There are three users of the resilient data structures.
      
      - The forwarding code accesses them under RCU, and does not modify them
        except for updating the time a selected bucket was last used.
      
      - Netlink code, running under RTNL, which may modify the data.
      
      - The delayed upkeep code, which may modify the data. This runs unlocked,
        and mutual exclusion between the RTNL code and the delayed upkeep is
        maintained by canceling the delayed work synchronously before the RTNL
        code touches anything. Later it restarts the delayed work if necessary.
      
      The RTNL code has to implement next-hop group replacement, next hop
      removal, etc. For removal, the mpath code uses a neat trick of having a
      backup next hop group structure, doing the necessary changes offline, and
      then RCU-swapping them in. However, the hash tables for resilient hashing
      are about an order of magnitude larger than the groups themselves (the size
      might be e.g. 4K entries), and it was felt that keeping two of them is an
      overkill. Both the primary next-hop group and the spare therefore use the
      same resilient table, and writers are careful to keep all references valid
      for the forwarding code. The hash table references next-hop group entries
      from the next-hop group that is currently in the primary role (i.e. not
      spare). During the transition from primary to spare, the table references a
      mix of both the primary group and the spare. When a next hop is deleted,
      the corresponding buckets are not set to NULL, but instead marked as empty,
      so that the pointer is valid and can be used by the forwarding code. The
      buckets are then migrated to a new next-hop group entry during upkeep. The
      only times that the hash table is invalid is the very beginning and very
      end of its lifetime. Between those points, it is always kept valid.
      
      This patch introduces the core support code itself. It does not handle
      notifications towards drivers, which are kept as if the group were an mpath
      one. It does not handle netlink either. The only bit currently exposed to
      user space is the new next-hop group type, and that is currently bounced.
      There is therefore no way to actually access this code.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      283a72a5
    • Ido Schimmel's avatar
      nexthop: Add netlink defines and enumerators for resilient NH groups · 710ec562
      Ido Schimmel authored
      - RTM_NEWNEXTHOP et.al. that handle resilient groups will have a new nested
        attribute, NHA_RES_GROUP, whose elements are attributes NHA_RES_GROUP_*.
      
      - RTM_NEWNEXTHOPBUCKET et.al. is a suite of new messages that will
        currently serve only for dumping of individual buckets of resilient next
        hop groups. For nexthop group buckets, these messages will carry a nested
        attribute NHA_RES_BUCKET, whose elements are attributes NHA_RES_BUCKET_*.
      
        There are several reasons why a new suite of messages is created for
        nexthop buckets instead of overloading the information on the existing
        RTM_{NEW,DEL,GET}NEXTHOP messages.
      
        First, a nexthop group can contain a large number of nexthop buckets (4k
        is not unheard of). This imposes limits on the amount of information that
        can be encoded for each nexthop bucket given a netlink message is limited
        to 64k bytes.
      
        Second, while RTM_NEWNEXTHOPBUCKET is only used for notifications at
        this point, in the future it can be extended to provide user space with
        control over nexthop buckets configuration.
      
      - The new group type is NEXTHOP_GRP_TYPE_RES. Note that nexthop code is
        adjusted to bounce groups with that type for now.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      710ec562
    • Petr Machata's avatar
      nexthop: Add a dedicated flag for multipath next-hop groups · 90e1a9e2
      Petr Machata authored
      With the introduction of resilient nexthop groups, there will be two types
      of multipath groups: the current hash-threshold "mpath" ones, and resilient
      groups. Both are multipath, but to determine the fact, the system needs to
      consider two flags. This might prove costly in the datapath. Therefore,
      introduce a new flag, that should be set for next-hop groups that have more
      than one nexthop, and should be considered multipath.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90e1a9e2
    • Petr Machata's avatar
      nexthop: __nh_notifier_single_info_init(): Make nh_info an argument · 96a85625
      Petr Machata authored
      The cited function currently uses rtnl_dereference() to get nh_info from a
      handed-in nexthop. However, under the resilient hashing scheme, this
      function will not always be called under RTNL, sometimes the mutual
      exclusion will be achieved differently. Therefore move the nh_info
      extraction from the function to its callers to make it possible to use a
      different synchronization guarantee.
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96a85625
    • Petr Machata's avatar
      nexthop: Pass nh_config to replace_nexthop() · 597f48e4
      Petr Machata authored
      Currently, replace assumes that the new group that is given is a
      fully-formed object. But mpath groups really only have one attribute, and
      that is the constituent next hop configuration. This may not be universally
      true. From the usability perspective, it is desirable to allow the replace
      operation to adjust just the constituent next hop configuration and leave
      the group attributes as such intact.
      
      But the object that keeps track of whether an attribute was or was not
      given is the nh_config object, not the next hop or next-hop group. To allow
      (selective) attribute updates during NH group replacement, propagate `cfg'
      to replace_nexthop() and further to replace_nexthop_grp().
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      597f48e4
    • David S. Miller's avatar
      Merge branch 'seg6-next' · 1d5d0a07
      David S. Miller authored
      Julien Massonneau says:
      
      ====================
      SRv6: SRH processing improvements
      
      Add support for IPv4 decapsulation in ipv6_srh_rcv() and
      ignore routing header with segments left equal to 0 for
      seg6local actions that doesn't perfom decapsulation.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d5d0a07
    • Julien Massonneau's avatar
      seg6: ignore routing header with segments left equal to 0 · fbbc5bc2
      Julien Massonneau authored
      When there are 2 segments routing header, after an End.B6 action
      for example, the second SRH will never be handled by an action, packet will
      be dropped when the first SRH has segments left equal to 0.
      For actions that doesn't perform decapsulation (currently: End, End.X,
      End.T, End.B6, End.B6.Encaps), this patch adds the IP6_FH_F_SKIP_RH flag
      in arguments for ipv6_find_hdr().
      Signed-off-by: default avatarJulien Massonneau <julien.massonneau@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbbc5bc2
    • Julien Massonneau's avatar
      seg6: add support for IPv4 decapsulation in ipv6_srh_rcv() · ee90c6ba
      Julien Massonneau authored
      As specified in IETF RFC 8754, section 4.3.1.2, if the upper layer
      header is IPv4 or IPv6, perform IPv6 decapsulation and resubmit the
      decapsulated packet to the IPv4 or IPv6 module.
      Only IPv6 decapsulation was implemented. This patch adds support for IPv4
      decapsulation.
      
      Link: https://tools.ietf.org/html/rfc8754#section-4.3.1.2Signed-off-by: default avatarJulien Massonneau <julien.massonneau@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee90c6ba
    • David S. Miller's avatar
      Merge branch 'hns3-next' · 6c609521
      David S. Miller authored
      Huazhong Tan says:
      
      ====================
      net: hns3: two updates for -next
      
      This series includes two updates for the HNS3 ethernet driver.
      ====================
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c609521
    • Yufeng Mo's avatar
      net: hns3: use pause capability queried from firmware · e8194f32
      Yufeng Mo authored
      For maintainability and compatibility, add support to use pause
      capability queried from firmware, and add debugfs support to dump
      this capability.
      Signed-off-by: default avatarYufeng Mo <moyufeng@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8194f32
    • Yufeng Mo's avatar
      net: hns3: use FEC capability queried from firmware · 433ccce8
      Yufeng Mo authored
      For maintainability and compatibility, add support to use FEC
      capability queried from firmware.
      Signed-off-by: default avatarYufeng Mo <moyufeng@huawei.com>
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      433ccce8
  2. 11 Mar, 2021 8 commits
    • Roi Dayan's avatar
      net/mlx5e: Alloc flow spec using kvzalloc instead of kzalloc · 9f4d9283
      Roi Dayan authored
      flow spec is not small and we do allocate it using kvzalloc
      in most places of the driver. fix rest of the places
      to use kvzalloc to avoid failure in allocation when
      memory is too fragmented.
      Signed-off-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      9f4d9283
    • Eli Cohen's avatar
      net/mlx5: Avoid unnecessary operation · 61e9508f
      Eli Cohen authored
      fs_get_obj retrieves the container of fs_parent_node just to pass the
      same value as &fs_ns->node. Just pass fs_parent_node to
      init_root_tree_recursive() to get exactly the same effect.
      Signed-off-by: default avatarEli Cohen <elic@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      61e9508f
    • Saeed Mahameed's avatar
      net/mlx5e: rep: Improve reg_cX conditions · 03e219c4
      Saeed Mahameed authored
      There is no point of calculating reg_c1 or overriding reg_c0 if we are
      going to abort the function.
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      03e219c4
    • Roi Dayan's avatar
      net/mlx5: SF, Fix return type · 3094552b
      Roi Dayan authored
      Fix the following coccicheck warnings:
      
      drivers/net/ethernet/mellanox/mlx5/core/sf/dev/dev.h:50:8-9: WARNING:
      return of 0/1 in function 'mlx5_sf_dev_allocated' with return type bool
      Signed-off-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      3094552b
    • Saeed Mahameed's avatar
      net/mlx5e: mlx5_tc_ct_init does not fail · 51ada5a5
      Saeed Mahameed authored
      mlx5_tc_ct_init() either returns a valid pointer or a NULL, either way
      the caller can continue, remove IS_ERR check from callers as it has no
      effect.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      51ada5a5
    • Vlad Buslov's avatar
      net/mlx5: Fix indir stable stubs · fbeab6be
      Vlad Buslov authored
      Some of the stubs for CONFIG_MLX5_CLS_ACT==disabled are missing "static
      inline" in their definition which causes the following compilation
      warnings:
      
         In file included from drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c:41:
      >> drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.h:34:1: warning: no previous prototype for function 'mlx5_esw_indir_table_init' [-Wmissing-prototypes]
         mlx5_esw_indir_table_init(void)
         ^
         drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.h:33:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
         struct mlx5_esw_indir_table *
         ^
         static
      >> drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.h:40:1: warning: no previous prototype for function 'mlx5_esw_indir_table_destroy' [-Wmissing-prototypes]
         mlx5_esw_indir_table_destroy(struct mlx5_esw_indir_table *indir)
         ^
         drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.h:39:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
         void
         ^
         static
      >> drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.h:61:1: warning: no previous prototype for function 'mlx5_esw_indir_table_needed' [-Wmissing-prototypes]
         mlx5_esw_indir_table_needed(struct mlx5_eswitch *esw,
         ^
         drivers/net/ethernet/mellanox/mlx5/core/esw/indir_table.h:60:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
         bool
         ^
         static
         3 warnings generated.
      
      Add "static inline" prefix to signatures of stubs that were missing it.
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      fbeab6be
    • Vlad Buslov's avatar
      net/mlx5e: Add missing include · 5632817b
      Vlad Buslov authored
      When CONFIG_IPV6 is disabled the header nexthop.h is not included by
      fib_notifier.h which causes tc_tun_encap.c to fail to compile:
      
         In file included from drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:5:
         In file included from drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.h:7:
         In file included from drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h:7:
         In file included from drivers/net/ethernet/mellanox/mlx5/core/en_tc.h:40:
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.h:78:5: warning: no previous prototype for function 'mlx5e_tc_tun_update_header_ipv6' [-Wmissing-prototypes]
         int mlx5e_tc_tun_update_header_ipv6(struct mlx5e_priv *priv,
             ^
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.h:78:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
         int mlx5e_tc_tun_update_header_ipv6(struct mlx5e_priv *priv,
         ^
         static
      >> drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1510:12: error: implicit declaration of function 'fib_info_nh' [-Werror,-Wimplicit-function-declaration]
                 fib_dev = fib_info_nh(fen_info->fi, 0)->fib_nh_dev;
                           ^
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1510:12: note: did you mean 'fib_info_put'?
         include/net/ip_fib.h:528:20: note: 'fib_info_put' declared here
         static inline void fib_info_put(struct fib_info *fi)
                            ^
      >> drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1510:42: error: member reference type 'int' is not a pointer
                 fib_dev = fib_info_nh(fen_info->fi, 0)->fib_nh_dev;
                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ^
         include/net/ip_fib.h:113:21: note: expanded from macro 'fib_nh_dev'
         #define fib_nh_dev              nh_common.nhc_dev
                                         ^
      >> drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1552:13: error: incomplete definition of type 'struct fib6_entry_notifier_info'
                 fen_info = container_of(info, struct fib6_entry_notifier_info, info);
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         include/linux/kernel.h:694:51: note: expanded from macro 'container_of'
                 BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) &&   \
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
         include/linux/compiler_types.h:256:74: note: expanded from macro '__same_type'
         #define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
                                                                                  ^
         include/linux/build_bug.h:39:58: note: expanded from macro 'BUILD_BUG_ON_MSG'
         #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                             ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
         include/linux/compiler_types.h:320:22: note: expanded from macro 'compiletime_assert'
                 _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
                 ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         include/linux/compiler_types.h:308:23: note: expanded from macro '_compiletime_assert'
                 __compiletime_assert(condition, msg, prefix, suffix)
                 ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         include/linux/compiler_types.h:300:9: note: expanded from macro '__compiletime_assert'
                         if (!(condition))                                       \
                               ^~~~~~~~~
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1546:9: note: forward declaration of 'struct fib6_entry_notifier_info'
                 struct fib6_entry_notifier_info *fen_info;
                        ^
      >> drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1552:13: error: offsetof of incomplete type 'struct fib6_entry_notifier_info'
                 fen_info = container_of(info, struct fib6_entry_notifier_info, info);
                            ^                  ~~~~~~
         include/linux/kernel.h:697:21: note: expanded from macro 'container_of'
                 ((type *)(__mptr - offsetof(type, member))); })
                                    ^        ~~~~
         include/linux/stddef.h:17:32: note: expanded from macro 'offsetof'
         #define offsetof(TYPE, MEMBER)  __compiler_offsetof(TYPE, MEMBER)
                                         ^                   ~~~~
         include/linux/compiler_types.h:140:35: note: expanded from macro '__compiler_offsetof'
         #define __compiler_offsetof(a, b)       __builtin_offsetof(a, b)
                                                 ^                  ~
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1546:9: note: forward declaration of 'struct fib6_entry_notifier_info'
                 struct fib6_entry_notifier_info *fen_info;
                        ^
      >> drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1552:11: error: assigning to 'struct fib6_entry_notifier_info *' from incompatible type 'void'
                 fen_info = container_of(info, struct fib6_entry_notifier_info, info);
                          ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      >> drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1553:12: error: implicit declaration of function 'fib6_info_nh_dev' [-Werror,-Wimplicit-function-declaration]
                 fib_dev = fib6_info_nh_dev(fen_info->rt);
                           ^
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1553:37: error: incomplete definition of type 'struct fib6_entry_notifier_info'
                 fib_dev = fib6_info_nh_dev(fen_info->rt);
                                            ~~~~~~~~^
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1546:9: note: forward declaration of 'struct fib6_entry_notifier_info'
                 struct fib6_entry_notifier_info *fen_info;
                        ^
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1555:14: error: incomplete definition of type 'struct fib6_entry_notifier_info'
                     fen_info->rt->fib6_dst.plen != 128)
                     ~~~~~~~~^
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1546:9: note: forward declaration of 'struct fib6_entry_notifier_info'
                 struct fib6_entry_notifier_info *fen_info;
                        ^
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1562:39: error: incomplete definition of type 'struct fib6_entry_notifier_info'
                 memcpy(&key.endpoint_ip.v6, &fen_info->rt->fib6_dst.addr,
                                              ~~~~~~~~^
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1546:9: note: forward declaration of 'struct fib6_entry_notifier_info'
                 struct fib6_entry_notifier_info *fen_info;
                        ^
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1563:24: error: incomplete definition of type 'struct fib6_entry_notifier_info'
                        sizeof(fen_info->rt->fib6_dst.addr));
                               ~~~~~~~~^
         drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c:1546:9: note: forward declaration of 'struct fib6_entry_notifier_info'
                 struct fib6_entry_notifier_info *fen_info;
                        ^
         1 warning and 10 errors generated.
      
      Manually include net/nexthop.h in tc_tun_encap.c.
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Signed-off-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      5632817b
    • Arnd Bergmann's avatar
      net/mlx5e: fix mlx5e_tc_tun_update_header_ipv6 dummy definition · 87f77a67
      Arnd Bergmann authored
      The alternative implementation of this function in a header file
      is declared as a global symbol, and gets added to every .c file
      that includes it, which leads to a link error:
      
      arm-linux-gnueabi-ld: drivers/net/ethernet/mellanox/mlx5/core/en_rx.o: in function `mlx5e_tc_tun_update_header_ipv6':
      en_rx.c:(.text+0x0): multiple definition of `mlx5e_tc_tun_update_header_ipv6'; drivers/net/ethernet/mellanox/mlx5/core/en_main.o:en_main.c:(.text+0x0): first defined here
      
      Mark it 'static inline' like the other functions here.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      87f77a67