1. 28 7月, 2018 12 次提交
    • A
      net/rds/Kconfig: Correct the RDS depends · 3e4e3643
      Anders Roxell 提交于
      Remove prefix 'CONFIG_' from CONFIG_IPV6
      
      Fixes: ba7d7e26 ("net/rds/Kconfig: RDS should depend on IPV6")
      Reported-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NAnders Roxell <anders.roxell@linaro.org>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e4e3643
    • D
      Merge branch 'mlxsw-Support-DSCP-prioritization-and-rewrite' · 2e279c93
      David S. Miller 提交于
      Ido Schimmel says:
      
      ====================
      mlxsw: Support DSCP prioritization and rewrite
      
      Petr says:
      
      On ingress, a network device such as a switch assigns to packets
      priority based on various criteria. Common options include interpreting
      PCP and DSCP fields according to user configuration. When a packet
      egresses the switch, a reverse process may rewrite PCP and/or DSCP
      headers according to packet priority.
      
      So far, mlxsw has supported prioritization based on PCP (802.1p priority
      tag). This patch set introduces support for prioritization based on
      DSCP, and DSCP rewrite.
      
      To configure the DSCP-to-priority maps, the user is expected to invoke
      ieee_setapp and ieee_delapp DCBNL ops, e.g. by using lldptool:
      
      To decide whether or not to pay attention to DSCP values, the Spectrum
      switch recognize a per-port configuration of trust level. Until the
      first APP rule is added for a given port, this port's trust level stays
      at PCP, meaning that PCP is used for packet prioritization. With the
      first DSCP APP rule, the port is configured to trust DSCP instead, and
      it stays there until all DSCP APP rules are removed again.
      
      Besides the DSCP (value 5) selector, another selector that plays into
      packet prioritization is Ethernet type (value 1) with PID of 0. Such APP
      entries denote default priority[1]:
      
      With this patch set, mlxsw uses these values to configure priority for
      DSCP values not explicitly specified in DSCP APP map. In the future we
      expect to also use this to configure default port priority for untagged
      packets.
      
      Access to DSCP-to-priority map, priority-to-DSCP map, and default
      priority for a port is exposed through three new DCB helpers. Like the
      already-existing dcb_ieee_getapp_mask() helper, these helpers operate in
      terms of bitmaps, to support the arbitrary M:N mapping that the APP
      rules allow. Such interface presents all the relevant information from
      the APP database without necessitating exposition of iterators, locking
      or other complex primitives. It is up to the driver to then digest the
      mapping in a way that the device supports. In this patch set, mlxsw
      resolves conflicts by favoring higher-numbered DSCP values and
      priorities.
      
      In this patchset:
      
      - Patch #1 fixes a bug in DCB APP database management.
      - Patch #2 adds the getters described above.
      - Patches #3-#6 add Spectrum configuration registers.
      - Patch #7 adds the mlxsw logic that configures the device according to
        APP rules.
      - Patch #8 adds a self-test. The test is added to the subdirectory
        drivers/net/mlxsw. Even though it's not particularly specific to
        mlxsw, it's not suitable for running on soft devices (which don't
        support the ieee_getapp et.al.), and thus isn't a good fit for the
        general net/forwarding directory.
      
      [1] 802.1Q-2014, Table D-9
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e279c93
    • P
      selftests: mlxsw: Add test for trust-DSCP · d159261f
      Petr Machata 提交于
      Add a test that exercises the new code. Send DSCP-tagged packets, and
      observe how they are prioritized in the switch and the DSCP is updated
      on egress again.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d159261f
    • P
      mlxsw: spectrum: Support ieee_setapp, ieee_delapp · b2b1dab6
      Petr Machata 提交于
      The APP TLVs are used for communicating priority-to-protocol ID maps for
      a given netdevice. Support the following APP TLVs:
      
      - DSCP (selector 5) to configure priority-to-DSCP code point maps. Use
        these maps to configure packet priority on ingress, and DSCP code
        point rewrite on egress.
      
      - Default priority (selector 1, PID 0) to configure priority for the
        DSCP code points that don't have one assigned by the DSCP selector. In
        future this could also be used for assigning default port priority
        when a packet arrives without DSCP tagging.
      
      Besides setting up the maps themselves, also configure port trust level
      and rewrite bits.
      
      Port trust level determines whether, for a packet arriving through a
      certain port, the priority should be determined based on PCP or DSCP
      header fields. So far, mlxsw kept the device default of trust-PCP. Now,
      as soon as the first DSCP APP TLV is configured, switch to trust-DSCP.
      Only when all DSCP APP TLVs are removed, switch back to trust-PCP again.
      Note that the default priority APP TLV doesn't impact the trust level
      configuration.
      
      Rewrite bits determine whether DSCP and PCP fields of egressing packets
      should be updated according to switch priority. When port trust is
      switched to DSCP, enable rewrite of DSCP field.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b2b1dab6
    • P
      mlxsw: reg: Add QoS Priority to DSCP Mapping Register · 55fb71f4
      Petr Machata 提交于
      This register controls mapping from Priority to DSCP for purposes of
      rewrite. Note that rewrite happens as the packet is transmitted provided
      that the DSCP rewrite bit is enabled for the packet.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      55fb71f4
    • P
      mlxsw: reg: Add QoS ReWrite Enable Register · e67131d9
      Petr Machata 提交于
      This register configures the rewrite enable (whether PCP or DSCP value
      in packet should be updated according to packet priority) per receive
      port.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e67131d9
    • P
      mlxsw: reg: Add QoS Priority Trust State Register · 746da42a
      Petr Machata 提交于
      The QPTS register controls the port policy to calculate the switch
      priority and packet color based on incoming packet fields.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      746da42a
    • P
      mlxsw: reg: Add QoS Port DSCP to Priority Mapping Register · 02837d72
      Petr Machata 提交于
      The QPDPM register controls the mapping from DSCP field to Switch
      Priority for IP packets.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      02837d72
    • P
      net: dcb: Add priority-to-DSCP map getters · b67c540b
      Petr Machata 提交于
      On ingress, a network device such as a switch assigns to packets
      priority based on various criteria. Common options include interpreting
      PCP and DSCP fields according to user configuration. When a packet
      egresses the switch, a reverse process may rewrite PCP and/or DSCP
      values according to packet priority.
      
      The following three functions support a) obtaining a DSCP-to-priority
      map or vice versa, and b) finding default-priority entries in APP
      database.
      
      The DCB subsystem supports for APP entries a very generous M:N mapping
      between priorities and protocol identifiers. Understandably,
      several (say) DSCP values can map to the same priority. But this
      asymmetry holds the other way around as well--one priority can map to
      several DSCP values. For this reason, the following functions operate in
      terms of bitmaps, with ones in positions that match some APP entry.
      
      - dcb_ieee_getapp_dscp_prio_mask_map() to compute for a given netdevice
        a map of DSCP-to-priority-mask, which gives for each DSCP value a
        bitmap of priorities related to that DSCP value by APP, along the
        lines of dcb_ieee_getapp_mask().
      
      - dcb_ieee_getapp_prio_dscp_mask_map() similarly to compute for a given
        netdevice a map from priorities to a bitmap of DSCPs.
      
      - dcb_ieee_getapp_default_prio_mask() which finds all default-priority
        rules for a given port in APP database, and returns a mask of
        priorities allowed by these default-priority rules.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b67c540b
    • P
      net: dcb: For wild-card lookups, use priority -1, not 0 · 08193d1a
      Petr Machata 提交于
      The function dcb_app_lookup walks the list of specified DCB APP entries,
      looking for one that matches a given criteria: ifindex, selector,
      protocol ID and optionally also priority. The "don't care" value for
      priority is set to 0, because that priority has not been allowed under
      CEE regime, which predates the IEEE standardization.
      
      Under IEEE, 0 is a valid priority number. But because dcb_app_lookup
      considers zero a wild card, attempts to add an APP entry with priority 0
      fail when other entries exist for a given ifindex / selector / PID
      triplet.
      
      Fix by changing the wild-card value to -1.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08193d1a
    • J
      net: sched: don't dump chains only held by actions · 1f3ed383
      Jiri Pirko 提交于
      In case a chain is empty and not explicitly created by a user,
      such chain should not exist. The only exception is if there is
      an action "goto chain" pointing to it. In that case, don't show the
      chain in the dump. Track the chain references held by actions and
      use them to find out if a chain should or should not be shown
      in chain dump.
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f3ed383
    • D
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next · 7a49d3d4
      David S. Miller 提交于
      Steffen Klassert says:
      
      ====================
      pull request (net-next): ipsec-next 2018-07-27
      
      1) Extend the output_mark to also support the input direction
         and masking the mark values before applying to the skb.
      
      2) Add a new lookup key for the upcomming xfrm interfaces.
      
      3) Extend the xfrm lookups to match xfrm interface IDs.
      
      4) Add virtual xfrm interfaces. The purpose of these interfaces
         is to overcome the design limitations that the existing
         VTI devices have.
      
        The main limitations that we see with the current VTI are the
        following:
      
        VTI interfaces are L3 tunnels with configurable endpoints.
        For xfrm, the tunnel endpoint are already determined by the SA.
        So the VTI tunnel endpoints must be either the same as on the
        SA or wildcards. In case VTI tunnel endpoints are same as on
        the SA, we get a one to one correlation between the SA and
        the tunnel. So each SA needs its own tunnel interface.
      
        On the other hand, we can have only one VTI tunnel with
        wildcard src/dst tunnel endpoints in the system because the
        lookup is based on the tunnel endpoints. The existing tunnel
        lookup won't work with multiple tunnels with wildcard
        tunnel endpoints. Some usecases require more than on
        VTI tunnel of this type, for example if somebody has multiple
        namespaces and every namespace requires such a VTI.
      
        VTI needs separate interfaces for IPv4 and IPv6 tunnels.
        So when routing to a VTI, we have to know to which address
        family this traffic class is going to be encapsulated.
        This is a lmitation because it makes routing more complex
        and it is not always possible to know what happens behind the
        VTI, e.g. when the VTI is move to some namespace.
      
        VTI works just with tunnel mode SAs. We need generic interfaces
        that ensures transfomation, regardless of the xfrm mode and
        the encapsulated address family.
      
        VTI is configured with a combination GRE keys and xfrm marks.
        With this we have to deal with some extra cases in the generic
        tunnel lookup because the GRE keys on the VTI are actually
        not GRE keys, the GRE keys were just reused for something else.
        All extensions to the VTI interfaces would require to add
        even more complexity to the generic tunnel lookup.
      
        So to overcome this, we developed xfrm interfaces with the
        following design goal:
      
        It should be possible to tunnel IPv4 and IPv6 through the same
        interface.
      
        No limitation on xfrm mode (tunnel, transport and beet).
      
        Should be a generic virtual interface that ensures IPsec
        transformation, no need to know what happens behind the
        interface.
      
        Interfaces should be configured with a new key that must match a
        new policy/SA lookup key.
      
        The lookup logic should stay in the xfrm codebase, no need to
        change or extend generic routing and tunnel lookups.
      
        Should be possible to use IPsec hardware offloads of the underlying
        interface.
      
      5) Remove xfrm pcpu policy cache. This was added after the flowcache
         removal, but it turned out to make things even worse.
         From Florian Westphal.
      
      6) Allow to update the set mark on SA updates.
         From Nathan Harold.
      
      7) Convert some timestamps to time64_t.
         From Arnd Bergmann.
      
      8) Don't check the offload_handle in xfrm code,
         it is an opaque data cookie for the driver.
         From Shannon Nelson.
      
      9) Remove xfrmi interface ID from flowi. After this pach
         no generic code is touched anymore to do xfrm interface
         lookups. From Benedict Wong.
      
      10) Allow to update the xfrm interface ID on SA updates.
          From Nathan Harold.
      
      11) Don't pass zero to ERR_PTR() in xfrm_resolve_and_create_bundle.
          From YueHaibing.
      
      12) Return more detailed errors on xfrm interface creation.
          From Benedict Wong.
      
      13) Use PTR_ERR_OR_ZERO instead of IS_ERR + PTR_ERR.
          From the kbuild test robot.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7a49d3d4
  2. 27 7月, 2018 28 次提交