Skip to content

L
linux
Switch branch/tag
  1. 09 Sep, 2020 20 commits
  3. 08 Sep, 2020 5 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
    • 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
  5. 07 Sep, 2020 15 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
    • Edward Cree's avatar
      sfc: simplify DMA mask setting · 08bdbcae
      Edward Cree authored 
      Christoph says[1] that dma_set_mask_and_coherent() is smart enough to
 truncate the mask itself if it's too long.  So we can get rid of our
 "lop off one bit and retry" loop in efx_init_io().

[1]: https://www.spinics.net/lists/netdev/msg677266.htmlSigned-off-by: default avatarEdward Cree <ecree@solarflare.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      08bdbcae
    • Edward Cree's avatar
      sfc: remove EFX_DRIVER_VERSION · 60bd2a2d
      Edward Cree authored 
      Per-module versions for in-tree drivers are deprecated.
Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      60bd2a2d
    • Edward Cree's avatar
      sfc: handle limited FEC support · 400d64cf
      Edward Cree authored 
      If the reported PHY capabilities do not include a given FEC mode, don't
 attempt to select that FEC mode anyway.  If the user tries to set a mode
 through ethtool that is not supported, return an error.
The _REQUESTED bits don't appear in the supported caps, but are implied
 by the corresponding FEC bits.
Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      400d64cf
    • Edward Cree's avatar
      sfc: add ethtool ops and miscellaneous ndos to EF100 · 4404c089
      Edward Cree authored 
      Mostly just calls to existing common functions.
Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      4404c089
    • Edward Cree's avatar
      sfc: remove phy_op indirection · c77289b4
      Edward Cree authored 
      Originally there were several implementations of PHY operations for the
 several different PHYs used on Falcon boards.  But Falcon is now in a
 separate driver, and all sfc NICs since then have had MCDI-managed PHYs.
Thus, there is no need to indirect through function pointers in
 efx->phy_op; we can simply call the efx_mcdi_phy_* functions directly.

This also hooks up these functions for EF100, which was previously using
 the dummy_phy_ops.
Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      c77289b4
    • Edward Cree's avatar
      sfc: don't double-down() filters in ef100_reset() · 7dcc9d8a
      Edward Cree authored 
      dev_close(), by way of ef100_net_stop(), already brings down the filter
 table, so there's no need to do it again (which just causes lots of
 WARN_ONs).
Similarly, don't bring it up ourselves, as dev_open() -> ef100_net_open()
 will do it, and will fail if it's already been brought up.

Fixes: a9dc3d56 ("sfc_ef100: RX filter table management and related gubbins")
Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7dcc9d8a
    • Wang Hai's avatar
      net: ethernet: dnet: Remove set but unused variable 'len' · 30ebaf8e
      Wang Hai authored 
      Fixes gcc '-Wunused-but-set-variable' warning:

drivers/net/ethernet/dnet.c: In function dnet_start_xmit
drivers/net/ethernet/dnet.c:511:15: warning: variable ‘len’ set but not used [-Wunused-but-set-variable]

commit 47964174 ("dnet: Dave DNET ethernet controller driver (updated)")
involved this unused variable, 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>
      30ebaf8e
    • Zhang Changzhong's avatar
      net: ethernet: dwmac: remove redundant null check before clk_disable_unprepare() · f3b11449
      Zhang Changzhong authored 
      Because clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter, so the additional checks are unnecessary, just
remove them.
Reported-by: default avatarHulk Robot <hulkci@huawei.com>
Signed-off-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f3b11449
    • Zhang Changzhong's avatar
      net: ethernet: fec: remove redundant null check before clk_disable_unprepare() · 05891200
      Zhang Changzhong authored 
      Because clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter, so the additional checks are unnecessary, just
remove them.
Reported-by: default avatarHulk Robot <hulkci@huawei.com>
Signed-off-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
Acked-by: default avatarFugang Duan <fugang.duan@nxp.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      05891200
    • Zhang Changzhong's avatar
      net: stmmac: remove redundant null check before clk_disable_unprepare() · 1c35cc9c
      Zhang Changzhong authored 
      Because clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter, so the additional checks are unnecessary, just
