Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 04 2月, 2021 12 次提交
    • S
      octeontx2-af: Handle CPT function level reset · c57c58fd
      由 Srujana Challa 提交于 
      When FLR is initiated for a VF (PCI function level reset),
the parent PF gets a interrupt. PF then sends a message to
admin function (AF), which then cleans up all resources
attached to that VF. This patch adds support to handle
CPT FLR.
Signed-off-by: NNarayana Prasad Raju Atherya <pathreya@marvell.com>
Signed-off-by: NSuheil Chandran <schandran@marvell.com>
Signed-off-by: NSunil Kovvuri Goutham <sgoutham@marvell.com>
Signed-off-by: NSrujana Challa <schalla@marvell.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      c57c58fd
    • S
      octeontx2-af: Add support for CPT1 in debugfs · b0f60fab
      由 Srujana Challa 提交于 
      Adds support to display block CPT1 stats at
"/sys/kernel/debug/octeontx2/cpt1".
Signed-off-by: NMahipal Challa <mchalla@marvell.com>
Signed-off-by: NSrujana Challa <schalla@marvell.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      b0f60fab
    • S
      octeontx2-af: Mailbox changes for 98xx CPT block · de2854c8
      由 Srujana Challa 提交于 
      This patch changes CPT mailbox message format to
support new block CPT1 in 98xx silicon.

cpt_rd_wr_reg ->
    Modify cpt_rd_wr_reg mailbox and its handler to
    accommodate new block CPT1.
cpt_lf_alloc ->
    Modify cpt_lf_alloc mailbox and its handler to
    configure LFs from a block address out of multiple
    blocks of same type. If a PF/VF needs to configure
    LFs from both the blocks then this mbox should be
    called twice.
Signed-off-by: NMahipal Challa <mchalla@marvell.com>
Signed-off-by: NSrujana Challa <schalla@marvell.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      de2854c8
    • M
      net: mdiobus: Prevent spike on MDIO bus reset signal · e0183b97
      由 Mike Looijmans 提交于 
      The mdio_bus reset code first de-asserted the reset by allocating with
GPIOD_OUT_LOW, then asserted and de-asserted again. In other words, if
the reset signal defaulted to asserted, there'd be a short "spike"
before the reset.

Here is what happens depending on the pre-existing state of the reset
signal:
Reset (previously asserted):   ~~~|_|~~~~|_______
Reset (previously deasserted): _____|~~~~|_______
                                  ^ ^    ^
                                  A B    C

At point A, the low going transition is because the reset line is
requested using GPIOD_OUT_LOW. If the line is successfully requested,
the first thing we do is set it high _without_ any delay. This is
point B. So, a glitch occurs between A and B.

We then fsleep() and finally set the GPIO low at point C.

Requesting the line using GPIOD_OUT_HIGH eliminates the A and B
transitions. Instead we get:

Reset (previously asserted)  : ~~~~~~~~~~|______
Reset (previously deasserted): ____|~~~~~|______
                                   ^     ^
                                   A     C

Where A and C are the points described above in the code. Point B
has been eliminated.

The issue was found when we pulled down the reset signal for the
Marvell 88E1512P PHY (because it requires at least 50ms after POR with
an active clock). Looking at the reset signal with a scope revealed a
short spike, point B in the artwork above.
Signed-off-by: NMike Looijmans <mike.looijmans@topic.nl>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20210202143239.10714-1-mike.looijmans@topic.nlSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      e0183b97
    • D
      net: mscc: ocelot: fix error code in mscc_ocelot_probe() · 4160d9ec
      由 Dan Carpenter 提交于 
      Probe should return an error code if platform_get_irq_byname() fails
but it returns success instead.

Fixes: 6c30384e ("net: mscc: ocelot: register devlink ports")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/YBkXyFIl4V9hgxYM@mwandaSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      4160d9ec
    • D
      net: mscc: ocelot: fix error handling bugs in mscc_ocelot_init_ports() · e0c16233
      由 Dan Carpenter 提交于 
      There are several error handling bugs in mscc_ocelot_init_ports().  I
