1. 09 Feb, 2022 34 commits
  2. 08 Feb, 2022 6 commits
    • Joe Damato's avatar
      i40e: Add a stat for tracking busy rx pages · b76bc129
      Joe Damato authored
      In some cases, pages cannot be reused by i40e because the page is busy. Add
      a counter for this event.
      
      Busy page count is accessible via ethtool.
      Signed-off-by: default avatarJoe Damato <jdamato@fastly.com>
      Tested-by: default avatarDave Switzer <david.switzer@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      b76bc129
    • Joe Damato's avatar
      i40e: Add a stat for tracking pages waived · cb963b98
      Joe Damato authored
      In some cases, pages can not be reused because they are not associated with
      the correct NUMA zone. Knowing how often pages are waived helps users to
      understand the interaction between the driver's memory usage and their
      system.
      
      Pass rx_stats through to i40e_can_reuse_rx_page to allow tracking when
      pages are waived.
      
      The page waive count is accessible via ethtool.
      Signed-off-by: default avatarJoe Damato <jdamato@fastly.com>
      Tested-by: default avatarDave Switzer <david.switzer@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      cb963b98
    • Joe Damato's avatar
      i40e: Add a stat tracking new RX page allocations · 453f8305
      Joe Damato authored
      Add a counter for new page allocations in the i40e RX path. This stat is
      accessible with ethtool.
      Signed-off-by: default avatarJoe Damato <jdamato@fastly.com>
      Tested-by: default avatarDave Switzer <david.switzer@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      453f8305
    • Joe Damato's avatar
      i40e: Aggregate and export RX page reuse stat · b3936d27
      Joe Damato authored
      rx page reuse was already being tracked by the i40e driver per RX ring.
      Aggregate the counts and make them accessible via ethtool.
      Signed-off-by: default avatarJoe Damato <jdamato@fastly.com>
      Tested-by: default avatarDave Switzer <david.switzer@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      b3936d27
    • Joe Damato's avatar
      i40e: Remove rx page reuse double count · 89bb0983
      Joe Damato authored
      Page reuse was being tracked from two locations:
        - i40e_reuse_rx_page (via 40e_clean_rx_irq), and
        - i40e_alloc_mapped_page
      
      Remove the double count and only count reuse from i40e_alloc_mapped_page
      when the page is about to be reused.
      Signed-off-by: default avatarJoe Damato <jdamato@fastly.com>
      Tested-by: default avatarDave Switzer <david.switzer@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      89bb0983
    • Jakub Kicinski's avatar
      Merge branch 'inet-separate-dscp-from-ecn-bits-using-new-dscp_t-type' · c3e676b9
      Jakub Kicinski authored
      Guillaume Nault says:
      
      ====================
      inet: Separate DSCP from ECN bits using new dscp_t type
      
      The networking stack currently doesn't clearly distinguish between DSCP
      and ECN bits. The entire DSCP+ECN bits are stored in u8 variables (or
      structure fields), and each part of the stack handles them in their own
      way, using different macros. This has created several bugs in the past
      and some uncommon code paths are still unfixed.
      
      Such bugs generally manifest by selecting invalid routes because of ECN
      bits interfering with FIB routes and rules lookups (more details in the
      LPC 2021 talk[1] and in the RFC of this series[2]).
      
      This patch series aims at preventing the introduction of such bugs (and
      detecting existing ones), by introducing a dscp_t type, representing
      "sanitised" DSCP values (that is, with no ECN information), as opposed
      to plain u8 values that contain both DSCP and ECN information. dscp_t
      makes it clear for the reader what we're working on, and Sparse can
      flag invalid interactions between dscp_t and plain u8.
      
      This series converts only a few variables and structures:
      
        * Patch 1 converts the tclass field of struct fib6_rule. It
          effectively forbids the use of ECN bits in the tos/dsfield option
          of ip -6 rule. Rules now match packets solely based on their DSCP
          bits, so ECN doesn't influence the result any more. This contrasts
          with the previous behaviour where all 8 bits of the Traffic Class
          field were used. It is believed that this change is acceptable as
          matching ECN bits wasn't usable for IPv4, so only IPv6-only
          deployments could be depending on it. Also the previous behaviour
          made DSCP-based ip6-rules fail for packets with both a DSCP and an
          ECN mark, which is another reason why any such deploy is unlikely.
      
        * Patch 2 converts the tos field of struct fib4_rule. This one too
          effectively forbids defining ECN bits, this time in ip -4 rule.
          Before that, setting ECN bit 1 was accepted, while ECN bit 0 was
          rejected. But even when accepted, the rule would never match, as
          the packets would have their ECN bits cleared before doing the
          rule lookup.
      
        * Patch 3 converts the fc_tos field of struct fib_config. This is
          equivalent to patch 2, but for IPv4 routes. Routes using a
          tos/dsfield option with any ECN bit set is now rejected. Before
          this patch, they were accepted but, as with ip4 rules, these routes
          couldn't match any packet, since their ECN bits are cleared before
          the lookup.
      
        * Patch 4 converts the fa_tos field of struct fib_alias. This one is
          pure internal u8 to dscp_t conversion. While patches 1-3 had user
          facing consequences, this patch shouldn't have any side effect and
          is there to give an overview of what future conversion patches will
          look like. Conversions are quite mechanical, but imply some code
          churn, which is the price for the extra clarity a possibility of
          type checking.
      
      To summarise, all the behaviour changes required for the dscp_t type
      approach to work should be contained in patches 1-3. These changes are
      edge cases of ip-route and ip-rule that don't currently work properly.
      So they should be safe. Also, a kernel selftest is added for each of
      them.
      
      Finally, this work also paves the way for allowing the usage of the 3
      high order DSCP bits in IPv4 (a few call paths already handle them, but
      in general the stack clears them before IPv4 rule and route lookups).
      
      References:
        [1] LPC 2021 talk:
              - https://linuxplumbersconf.org/event/11/contributions/943/
              - Direct link to slide deck:
                  https://linuxplumbersconf.org/event/11/contributions/943/attachments/901/1780/inet_tos_lpc2021.pdf
        [2] RFC version of this series:
            - https://lore.kernel.org/netdev/cover.1638814614.git.gnault@redhat.com/
      ====================
      
      Link: https://lore.kernel.org/r/cover.1643981839.git.gnault@redhat.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c3e676b9