1. 09 Sep, 2020 29 commits
  2. 08 Sep, 2020 8 commits
    • David Howells's avatar
      rxrpc: Allow multiple client connections to the same peer · 288827d5
      David Howells authored
      Allow the number of parallel connections to a machine to be expanded from a
      single connection to a maximum of four.  This allows up to 16 calls to be
      in progress at the same time to any particular peer instead of 4.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      288827d5
    • David Howells's avatar
      rxrpc: Rewrite the client connection manager · 245500d8
      David Howells authored
      Rewrite the rxrpc client connection manager so that it can support multiple
      connections for a given security key to a peer.  The following changes are
      made:
      
       (1) For each open socket, the code currently maintains an rbtree with the
           connections placed into it, keyed by communications parameters.  This
           is tricky to maintain as connections can be culled from the tree or
           replaced within it.  Connections can require replacement for a number
           of reasons, e.g. their IDs span too great a range for the IDR data
           type to represent efficiently, the call ID numbers on that conn would
           overflow or the conn got aborted.
      
           This is changed so that there's now a connection bundle object placed
           in the tree, keyed on the same parameters.  The bundle, however, does
           not need to be replaced.
      
       (2) An rxrpc_bundle object can now manage the available channels for a set
           of parallel connections.  The lock that manages this is moved there
           from the rxrpc_connection struct (channel_lock).
      
       (3) There'a a dummy bundle for all incoming connections to share so that
           they have a channel_lock too.  It might be better to give each
           incoming connection its own bundle.  This bundle is not needed to
           manage which channels incoming calls are made on because that's the
           solely at whim of the client.
      
       (4) The restrictions on how many client connections are around are
           removed.  Instead, a previous patch limits the number of client calls
           that can be allocated.  Ordinarily, client connections are reaped
           after 2 minutes on the idle queue, but when more than a certain number
           of connections are in existence, the reaper starts reaping them after
           2s of idleness instead to get the numbers back down.
      
           It could also be made such that new call allocations are forced to
           wait until the number of outstanding connections subsides.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      245500d8
    • David Howells's avatar
      rxrpc: Impose a maximum number of client calls · b7a7d674
      David Howells authored
      Impose a maximum on the number of client rxrpc calls that are allowed
      simultaneously.  This will be in lieu of a maximum number of client
      connections as this is easier to administed as, unlike connections, calls
      aren't reusable (to be changed in a subsequent patch)..
      
      This doesn't affect the limits on service calls and connections.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      b7a7d674
    • Jose M. Guisado Gomez's avatar
      netfilter: nf_tables: add userdata support for nft_object · b131c964
      Jose M. Guisado Gomez authored
      Enables storing userdata for nft_object. Initially this will store an
      optional comment but can be extended in the future as needed.
      
      Adds new attribute NFTA_OBJ_USERDATA to nft_object.
      Signed-off-by: default avatarJose M. Guisado Gomez <guigom@riseup.net>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      b131c964
    • Fabian Frederick's avatar
      selftests/net: replace obsolete NFT_CHAIN configuration · 0c5edd77
      Fabian Frederick authored
      Replace old parameters with global NFT_NAT from commit db8ab388
      ("netfilter: nf_tables: merge ipv4 and ipv6 nat chain types")
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      0c5edd77
    • Wang Hai's avatar
      netfilter: ebt_stp: Remove unused macro BPDU_TYPE_TCN · 36c3be8a
      Wang Hai authored
      BPDU_TYPE_TCN is never used after it was introduced.
      So better to remove it.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarWang Hai <wanghai38@huawei.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      36c3be8a
    • Vladimir Oltean's avatar
      net: dsa: don't print non-fatal MTU error if not supported · 4349abdb
      Vladimir Oltean authored
      Commit 72579e14 ("net: dsa: don't fail to probe if we couldn't set
      the MTU") changed, for some reason, the "err && err != -EOPNOTSUPP"
      check into a simple "err". This causes the MTU warning to be printed
      even for drivers that don't have the MTU operations implemented.
      Fix that.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4349abdb
    • Vladimir Oltean's avatar
      net: dsa: change PHY error message again · c9ebf126
      Vladimir Oltean authored
      slave_dev->name is only populated at this stage if it was specified
      through a label in the device tree. However that is not mandatory.
      When it isn't, the error message looks like this:
      
      [    5.037057] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d
      [    5.044672] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d
      [    5.052275] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d
      [    5.059877] fsl_enetc 0000:00:00.2 eth2: error -19 setting up slave PHY for eth%d
      
      which is especially confusing since the error gets printed on behalf of
      the DSA master (fsl_enetc in this case).
      
      Printing an error message that contains a valid reference to the DSA
      port's name is difficult at this point in the initialization stage, so
      at least we should print some info that is more reliable, even if less
      user-friendly. That may be the driver name and the hardware port index.
      
      After this change, the error is printed as:
      
      [    6.051587] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 0
      [    6.061192] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 1
      [    6.070765] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 2
      [    6.080324] mscc_felix 0000:00:00.5: error -19 setting up PHY for tree 0, switch 0, port 3
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c9ebf126
  3. 07 Sep, 2020 3 commits
    • Jakub Kicinski's avatar
      net: tighten the definition of interface statistics · 0db0c34c
      Jakub Kicinski authored
      This patch is born out of an investigation into which IEEE statistics
      correspond to which struct rtnl_link_stats64 members. Turns out that
      there seems to be reasonable consensus on the matter, among many drivers.
      To save others the time (and it took more time than I'm comfortable
      admitting) I'm adding comments referring to IEEE attributes to
      struct rtnl_link_stats64.
      
      Up until now we had two forms of documentation for stats - in
      Documentation/ABI/testing/sysfs-class-net-statistics and the comments
      on struct rtnl_link_stats64 itself. While the former is very cautious
      in defining the expected behavior, the latter feel quite dated and
      may not be easy to understand for modern day driver author
      (e.g. rx_over_errors). At the same time modern systems are far more
      complex and once obvious definitions lost their clarity. For example
      - does rx_packet count at the MAC layer (aFramesReceivedOK)?
      packets processed correctly by hardware? received by the driver?
      or maybe received by the stack?
      
      I tried to clarify the expectations, further clarifications from
      others are very welcome.
      
      The part hardest to untangle is rx_over_errors vs rx_fifo_errors
      vs rx_missed_errors. After much deliberation I concluded that for
      modern HW only two of the counters will make sense. The distinction
      between internal FIFO overflow and packets dropped due to back-pressure
      from the host is likely too implementation (driver and device) specific
      to expose in the standard stats.
      
      Now - which two of those counters we select to use is anyone's pick:
      
      sysfs documentation suggests rx_over_errors counts packets which
      did not fit into buffers due to MTU being too small, which I reused.
      There don't seem to be many modern drivers using it (well, CAN drivers
      seem to love this statistic).
      
      Of the remaining two I picked rx_missed_errors to report device drops.
      bnxt reports it and it's folded into "drop"s in procfs (while
      rx_fifo_errors is an error, and modern devices usually receive the frame
      OK, they just can't admit it into the pipeline).
      
      Of the drivers I looked at only AMD Lance-like and NS8390-like use all
      three of these counters. rx_missed_errors counts missed frames,
      rx_over_errors counts overflow events, and rx_fifo_errors counts frames
      which were truncated because they didn't fit into buffers. This suggests
      that rx_fifo_errors may be the correct stat for truncated packets, but
      I'd think a FIFO stat counting truncated packets would be very confusing
      to a modern reader.
      
      v2:
       - add driver developer notes about ethtool stat count and reset
       - replace Ethernet with IEEE 802.3 to better indicate source of attrs
       - mention byte counters don't count FCS
       - clarify RX counter is from device to host
       - drop "sightly" from sysfs paragraph
       - add examples of ethtool stats
       - s/incoming/received/ s/incoming/transmitted/
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0db0c34c
    • Wang Hai's avatar
      rxrpc: Remove unused macro rxrpc_min_rtt_wlen · 81365af1
      Wang Hai authored
      rxrpc_min_rtt_wlen is never used after it was introduced.
      So better to remove it.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: default avatarWang Hai <wanghai38@huawei.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      81365af1
    • Jakub Kicinski's avatar
      Merge branch 'sfc-ethtool-for-EF100-and-related-improvements' · 14e9e262
      Jakub Kicinski authored
      Edward Cree says:
      
      ====================
      sfc: ethtool for EF100 and related improvements
      
      This series adds the ethtool support to the EF100 driver that was held
       back from the original submission as the lack of phy_ops caused issues.
      Patch #2, removing the phy_op indirection, deals with this.  There are a
       lot of checkpatch warnings / xmastree violations but they're all in
       pure code movement so I've left the code as it is.
      While patch #1 is technically a fix and possibly could go to 'net', I've
       put it in this series since it only becomes triggerable with the added
       'ethtool --reset' support.
      ====================
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      14e9e262