1. 10 Mar, 2014 12 commits
    • KY Srinivasan's avatar
      Drivers: net: hyperv: Enable receive side IP checksum offload · e3d605ed
      KY Srinivasan authored
      Enable receive side checksum offload.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Reviewed-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3d605ed
    • KY Srinivasan's avatar
      Drivers: net: hyperv: Enable offloads on the host · 4a0e70ae
      KY Srinivasan authored
      Prior to enabling guest side offloads, enable the offloads on the host.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Reviewed-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a0e70ae
    • KY Srinivasan's avatar
      Drivers: net: hyperv: Cleanup the send path · 8a00251a
      KY Srinivasan authored
      In preparation for enabling offloads, cleanup the send path.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Reviewed-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a00251a
    • KY Srinivasan's avatar
      Drivers: net: hyperv: Enable scatter gather I/O · 54a7357f
      KY Srinivasan authored
      Cleanup the code and enable scatter gather I/O.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Reviewed-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54a7357f
    • Tim Harvey's avatar
      sky2: allow mac to come from dt · 3ee2f8ce
      Tim Harvey authored
      The driver reads the mac address from the device registers which would
      need to have been programmed by the bootloader.  This patch adds
      the ability to pull the mac from devicetree via the pci device dt node.
      Signed-off-by: default avatarTim Harvey <tharvey@gateworks.com>
      Cc: netdev@vger.kernel.org
      Cc: devicetree@vger.kernel.org
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      
      Changes since v2:
       - eliminated use of stack tmpaddr per feedback
      
      Changes since v1:
       - simplified based on feedback
       - fixed formatting
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ee2f8ce
    • Eric Dumazet's avatar
      l2tp: fix unused variable warning · 746e3499
      Eric Dumazet authored
      net/l2tp/l2tp_core.c:1111:15: warning: unused variable
      'sk' [-Wunused-variable]
      
      Fixes: 31c70d59 ("l2tp: keep original skb ownership")
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      746e3499
    • Kleber Sacilotto de Souza's avatar
      IB/mlx5_core: remove unreachable function call in module init · c120e9e0
      Kleber Sacilotto de Souza authored
      The call to mlx5_health_cleanup() in the module init function can never
      be reached. Removing it.
      Signed-off-by: default avatarKleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
      Acked-by: default avatarEli Cohen <eli@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c120e9e0
    • Eric Dumazet's avatar
      netlink: autosize skb lengthes · 9063e21f
      Eric Dumazet authored
      One known problem with netlink is the fact that NLMSG_GOODSIZE is
      really small on PAGE_SIZE==4096 architectures, and it is difficult
      to know in advance what buffer size is used by the application.
      
      This patch adds an automatic learning of the size.
      
      First netlink message will still be limited to ~4K, but if user used
      bigger buffers, then following messages will be able to use up to 16KB.
      
      This speedups dump() operations by a large factor and should be safe
      for legacy applications.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Thomas Graf <tgraf@suug.ch>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9063e21f
    • Edward Cree's avatar
      sfc: Use ether_addr_copy and eth_broadcast_addr · cd84ff4d
      Edward Cree authored
      Faster than memcpy/memset on some architectures.
      Signed-off-by: default avatarEdward Cree <ecree@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cd84ff4d
    • David S. Miller's avatar
      Merge branch 'gianfar-next' · 19433646
      David S. Miller authored
      Claudiu Manoil says:
      
      ====================
      gianfar: Tx timeout issue
      
      There's an older Tx timeout issue showing up on etsec2 devices
      with 2 CPUs.  I pinned this issue down to processing overhead
      incurred by supporting multiple Tx/Rx rings, as explained in
      the 2nd patch below.  But before this, there's also a concurency
      issue leading to Rx/Tx spurrious interrupts, addressed by the
      'Tx NAPI' patch below.
      The Tx timeout can be triggered with multiple Tx flows,
      'iperf -c -N 8' commands, on a 2 CPUs etsec2 based (P1020) board.
      
      Before the patches:
      """
      root@p1020rdb-pc:~# iperf -c 172.16.1.3 -n 1000M -P 8 &
      [...]
      root@p1020rdb-pc:~# NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue 1 timed out
      WARNING: at net/sched/sch_generic.c:279
      Modules linked in:
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.13.0-rc3-03386-g89ea59c #23
      task: ed84ef40 ti: ed868000 task.ti: ed868000
      NIP: c04627a8 LR: c04627a8 CTR: c02fb270
      REGS: ed869d00 TRAP: 0700   Not tainted  (3.13.0-rc3-03386-g89ea59c)
      MSR: 00029000 <CE,EE,ME>  CR: 44000022  XER: 20000000
      [...]
      
      root@p1020rdb-pc:~# [ ID] Interval       Transfer     Bandwidth
      [  5]  0.0-19.3 sec  1000 MBytes    434 Mbits/sec
      [  8]  0.0-39.7 sec  1000 MBytes    211 Mbits/sec
      [  9]  0.0-40.1 sec  1000 MBytes    209 Mbits/sec
      [  3]  0.0-40.2 sec  1000 MBytes    209 Mbits/sec
      [ 10]  0.0-59.0 sec  1000 MBytes    142 Mbits/sec
      [  7]  0.0-74.6 sec  1000 MBytes    112 Mbits/sec
      [  6]  0.0-74.7 sec  1000 MBytes    112 Mbits/sec
      [  4]  0.0-74.7 sec  1000 MBytes    112 Mbits/sec
      [SUM]  0.0-74.7 sec  7.81 GBytes    898 Mbits/sec
      
      root@p1020rdb-pc:~# ifconfig eth1
      eth1      Link encap:Ethernet  HWaddr 00:04:9f:00:13:01
                inet addr:172.16.1.1  Bcast:172.16.255.255  Mask:255.255.0.0
                inet6 addr: fe80::204:9fff:fe00:1301/64 Scope:Link
                UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                RX packets:708722 errors:0 dropped:0 overruns:0 frame:0
                TX packets:8717849 errors:6 dropped:0 overruns:1470 carrier:0
                collisions:0 txqueuelen:1000
                RX bytes:58118018 (55.4 MiB)  TX bytes:274069482 (261.3 MiB)
                Base address:0xa000
      
      """
      
      After applying the patches:
      """
      root@p1020rdb-pc:~# iperf -c 172.16.1.3 -n 1000M -P 8 &
      [...]
      root@p1020rdb-pc:~# [ ID] Interval       Transfer     Bandwidth
      [  9]  0.0-70.5 sec  1000 MBytes    119 Mbits/sec
      [  5]  0.0-70.5 sec  1000 MBytes    119 Mbits/sec
      [  6]  0.0-70.7 sec  1000 MBytes    119 Mbits/sec
      [  4]  0.0-71.0 sec  1000 MBytes    118 Mbits/sec
      [  8]  0.0-71.1 sec  1000 MBytes    118 Mbits/sec
      [  3]  0.0-71.2 sec  1000 MBytes    118 Mbits/sec
      [ 10]  0.0-71.3 sec  1000 MBytes    118 Mbits/sec
      [  7]  0.0-71.3 sec  1000 MBytes    118 Mbits/sec
      [SUM]  0.0-71.3 sec  7.81 GBytes    942 Mbits/sec
      
      root@p1020rdb-pc:~# ifconfig eth1
      eth1      Link encap:Ethernet  HWaddr 00:04:9f:00:13:01
                inet addr:172.16.1.1  Bcast:172.16.255.255  Mask:255.255.0.0
                inet6 addr: fe80::204:9fff:fe00:1301/64 Scope:Link
                UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                RX packets:728446 errors:0 dropped:0 overruns:0 frame:0
                TX packets:8690057 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:1000
                RX bytes:59732650 (56.9 MiB)  TX bytes:271554306 (258.9 MiB)
                Base address:0xa000
      """
      v2: PATCH 2:
          Replaced CPP check with run-time condition to
          limit the number of queues. Updated comments.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19433646
    • Claudiu Manoil's avatar
      gianfar: Use Single-Queue polling for "fsl,etsec2" · 71ff9e3d
      Claudiu Manoil authored
      For the "fsl,etsec2" compatible models the driver currently
      supports 8 Tx and Rx DMA rings (aka HW queues).  However, there
      are only 2 pairs of Rx/Tx interrupt lines, as these controllers
      are integrated in low power SoCs with 2 CPUs at most.  As a result,
      there are at most 2 NAPI instances that have to service multiple
      Tx and Rx queues for these devices.  This complicates the NAPI
      polling routine having to iterate over the mutiple Rx/Tx queues
      hooked to the same interrupt lines.  And there's also an overhead
      at HW level, as the controller needs to service all the 8 Tx rings
      in a round robin manner.  The combined overhead shows up for multi
      parallel Tx flows transmitted by the kernel stack, when the driver
      usually starts returning NETDEV_TX_BUSY leading to NETDEV WATCHDOG
      Tx timeout triggering if the Tx path is congested for too long.
      
      As an alternative, this patch makes the driver support only one
      Tx/Rx DMA ring per NAPI instance (per interrupt group or pair
      of Tx/Rx interrupt lines) by default.  The simplified single queue
      polling routine (gfar_poll_sq) will be the default napi poll routine
      for the etsec2 devices too.  Some adjustments needed to be made to
      link the Tx/Rx HW queues with each NAPI instance (2 in this case).
      The gfar_poll_sq() is already successfully used by older SQ_SG_MODE
      (single interrupt group) controllers.
      This patch fixes Tx timeout triggering under heavy Tx traffic load
      (i.e. iperf -c -P 8) for the "fsl,etsec2" (currently the only
      MQ_MG_MODE devices).  There's also a significant memory footprint
      reduction by supporting 2 Rx/Tx DMA rings (at most), instead of 8,
      for these devices.
      Signed-off-by: default avatarClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71ff9e3d
    • Claudiu Manoil's avatar
      gianfar: Separate out the Tx interrupt handling (Tx NAPI) · aeb12c5e
      Claudiu Manoil authored
      There are some concurrency issues on devices w/ 2 CPUs related
      to the handling of Rx and Tx interrupts.  eTSEC has separate
      interrupt lines for Rx and Tx but a single imask register
      to mask these interrupts and a single NAPI instance to handle
      both Rx and Tx work.  As a result, the Rx and Tx ISRs are
      identical, both are invoking gfar_schedule_cleanup(), however
      both handlers can be entered at the same time when the Rx and
      Tx interrupts are taken by different CPUs.  In this case
      spurrious interrupts (SPU) show up (in /proc/interrupts)
      indicating a concurrency issue.  Also, Tx overruns followed
      by Tx timeout have been observed under heavy Tx traffic load.
      
      To address these issues, the schedule cleanup ISR part has
      been changed to handle the Rx and Tx interrupts independently.
      The patch adds a separate NAPI poll routine for Tx cleanup to
      be triggerred independently by the Tx confirmation interrupts
      only.  Existing poll functions are modified to handle only
      the Rx path processing.  The Tx poll routine does not need a
      budget, since Tx processing doesn't consume NAPI budget, and
      hence it is registered with minimum NAPI weight.
      NAPI scheduling does not require locking since there are
      different NAPI instances between the Rx and Tx confirmation
      paths now.
      So, the patch fixes the occurence of spurrious Rx/Tx interrupts.
      Tx overruns also occur less frequently now.
      Signed-off-by: default avatarClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aeb12c5e
  2. 09 Mar, 2014 3 commits
  3. 08 Mar, 2014 16 commits
  4. 07 Mar, 2014 9 commits