remove them.
Reported-by: default avatarHulk Robot <hulkci@huawei.com>
Signed-off-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1c35cc9c
    • Zhang Changzhong's avatar
      net: xilinx: remove redundant null check before clk_disable_unprepare() · e50fd9b5
      Zhang Changzhong authored 
      Because clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter, so the additional checks are unnecessary, just
remove them.
Reported-by: default avatarHulk Robot <hulkci@huawei.com>
Signed-off-by: default avatarZhang Changzhong <zhangchangzhong@huawei.com>
Reviewed-by: default avatarRadhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e50fd9b5
    • Jakub Kicinski's avatar
      Merge branch 'net-bridge-mcast-initial-IGMPv3-MLDv2-support-part-1' · 6af52ae2
      Jakub Kicinski authored 
      Nikolay Aleksandrov says:

====================
net: bridge: mcast: initial IGMPv3/MLDv2 support (part 1)

This patch-set implements the control plane for initial IGMPv3/MLDv2
support which takes care of include/exclude sets and state transitions
based on the different report types.
Patch 01 arranges the structure better by moving the frequently used
fields together, patch 02 factors out the port group deletion code which is
used in a few places. Patches 03 and 04 add support for source lists and
group modes per port group which are dumped. Patch 05 adds support for
group-and-source specific queries required for IGMPv3/MLDv2. Then patch 06
adds support for group and group-and-source query retransmissions via a new
rexmit timer. Patches 07 and 08 make use of the already present mdb fill
functions when sending notifications so we can have the full mdb entries'
state filled in (with sources, mode etc). Patch 09 takes care of port group
expiration, it switches the group mode to include and deletes it if there
are no sources with active timers. Patches 10-13 are the core changes which
add support for IGMPv3/MLDv2 reports and handle the source list set
operations as per RFCs 3376 and 3810, all IGMPv3/MLDv2 report types with
their transitions should be supported after these patches. I've used RFCs
3376, 3810 and FRR as a reference implementation. The source lists are
capped at 32 entries, we can remove that limitation at a later point which
would require a better data structure to hold them. IGMPv3 processing is
hidden behind the bridge's multicast_igmp_version option which must be set
to 3 in order to enable it. MLDv2 processing is hidden behind the bridge's
multicast_mld_version which must be set to 2 in order to enable it.
Patch 14 improves other querier processing a bit (more about this below).
And finally patch 15 transforms the src gc so it can be used with all mcast
objects since now we have multiple timers that can be running and we
need to make sure they have all finished before freeing the objects.
This is part 1, it only adds control plane support and doesn't change
the fast path. A following patch-set will take care of that.

Here're the sets that will come next (in order):
 - Fast path patch-set which adds support for (S, G) mdb entries needed
   for IGMPv3/MLDv2 forwarding, entry add source (kernel, user-space etc)
   needed for IGMPv3/MLDv2 entry management, entry block mode needed for
   IGMPv3/MLDv2 exclude mode. This set will also add iproute2 support for
   manipulating and showing all the new state.
 - Selftests patches which will verify all state transitions and forwarding
 - Explicit host tracking patch-set, needed for proper fast leave and
   with it fast leave will be enabled for IGMPv3/MLDv2

Not implemented yet:
 - Host IGMPv3/MLDv2 filter support (currently we handle only join/leave
   as before)
 - Proper other querier source timer and value updates
 - IGMPv3/v2 MLDv2/v1 compat (I have a few rough patches for this one)

v4: move old patch 05 to 02 (group del patch), before src lists
    patch 02: set pg's fast leave flag when deleting due to fast leave
    patch 03: now can use the new port del function
              add igmpv2/mldv1 bool which are set when the entry is
              added in those modes (later will be passed as update_timer)
    patch 10: rename update_timer to igmpv2_mldv1 and use the passed
              value from br_multicast_add_group's callers
v3: add IPv6/MLDv2 support, most patches are changed
v2:
 patches 03-04: make src lists RCU friendly so they can be traversed
                when dumping, reduce limit to a more conservative 32
                src group entries for a start
 patches 11-13: remove helper and directly do bitops
 patch      15: force mcast gc on bridge port del to make sure port
                group timers have finished before freeing the port
====================
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6af52ae2
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7