1. 17 1月, 2014 1 次提交
    • T
      net: Check skb->rxhash in gro_receive · 0b4cec8c
      Tom Herbert 提交于
      When initializing a gro_list for a packet, first check the rxhash of
      the incoming skb against that of the skb's in the list. This should be
      a very strong inidicator of whether the flow is going to be matched,
      and potentially allows a lot of other checks to be short circuited.
      Use skb_hash_raw so that we don't force the hash to be calculated.
      
      Tested by running netperf 200 TCP_STREAMs between two machines with
      GRO, HW rxhash, and 1G. Saw no performance degration, slight reduction
      of time in dev_gro_receive.
      Signed-off-by: NTom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b4cec8c
  2. 16 1月, 2014 3 次提交
  3. 15 1月, 2014 5 次提交
  4. 14 1月, 2014 2 次提交
    • V
      net: make dev_set_mtu() honor notification return code · 2315dc91
      Veaceslav Falico 提交于
      Currently, after changing the MTU for a device, dev_set_mtu() calls
      NETDEV_CHANGEMTU notification, however doesn't verify it's return code -
      which can be NOTIFY_BAD - i.e. some of the net notifier blocks refused this
      change, and continues nevertheless.
      
      To fix this, verify the return code, and if it's an error - then revert the
      MTU to the original one, notify again and pass the error code.
      
      CC: Jiri Pirko <jiri@resnulli.us>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Eric Dumazet <edumazet@google.com>
      CC: Alexander Duyck <alexander.h.duyck@intel.com>
      CC: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Reviewed-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2315dc91
    • E
      net: gro: change GRO overflow strategy · 600adc18
      Eric Dumazet 提交于
      GRO layer has a limit of 8 flows being held in GRO list,
      for performance reason.
      
      When a packet comes for a flow not yet in the list,
      and list is full, we immediately give it to upper
      stacks, lowering aggregation performance.
      
      With TSO auto sizing and FQ packet scheduler, this situation
      happens more often.
      
      This patch changes strategy to simply evict the oldest flow of
      the list. This works better because of the nature of packet
      trains for which GRO is efficient. This also has the effect
      of lowering the GRO latency if many flows are competing.
      
      Tested :
      
      Used a 40Gbps NIC, with 4 RX queues, and 200 concurrent TCP_STREAM
      netperf.
      
      Before patch, aggregate rate is 11Gbps (while a single flow can reach
      30Gbps)
      
      After patch, line rate is reached.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Jerry Chu <hkchu@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      600adc18
  5. 11 1月, 2014 1 次提交
    • J
      net: core: explicitly select a txq before doing l2 forwarding · f663dd9a
      Jason Wang 提交于
      Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
      will cause several issues:
      
      - NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
        instead of lower device which misses the necessary txq synchronization for
        lower device such as txq stopping or frozen required by dev watchdog or
        control path.
      - dev_hard_start_xmit() was called with NULL txq which bypasses the net device
        watchdog.
      - dev_hard_start_xmit() does not check txq everywhere which will lead a crash
        when tso is disabled for lower device.
      
      Fix this by explicitly introducing a new param for .ndo_select_queue() for just
      selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also
      extended to accept this parameter and dev_queue_xmit_accel() was used to do l2
      forwarding transmission.
      
      With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
      to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep
      a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of
      dev_queue_xmit() to do the transmission.
      
      In the future, it was also required for macvtap l2 forwarding support since it
      provides a necessary synchronization method.
      
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: e1000-devel@lists.sourceforge.net
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f663dd9a
  6. 10 1月, 2014 1 次提交
  7. 08 1月, 2014 2 次提交
    • J
      net-gre-gro: Add GRE support to the GRO stack · bf5a755f
      Jerry Chu 提交于
      This patch built on top of Commit 299603e8
      ("net-gro: Prepare GRO stack for the upcoming tunneling support") to add
      the support of the standard GRE (RFC1701/RFC2784/RFC2890) to the GRO
      stack. It also serves as an example for supporting other encapsulation
      protocols in the GRO stack in the future.
      
      The patch supports version 0 and all the flags (key, csum, seq#) but
      will flush any pkt with the S (seq#) flag. This is because the S flag
      is not support by GSO, and a GRO pkt may end up in the forwarding path,
      thus requiring GSO support to break it up correctly.
      
      Currently the "packet_offload" structure only contains L3 (ETH_P_IP/
      ETH_P_IPV6) GRO offload support so the encapped pkts are limited to
      IP pkts (i.e., w/o L2 hdr). But support for other protocol type can
      be easily added, so is the support for GRE variations like NVGRE.
      
      The patch also support csum offload. Specifically if the csum flag is on
      and the h/w is capable of checksumming the payload (CHECKSUM_COMPLETE),
      the code will take advantage of the csum computed by the h/w when
      validating the GRE csum.
      
      Note that commit 60769a5d "ipv4: gre:
      add GRO capability" already introduces GRO capability to IPv4 GRE
      tunnels, using the gro_cells infrastructure. But GRO is done after
      GRE hdr has been removed (i.e., decapped). The following patch applies
      GRO when pkts first come in (before hitting the GRE tunnel code). There
      is some performance advantage for applying GRO as early as possible.
      Also this approach is transparent to other subsystem like Open vSwitch
      where GRE decap is handled outside of the IP stack hence making it
      harder for the gro_cells stuff to apply. On the other hand, some NICs
      are still not capable of hashing on the inner hdr of a GRE pkt (RSS).
      In that case the GRO processing of pkts from the same remote host will
      all happen on the same CPU and the performance may be suboptimal.
      
      I'm including some rough preliminary performance numbers below. Note
      that the performance will be highly dependent on traffic load, mix as
      usual. Moreover it also depends on NIC offload features hence the
      following is by no means a comprehesive study. Local testing and tuning
      will be needed to decide the best setting.
      
      All tests spawned 50 copies of netperf TCP_STREAM and ran for 30 secs.
      (super_netperf 50 -H 192.168.1.18 -l 30)
      
      An IP GRE tunnel with only the key flag on (e.g., ip tunnel add gre1
      mode gre local 10.246.17.18 remote 10.246.17.17 ttl 255 key 123)
      is configured.
      
      The GRO support for pkts AFTER decap are controlled through the device
      feature of the GRE device (e.g., ethtool -K gre1 gro on/off).
      
      1.1 ethtool -K gre1 gro off; ethtool -K eth0 gro off
      thruput: 9.16Gbps
      CPU utilization: 19%
      
      1.2 ethtool -K gre1 gro on; ethtool -K eth0 gro off
      thruput: 5.9Gbps
      CPU utilization: 15%
      
      1.3 ethtool -K gre1 gro off; ethtool -K eth0 gro on
      thruput: 9.26Gbps
      CPU utilization: 12-13%
      
      1.4 ethtool -K gre1 gro on; ethtool -K eth0 gro on
      thruput: 9.26Gbps
      CPU utilization: 10%
      
      The following tests were performed on a different NIC that is capable of
      csum offload. I.e., the h/w is capable of computing IP payload csum
      (CHECKSUM_COMPLETE).
      
      2.1 ethtool -K gre1 gro on (hence will use gro_cells)
      
      2.1.1 ethtool -K eth0 gro off; csum offload disabled
      thruput: 8.53Gbps
      CPU utilization: 9%
      
      2.1.2 ethtool -K eth0 gro off; csum offload enabled
      thruput: 8.97Gbps
      CPU utilization: 7-8%
      
      2.1.3 ethtool -K eth0 gro on; csum offload disabled
      thruput: 8.83Gbps
      CPU utilization: 5-6%
      
      2.1.4 ethtool -K eth0 gro on; csum offload enabled
      thruput: 8.98Gbps
      CPU utilization: 5%
      
      2.2 ethtool -K gre1 gro off
      
      2.2.1 ethtool -K eth0 gro off; csum offload disabled
      thruput: 5.93Gbps
      CPU utilization: 9%
      
      2.2.2 ethtool -K eth0 gro off; csum offload enabled
      thruput: 5.62Gbps
      CPU utilization: 8%
      
      2.2.3 ethtool -K eth0 gro on; csum offload disabled
      thruput: 7.69Gbps
      CPU utilization: 8%
      
      2.2.4 ethtool -K eth0 gro on; csum offload enabled
      thruput: 8.96Gbps
      CPU utilization: 5-6%
      Signed-off-by: NH.K. Jerry Chu <hkchu@google.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf5a755f
    • B
      net: Do not enable tx-nocache-copy by default · cdb3f4a3
      Benjamin Poirier 提交于
      There are many cases where this feature does not improve performance or even
      reduces it.
      
      For example, here are the results from tests that I've run using 3.12.6 on one
      Intel Xeon W3565 and one i7 920 connected by ixgbe adapters. The results are
      from the Xeon, but they're similar on the i7. All numbers report the
      mean±stddev over 10 runs of 10s.
      
      1) latency tests similar to what is described in "c6e1a0d1 net: Allow no-cache
      copy from user on transmit"
      There is no statistically significant difference between tx-nocache-copy
      on/off.
      nic irqs spread out (one queue per cpu)
      
      200x netperf -r 1400,1
      tx-nocache-copy off
              692000±1000 tps
              50/90/95/99% latency (us): 275±2/643.8±0.4/799±1/2474.4±0.3
      tx-nocache-copy on
              693000±1000 tps
              50/90/95/99% latency (us): 274±1/644.1±0.7/800±2/2474.5±0.7
      
      200x netperf -r 14000,14000
      tx-nocache-copy off
              86450±80 tps
              50/90/95/99% latency (us): 334.37±0.02/838±1/2100±20/3990±40
      tx-nocache-copy on
              86110±60 tps
              50/90/95/99% latency (us): 334.28±0.01/837±2/2110±20/3990±20
      
      2) single stream throughput tests
      tx-nocache-copy leads to higher service demand
      
                              throughput  cpu0        cpu1        demand
                              (Gb/s)      (Gcycle)    (Gcycle)    (cycle/B)
      
      nic irqs and netperf on cpu0 (1x netperf -T0,0 -t omni -- -d send)
      
      tx-nocache-copy off     9402±5      9.4±0.2                 0.80±0.01
      tx-nocache-copy on      9403±3      9.85±0.04               0.838±0.004
      
      nic irqs on cpu0, netperf on cpu1 (1x netperf -T1,1 -t omni -- -d send)
      
      tx-nocache-copy off     9401±5      5.83±0.03   5.0±0.1     0.923±0.007
      tx-nocache-copy on      9404±2      5.74±0.03   5.523±0.009 0.958±0.002
      
      As a second example, here are some results from Eric Dumazet with latest
      net-next.
      tx-nocache-copy also leads to higher service demand
      
      (cpu is Intel(R) Xeon(R) CPU X5660  @ 2.80GHz)
      
      lpq83:~# ./ethtool -K eth0 tx-nocache-copy on
      lpq83:~# perf stat ./netperf -H lpq84 -c
      MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lpq84.prod.google.com () port 0 AF_INET
      Recv   Send    Send                          Utilization       Service Demand
      Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
      Size   Size    Size     Time     Throughput  local    remote   local   remote
      bytes  bytes   bytes    secs.    10^6bits/s  % S      % U      us/KB   us/KB
      
       87380  16384  16384    10.00      9407.44   2.50     -1.00    0.522   -1.000
      
       Performance counter stats for './netperf -H lpq84 -c':
      
             4282.648396 task-clock                #    0.423 CPUs utilized
                   9,348 context-switches          #    0.002 M/sec
                      88 CPU-migrations            #    0.021 K/sec
                     355 page-faults               #    0.083 K/sec
          11,812,797,651 cycles                    #    2.758 GHz                     [82.79%]
           9,020,522,817 stalled-cycles-frontend   #   76.36% frontend cycles idle    [82.54%]
           4,579,889,681 stalled-cycles-backend    #   38.77% backend  cycles idle    [67.33%]
           6,053,172,792 instructions              #    0.51  insns per cycle
                                                   #    1.49  stalled cycles per insn [83.64%]
             597,275,583 branches                  #  139.464 M/sec                   [83.70%]
               8,960,541 branch-misses             #    1.50% of all branches         [83.65%]
      
            10.128990264 seconds time elapsed
      
      lpq83:~# ./ethtool -K eth0 tx-nocache-copy off
      lpq83:~# perf stat ./netperf -H lpq84 -c
      MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to lpq84.prod.google.com () port 0 AF_INET
      Recv   Send    Send                          Utilization       Service Demand
      Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
      Size   Size    Size     Time     Throughput  local    remote   local   remote
      bytes  bytes   bytes    secs.    10^6bits/s  % S      % U      us/KB   us/KB
      
       87380  16384  16384    10.00      9412.45   2.15     -1.00    0.449   -1.000
      
       Performance counter stats for './netperf -H lpq84 -c':
      
             2847.375441 task-clock                #    0.281 CPUs utilized
                  11,632 context-switches          #    0.004 M/sec
                      49 CPU-migrations            #    0.017 K/sec
                     354 page-faults               #    0.124 K/sec
           7,646,889,749 cycles                    #    2.686 GHz                     [83.34%]
           6,115,050,032 stalled-cycles-frontend   #   79.97% frontend cycles idle    [83.31%]
           1,726,460,071 stalled-cycles-backend    #   22.58% backend  cycles idle    [66.55%]
           2,079,702,453 instructions              #    0.27  insns per cycle
                                                   #    2.94  stalled cycles per insn [83.22%]
             363,773,213 branches                  #  127.757 M/sec                   [83.29%]
               4,242,732 branch-misses             #    1.17% of all branches         [83.51%]
      
            10.128449949 seconds time elapsed
      
      CC: Tom Herbert <therbert@google.com>
      Signed-off-by: NBenjamin Poirier <bpoirier@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cdb3f4a3
  8. 07 1月, 2014 1 次提交
  9. 06 1月, 2014 2 次提交
  10. 04 1月, 2014 3 次提交
  11. 03 1月, 2014 7 次提交
    • F
      {pktgen, xfrm} Show spi value properly when ipsec turned on · 8101328b
      Fan Du 提交于
      If user run pktgen plus ipsec by using spi, show spi value
      properly when cat /proc/net/pktgen/ethX
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      8101328b
    • F
      {pktgen, xfrm} Introduce xfrm_state_lookup_byspi for pktgen · c454997e
      Fan Du 提交于
      Introduce xfrm_state_lookup_byspi to find user specified by custom
      from "pgset spi xxx". Using this scheme, any flow regardless its
      saddr/daddr could be transform by SA specified with configurable
      spi.
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      c454997e
    • F
      {pktgen, xfrm} Construct skb dst for tunnel mode transformation · cf93d47e
      Fan Du 提交于
      IPsec tunnel mode encapuslation needs to set outter ip header
      with right protocol/ttl/id value with regard to skb->dst->child.
      
      Looking up a rt in a standard way is absolutely wrong for every
      packet transmission. In a simple way, construct a dst by setting
      neccessary information to make tunnel mode encapuslation working.
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      cf93d47e
    • F
      {pktgen, xfrm} Using "pgset spi xxx" to spedifiy SA for a given flow · de4aee7d
      Fan Du 提交于
      User could set specific SPI value to arm pktgen flow with IPsec
      transformation, instead of looking up SA by sadr/daddr. The reaseon
      to do so is because current state lookup scheme is both slow and, most
      important of all, in fact pktgen doesn't need to match any SA state
      addresses information, all it needs is the SA transfromation shell to
      do the encapuslation.
      
      And this option also provide user an alternative to using pktgen
      test existing SA without creating new ones.
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      de4aee7d
    • F
      {pktgen, xfrm} Add statistics counting when transforming · 6de9ace4
      Fan Du 提交于
      so /proc/net/xfrm_stat could give user clue about what's
      wrong in this process.
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      6de9ace4
    • F
      {pktgen, xfrm} Correct xfrm state lock usage when transforming · 0af0a413
      Fan Du 提交于
      xfrm_state lock protects its state, i.e., VALID/DEAD and statistics,
      not the transforming procedure, as both mode/type output functions
      are reentrant.
      
      Another issue is state lock can be used in BH context when state timer
      alarmed, after transformation in pktgen, update state statistics acquiring
      state lock should disabled BH context for a moment. Otherwise LOCKDEP
      critisize this:
      
      [   62.354339] pktgen: Packet Generator for packet performance testing. Version: 2.74
      [   62.655444]
      [   62.655448] =================================
      [   62.655451] [ INFO: inconsistent lock state ]
      [   62.655455] 3.13.0-rc2+ #70 Not tainted
      [   62.655457] ---------------------------------
      [   62.655459] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      [   62.655463] kpktgend_0/2764 [HC0[0]:SC0[0]:HE1:SE1] takes:
      [   62.655466]  (&(&x->lock)->rlock){+.?...}, at: [<ffffffffa00886f6>] pktgen_thread_worker+0x1796/0x1860 [pktgen]
      [   62.655479] {IN-SOFTIRQ-W} state was registered at:
      [   62.655484]   [<ffffffff8109a61d>] __lock_acquire+0x62d/0x1d70
      [   62.655492]   [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   62.655498]   [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
      [   62.655505]   [<ffffffff816dc3a3>] xfrm_timer_handler+0x43/0x290
      [   62.655511]   [<ffffffff81059437>] __tasklet_hrtimer_trampoline+0x17/0x40
      [   62.655519]   [<ffffffff8105a1b7>] tasklet_hi_action+0xd7/0xf0
      [   62.655523]   [<ffffffff81059ac6>] __do_softirq+0xe6/0x2d0
      [   62.655526]   [<ffffffff8105a026>] irq_exit+0x96/0xc0
      [   62.655530]   [<ffffffff8177fd0a>] smp_apic_timer_interrupt+0x4a/0x60
      [   62.655537]   [<ffffffff8177e96f>] apic_timer_interrupt+0x6f/0x80
      [   62.655541]   [<ffffffff8100b7c6>] arch_cpu_idle+0x26/0x30
      [   62.655547]   [<ffffffff810ace28>] cpu_startup_entry+0x88/0x2b0
      [   62.655552]   [<ffffffff81761c3c>] rest_init+0xbc/0xd0
      [   62.655557]   [<ffffffff81ea5e5e>] start_kernel+0x3c4/0x3d1
      [   62.655583]   [<ffffffff81ea55a8>] x86_64_start_reservations+0x2a/0x2c
      [   62.655588]   [<ffffffff81ea569f>] x86_64_start_kernel+0xf5/0xfc
      [   62.655592] irq event stamp: 77
      [   62.655594] hardirqs last  enabled at (77): [<ffffffff810ab7f2>] vprintk_emit+0x1b2/0x520
      [   62.655597] hardirqs last disabled at (76): [<ffffffff810ab684>] vprintk_emit+0x44/0x520
      [   62.655601] softirqs last  enabled at (22): [<ffffffff81059b57>] __do_softirq+0x177/0x2d0
      [   62.655605] softirqs last disabled at (15): [<ffffffff8105a026>] irq_exit+0x96/0xc0
      [   62.655609]
      [   62.655609] other info that might help us debug this:
      [   62.655613]  Possible unsafe locking scenario:
      [   62.655613]
      [   62.655616]        CPU0
      [   62.655617]        ----
      [   62.655618]   lock(&(&x->lock)->rlock);
      [   62.655622]   <Interrupt>
      [   62.655623]     lock(&(&x->lock)->rlock);
      [   62.655626]
      [   62.655626]  *** DEADLOCK ***
      [   62.655626]
      [   62.655629] no locks held by kpktgend_0/2764.
      [   62.655631]
      [   62.655631] stack backtrace:
      [   62.655636] CPU: 0 PID: 2764 Comm: kpktgend_0 Not tainted 3.13.0-rc2+ #70
      [   62.655638] Hardware name: innotek GmbH VirtualBox, BIOS VirtualBox 12/01/2006
      [   62.655642]  ffffffff8216b7b0 ffff88001be43ab8 ffffffff8176af37 0000000000000007
      [   62.655652]  ffff88001c8d4fc0 ffff88001be43b18 ffffffff81766d78 0000000000000000
      [   62.655663]  ffff880000000001 ffff880000000001 ffffffff8101025f ffff88001be43b18
      [   62.655671] Call Trace:
      [   62.655680]  [<ffffffff8176af37>] dump_stack+0x46/0x58
      [   62.655685]  [<ffffffff81766d78>] print_usage_bug+0x1f1/0x202
      [   62.655691]  [<ffffffff8101025f>] ? save_stack_trace+0x2f/0x50
      [   62.655696]  [<ffffffff81099f8c>] mark_lock+0x28c/0x2f0
      [   62.655700]  [<ffffffff810994b0>] ? check_usage_forwards+0x150/0x150
      [   62.655704]  [<ffffffff8109a67a>] __lock_acquire+0x68a/0x1d70
      [   62.655712]  [<ffffffff81115b09>] ? irq_work_queue+0x69/0xb0
      [   62.655717]  [<ffffffff810ab7f2>] ? vprintk_emit+0x1b2/0x520
      [   62.655722]  [<ffffffff8109cec5>] ? trace_hardirqs_on_caller+0x105/0x1d0
      [   62.655730]  [<ffffffffa00886f6>] ? pktgen_thread_worker+0x1796/0x1860 [pktgen]
      [   62.655734]  [<ffffffff8109c3c7>] lock_acquire+0x97/0x130
      [   62.655741]  [<ffffffffa00886f6>] ? pktgen_thread_worker+0x1796/0x1860 [pktgen]
      [   62.655745]  [<ffffffff81774af6>] _raw_spin_lock+0x36/0x70
      [   62.655752]  [<ffffffffa00886f6>] ? pktgen_thread_worker+0x1796/0x1860 [pktgen]
      [   62.655758]  [<ffffffffa00886f6>] pktgen_thread_worker+0x1796/0x1860 [pktgen]
      [   62.655766]  [<ffffffffa0087a79>] ? pktgen_thread_worker+0xb19/0x1860 [pktgen]
      [   62.655771]  [<ffffffff8109cf9d>] ? trace_hardirqs_on+0xd/0x10
      [   62.655777]  [<ffffffff81775410>] ? _raw_spin_unlock_irq+0x30/0x40
      [   62.655785]  [<ffffffff8151faa0>] ? e1000_clean+0x9d0/0x9d0
      [   62.655791]  [<ffffffff81094310>] ? __init_waitqueue_head+0x60/0x60
      [   62.655795]  [<ffffffff81094310>] ? __init_waitqueue_head+0x60/0x60
      [   62.655800]  [<ffffffffa0086f60>] ? mod_cur_headers+0x7f0/0x7f0 [pktgen]
      [   62.655806]  [<ffffffff81078f84>] kthread+0xe4/0x100
      [   62.655813]  [<ffffffff81078ea0>] ? flush_kthread_worker+0x170/0x170
      [   62.655819]  [<ffffffff8177dc6c>] ret_from_fork+0x7c/0xb0
      [   62.655824]  [<ffffffff81078ea0>] ? flush_kthread_worker+0x170/0x170
      Signed-off-by: NFan Du <fan.du@windriver.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      0af0a413
    • D
      netpoll: Fix missing TXQ unlock and and OOPS. · aca5f58f
      David S. Miller 提交于
      The VLAN tag handling code in netpoll_send_skb_on_dev() has two problems.
      
      1) It exits without unlocking the TXQ.
      
      2) It then tries to queue a NULL skb to npinfo->txq.
      Reported-by: NAhmed Tamrawi <atamrawi@iastate.edu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aca5f58f
  12. 02 1月, 2014 2 次提交
  13. 01 1月, 2014 2 次提交
    • Z
    • D
      vlan: Fix header ops passthru when doing TX VLAN offload. · 2205369a
      David S. Miller 提交于
      When the vlan code detects that the real device can do TX VLAN offloads
      in hardware, it tries to arrange for the real device's header_ops to
      be invoked directly.
      
      But it does so illegally, by simply hooking the real device's
      header_ops up to the VLAN device.
      
      This doesn't work because we will end up invoking a set of header_ops
      routines which expect a device type which matches the real device, but
      will see a VLAN device instead.
      
      Fix this by providing a pass-thru set of header_ops which will arrange
      to pass the proper real device instead.
      
      To facilitate this add a dev_rebuild_header().  There are
      implementations which provide a ->cache and ->create but not a
      ->rebuild (f.e. PLIP).  So we need a helper function just like
      dev_hard_header() to avoid crashes.
      
      Use this helper in the one existing place where the
      header_ops->rebuild was being invoked, the neighbour code.
      
      With lots of help from Florian Westphal.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2205369a
  14. 22 12月, 2013 1 次提交
  15. 20 12月, 2013 1 次提交
  16. 18 12月, 2013 5 次提交
  17. 14 12月, 2013 1 次提交