1. 19 11月, 2021 35 次提交
  2. 18 11月, 2021 5 次提交
    • D
      ptp: ocp: Fix a couple NULL vs IS_ERR() checks · c7521d3a
      Dan Carpenter 提交于
      The ptp_ocp_get_mem() function does not return NULL, it returns error
      pointers.
      
      Fixes: 773bda96 ("ptp: ocp: Expose various resources on the timecard.")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7521d3a
    • D
      Merge branch 'lan78xx-napi' · bb8cecf8
      David S. Miller 提交于
      John Efstathiades says:
      
      ===================
      lan78xx NAPI Performance Improvements
      
      This patch set introduces a set of changes to the lan78xx driver
      that were originally developed as part of an investigation into
      the performance of TCP and UDP transfers on an Android system.
      The changes increase the throughput of both UDP and TCP transfers
      and reduce the overall CPU load.
      
      These improvements are also seen on a standard Linux kernel. Typical
      results are included at the end of this document.
      
      The changes to the driver evolved over time. The patches presented
      here attempt to organise the changes in to coherent blocks that
      affect logically connected parts of the driver. The patches do not
      reflect the way in which the code evolved during the performance
      investigation.
      
      Each patch produces a working driver that has an incremental
      improvement but patches 2, 3 and 6 should be considered a single
      update.
      
      The changes affect the following parts of the driver:
      
      1. Deferred URB processing
      
      The deferred URB processing that was originally done by a tasklet
      is now done by a NAPI polling routine. The NAPI cycle has a fixed
      work budget that controls how many received frames are passed to
      the network stack.
      
      Patch 6 introduces the NAPI polling but depends on preceding patches.
      
      The new NAPI polling routine is also responsible for submitting
      Rx and Tx URBs to the USB host controller.
      
      Moving the URB processing to a NAPI-based system "smoothed"
      incoming and outgoing data flows on the Android system under
      investigation. However, taken in isolation, moving from a tasklet
      approach to a NAPI approach made little or no difference to the
      overall performance.
      
      2. URB buffer management
      
      The driver creates a pool of Tx and a pool of Rx URB buffers. Each
      buffer is large enough to accommodate a packet with the maximum MTU
      data. URBs are allocated from these pools as required.
      
      Patch 2 introduces the new Tx buffer pool.
      Patch 3 introduces the new Rx buffer pool.
      
      3. Tx pending data
      
      SKBs containing data to be transmitted are added to a queue. The
      driver tracks free Tx URBs and the corresponding free Tx URB space.
      When new Tx URBs are submitted, pending data is copied into the
      URB buffer until the URB buffer is filled or there is no more
      pending data. This maximises utilisation the LAN78xx internal
      USB and network frame buffers.
      
      New Tx URBs are submitted to the USB host controller as part of the
      NAPI polling cycle.
      
      Patch 2 introduces these changes.
      
      4. Rx URB completion
      
      A new URB is no longer submitted as part of the URB completion
      callback.
      New URBs are submitted during the NAPI polling cycle.
      
      Patch 3 introduces these changes.
      
      5. Rx URB processing
      
      Completed URBs are put on to queue for processing (as is done in the
      current driver). Network packets in completed URBs are copied from
      the URB buffer in to dynamically allocated SKBs and passed to
      the network stack.
      
      The emptied URBs are resubmitted to the USB host controller.
      
      Patch 3 introduces this change. Patch 6 updates the change to use
      NAPI SKBs.
      
      Each packet passed to the network stack is a single NAPI work item.
      If the NAPI work budget is exhausted the remaining packets in the
      URB are put onto an overflow queue that is processed at the start
      of the next NAPI cycle.
      
      Patch 6 introduces this change.
      
      6. Driver-specific hard_header_len
      
      The driver-specific hard_header_len adjustment was removed as it
      broke generic receive offload (GRO) processing. Moreover, it was no
      longer required due the change in Tx pending data management (see
      point 3. above).
      
      Patch 5 introduces this change.
      
      The modification has been tested on four different target machines:
      
      Target           |    CPU     |   ARCH  | cores | kernel |  RAM  |
      -----------------+------------+---------+-------+--------+-------|
      Raspberry Pi 4B  | Cortex-A72 | aarch64 |   4   | 64-bit |  2 GB |
      Nitrogen8M SBC   | Cortex-A53 | aarch64 |   4   | 64-bit |  2 GB |
      Compaq Pressario | Pentium D  | i686    |   2   | 32-bit |  4 GB |
      Dell T3620       | Core i3    | x86_64  |  2+2  | 64-bit | 16 GB |
      
      The targets, apart from the Compaq, each have an on-chip USB3 host
      controller. A PCIe-based USB3 host controller card was added to the
      Compaq to provide the necessary USB3 host interface.
      
      The network throughput was measured using iperf3. The peer device was
      a second Dell T3620 fitted with an Intel i210 network interface. The
      target machine and the peer device were connected via a Netgear GS105
      gigabit switch.
      
      The CPU load was measured using mpstat running on the target machine.
      
      The tables below summarise the throughput and CPU load improvements
      achieved by the updated driver.
      
      The bandwidth is the average bandwidth reported by iperf3 at the end
      of a 60-second test.
      
      The percentage idle figure is the average idle reported across all
      CPU cores on the target machine for the duration of the test.
      
      TCP Rx (target receiving, peer transmitting)
      
                       |   Standard Driver  |   NAPI Driver      |
      Target           | Bandwidth | % Idle | Bandwidth | % Idle |
      -----------------+-----------+--------+--------------------|
      RPi4 Model B     |    941    |  74.9  |    941    |  91.5  |
      Nitrogen8M       |    941    |  76.2  |    941    |  92.7  |
      Compaq Pressario |    941    |  44.5  |    941    |  82.1  |
      Dell T3620       |    941    |  88.9  |    941    |  98.3  |
      
      TCP Tx (target transmitting, peer receiving)
      
                       |   Standard Driver  |   NAPI Driver      |
      Target           | Bandwidth | % Idle | Bandwidth | % Idle |
      -----------------+-----------+--------+--------------------|
      RPi4 Model B     |    683    |  80.1  |    942    |  97.6  |
      Nitrogen8M       |    942    |  97.8  |    942    |  97.3  |
      Compaq Pressario |    939    |  80.0  |    942    |  91.2  |
      Dell T3620       |    942    |  95.3  |    942    |  97.6  |
      
      UDP Rx (target receiving, peer transmitting)
      
                       |   Standard Driver  |   NAPI Driver      |
      Target           | Bandwidth | % Idle | Bandwidth | % Idle |
      -----------------+-----------+--------+--------------------|
      RPi4 Model B     |     -     |    -   | 958 (0%)  |  76.2  |
      Nitrogen8M       | 690 (25%) |  57.7  | 937 (0%)  |  68.5  |
      Compaq Pressario | 958 (0%)  |  50.2  | 958 (0%)  |  61.6  |
      Dell T3620       | 958 (0%)  |  89.6  | 958 (0%)  |  85.3  |
      
      The figure in brackets is the percentage packet loss.
      
      UDP Tx (target transmitting, peer receiving)
      
                       |   Standard Driver  |   NAPI Driver      |
      Target           | Bandwidth | % Idle | Bandwidth | % Idle |
      -----------------+-----------+--------+--------------------|
      RPi4 Model B     |    370    |  75.0  |    886    |  78.9  |
      Nitrogen8M       |    710    |  75.0  |    958    |  85.3  |
      Compaq Pressario |    958    |  65.5  |    958    |  76.6  |
      Dell T3620       |    958    |  97.0  |    958    |  97.3  |
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb8cecf8
    • J
      lan78xx: Introduce NAPI polling support · ec4c7e12
      John Efstathiades 提交于
      This patch introduces a NAPI-style approach for processing completed
      Rx URBs that contributes to improving driver throughput and reducing
      CPU load.
      
      Packets in completed URBs are copied to NAPI SKBs and passed to the
      network stack for processing. Each frame passed to the stack is one
      work item in the NAPI budget.
      
      If the NAPI budget is consumed and frames remain, they are added to
      an overflow queue that is processed at the start of the next NAPI
      polling cycle.
      
      The NAPI handler is also responsible for copying pending Tx data to
      Tx URBs and submitting them to the USB host controller for
      transmission.
      Signed-off-by: NJohn Efstathiades <john.efstathiades@pebblebay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec4c7e12
    • J
      lan78xx: Remove hardware-specific header update · 0dd87266
      John Efstathiades 提交于
      Remove hardware-specific header length adjustment as it is no longer
      required. It also breaks generic receive offload (GRO) processing of
      received TCP frames that results in a TCP ACK being sent for each
      received frame.
      Signed-off-by: NJohn Efstathiades <john.efstathiades@pebblebay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0dd87266
    • J
      lan78xx: Re-order rx_submit() to remove forward declaration · 9d2da721
      John Efstathiades 提交于
      Move position of rx_submit() to remove forward declaration of
      rx_complete() which is now no longer required.
      Signed-off-by: NJohn Efstathiades <john.efstathiades@pebblebay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d2da721