went through the code, and carefully audited it and made fixes and
cleanups.

1) The ocelot_probe_port() function didn't have a mirror release function
   so it was hard to follow.  I created the ocelot_release_port()
   function.
2) In the ocelot_probe_port() function, if the register_netdev() call
   failed, then it lead to a double free_netdev(dev) bug.  Fix this by
   setting "ocelot->ports[port] = NULL" on the error path.
3) I was concerned that the "port" which comes from of_property_read_u32()
   might be out of bounds so I added a check for that.
4) In the original code if ocelot_regmap_init() failed then the driver
   tried to continue but I think that should be a fatal error.
5) If ocelot_probe_port() failed then the most recent devlink was leaked.
   The fix for mostly came Vladimir Oltean.  Get rid of "registered_ports"
   and just set a bit in "devlink_ports_registered" to say when the
   devlink port has been registered (and needs to be unregistered on
   error).  There are fewer than 32 ports so a u32 is large enough for
   this purpose.
6) The error handling if the final ocelot_port_devlink_init() failed had
   two problems.  The "while (port-- >= 0)" loop should have been
   "--port" pre-op instead of a post-op to avoid a buffer underflow.
   The "if (!registered_ports[port])" condition was reversed leading to
   resource leaks and double frees.

Fixes: 6c30384e ("net: mscc: ocelot: register devlink ports")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/YBkXhqRxHtRGzSnJ@mwandaSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      e0c16233
    • J
      Merge branch 'net-use-indirect_call-in-some-dst_ops' · 2d912da0
      由 Jakub Kicinski 提交于 
      Brian Vazquez says:

====================
net: use INDIRECT_CALL in some dst_ops

This patch series uses the INDIRECT_CALL wrappers in some dst_ops
functions to mitigate retpoline costs. Benefits depend on the
platform as described below.

Background: The kernel rewrites the retpoline code at
__x86_indirect_thunk_r11 depending on the CPU's requirements.
The INDIRECT_CALL wrappers provide hints on possible targets and
save the retpoline overhead using a direct call in case the
target matches one of the hints.

The retpoline overhead for the following three cases has been
measured by Luigi Rizzo in microbenchmarks, using CPU performance
counters, and cover reasonably well the range of possible retpoline
overheads compared to a plain indirect call (in equal conditions,
specifically with predicted branch, hot cache):

- just "jmp *(%r11)" on modern platforms like Intel Cascadelake.
  In this case the overhead is just 2 clock cycles:

- "lfence; jmp *(%r11)" on e.g. some recent AMD CPUs.
  In this case the lfence is blocked until pending reads complete,
  so the actual overhead depends on previous instructions.
  The best case we have measured 15 clock cycles of overhead.

- worst case, e.g. skylake, the full retpoline is used

    __x86_indirect_thunk_r11:     call set_u_target
    capture_speculation:          pause
                                  lfence
                                  jmp capture_speculation
    .align 16
    set_up_target:                mov %r11, (%rsp)
                                  ret

   In this case the overhead has been measured in 35-40 clock cycles.

The actual time saved hence depends on the platform and current
clock speed (which varies heavily, especially when C-states are active).
Also note that actual benefit might be lower than expected if the
longer retpoline overlaps with some pending memory read.

MEASUREMENTS:
The INDIRECT_CALL wrappers in this patchset involve the processing
of incoming SYN and generation of syncookies. Hence, the test has been
run by configuring a receiving host with a single NIC rx queue, disabling
RPS and RFS so that all processing occurs on the same core.
An external source generates SYN fast enough to saturate the receiving CPU.
We ran two sets of experiments, with and without the dst_output patch,
comparing the number of syncookies generated over a 20s period
in multiple runs.

Assuming the CPU is saturated, the time per packet is
   t = number_of_packets/total_time
and if the two datasets have statistically meaningful difference,
the difference in times between the two cases gives an estimate
of the benefits from one INDIRECT_CALL.

Here are the experimental results:

Skylake     Syncookies over 20s (5 tests)
---------------------------------------------------
indirect    9166325 9182023 9170093 9134014 9171082
retpoline   9099308 9126350 9154841 9056377 9122376

Computing the stats on the ns_pkt = 20e6/total_packets gives the following:

$ ministat -c 95 -w 70 /tmp/sk-indirect /tmp/sk-retp
x /tmp/sk-indirect
+ /tmp/sk-retp
+----------------------------------------------------------------------+
|x     xx x     +          x    + +           +                       +|
||______M__A_______|_|____________M_____A___________________|          |
+----------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x   5   2.17817e-06   2.18962e-06     2.181e-06  2.182292e-06 4.3252133e-09
+   5   2.18464e-06   2.20839e-06   2.19241e-06  2.194974e-06 8.8695958e-09
Difference at 95.0% confidence
        1.2682e-08 +/- 1.01766e-08
        0.581132% +/- 0.466326%
        (Student's t, pooled s = 6.97772e-09)

This suggests a difference of 13ns +/- 10ns
Our expectation from microbenchmarks was 35-40 cycles per call,
but part of the gains may be eaten by stalls from pending memory reads.

For Cascadelake:
Cascadelake     Syncookies over 20s (5 tests)
---------------------------------------------------------
indirect     10339797 10297547 10366826 10378891 10384854
retpoline    10332674 10366805 10320374 10334272 10374087

Computing the stats on the ns_pkt = 20e6/total_packets gives no
meaningful difference even at just 80% (this was expected):

$ ministat -c 80 -w 70 /tmp/cl-indirect /tmp/cl-retp
x /tmp/cl-indirect
+ /tmp/cl-retp
+----------------------------------------------------------------------+
|   x    x  +     *                   x   + +        +                x|
||______________|_M_________A_____A_______M________|___|               |
+----------------------------------------------------------------------+
    N           Min           Max        Median           Avg        Stddev
x   5   1.92588e-06   1.94221e-06   1.92923e-06  1.931716e-06 6.6936746e-09
+   5   1.92788e-06   1.93791e-06   1.93531e-06  1.933188e-06 4.3734106e-09
No difference proven at 80.0% confidence
====================

Link: https://lore.kernel.org/r/20210201174132.3534118-1-brianvv@google.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      2d912da0
    • B
      net: indirect call helpers for ipv4/ipv6 dst_check functions · bbd807df
      由 Brian Vazquez 提交于 
      This patch avoids the indirect call for the common case:
ip6_dst_check and ipv4_dst_check
Signed-off-by: NBrian Vazquez <brianvv@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      bbd807df
    • B
      net: use indirect call helpers for dst_mtu · f67fbeae
      由 Brian Vazquez 提交于 
      This patch avoids the indirect call for the common case:
ip6_mtu and ipv4_mtu
Signed-off-by: NBrian Vazquez <brianvv@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      f67fbeae
    • B
      net: use indirect call helpers for dst_output · 6585d7dc
      由 Brian Vazquez 提交于 
      This patch avoids the indirect call for the common case:
ip6_output and ip_output
Signed-off-by: NBrian Vazquez <brianvv@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      6585d7dc
    • B
      net: use indirect call helpers for dst_input · e43b2190
      由 Brian Vazquez 提交于 
      This patch avoids the indirect call for the common case:
ip_local_deliver and ip6_input
Signed-off-by: NBrian Vazquez <brianvv@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      e43b2190
    • E
      net: usb: cdc_ncm: use new API for bh tasklet · 4f4e5436
      由 Emil Renner Berthing 提交于 
      This converts the driver to use the new tasklet API introduced in
commit 12cc923f ("tasklet: Introduce new initialization API")

It is unfortunate that we need to add a pointer to the driver context to
get back to the usbnet device, but the space will be reclaimed once
there are no more users of the old API left and we can remove the data
value and flag from the tasklet struct.
Signed-off-by: NEmil Renner Berthing <kernel@esmil.dk>
Link: https://lore.kernel.org/r/20210130234637.26505-1-kernel@esmil.dkSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      4f4e5436
  3. 03 2月, 2021 28 次提交