1. 08 1月, 2014 25 次提交
    • S
      i40e: rework shadow ram read functions · a4bcfbb7
      Shannon Nelson 提交于
      Rework Shadow RAM read word/buffer functions to not use AQ Request
      Resource commands.  Requesting resource is not needed for SR read
      operations which are done through SRCTL register.  Access to SR through
      register is controlled through DONE bit within SRCTL.  With this change
      we do not block whole NVM resource for SR read operations.
      
      Change-Id: I73e96cdea39a45ee7b5bdf038e527308de2d9efe
      Signed-off-by: NKamil Krawczyk <kamil.krawczyk@intel.com>
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      a4bcfbb7
    • S
      i40e: check MAC type before any REG access · af89d26c
      Shannon Nelson 提交于
      We need to check if we are dealing with the correct MAC type before we
      try to read anything from the registers.
      
      Change-Id: I3989516999d06c3009e87d6a2eafc20af305c5c2
      Signed-off-by: NKamil Krawczyk <kamil.krawczyk@intel.com>
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      af89d26c
    • S
      i40e: move PF ID init from PF reset to SC init · 5f9116ac
      Shannon Nelson 提交于
      Move PF ID initialization code from PF reset routine to earlier driver
      initialization function.  There are a few operations which need the
      PF ID before the first PF reset is called.
      
      Change-Id: I7e971f7556b46a837149850ec05ce115c35db575
      Signed-off-by: NKamil Krawczyk <kamil.krawczyk@intel.com>
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5f9116ac
    • S
      i40e: Reduce range of interrupt reg in reg test · af9810ea
      Shannon Nelson 提交于
      Use a smaller range of test registers in MFP mode as there are fewer
      resources than when in SFP mode.
      
      Change-Id: I08424890c3f57b5dde5ee99e99724ce252e0875a
      Signed-off-by: NKamil Krawczyk <kamil.krawczyk@intel.com>
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      af9810ea
    • S
      i40e: update firmware api to 1.1 · 981b7545
      Shannon Nelson 提交于
      The firmware's AdminQ interface has matured a little, so update the
      code to use the new fields and values.
      
      Change-Id: I8fcd7b443f268dcf9346bd6a9e940fe9c2958891
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      981b7545
    • S
      i40e: Add code to wait for FW to complete in reset path · 42794bd8
      Shannon Nelson 提交于
      The RSTAT comes back with DEVICE READY to indicate that the HW is ready,
      but we still have to wait for the FW to indicate that the Core and Global
      modules are back up again.  This needs a read of the NVM_ULD register.
      
      Change-Id: I88276165f9cd446d2f166fb4b8cff00521af4bec
      Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
      Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      42794bd8
    • C
      i40e: Bump version · 7f61d1f7
      Catherine Sullivan 提交于
      Version update to 0.3.25-k
      Signed-off-by: NCatherine Sullivan <catherine.sullivan@intel.com>
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      7f61d1f7
    • G
      i40e: Allow VF to set already assigned MAC address · 5017c2a8
      Greg Rose 提交于
      The VF is allowed to request the PF to set its already assigned
      MAC address without generating an error.
      
      Change-Id: I8dfdf353396995dbbb26cafab4e42b451911da3d
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Acked-by: NShannon Nelson <shannon.nelson@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5017c2a8
    • G
      i40e: Stop accepting any VLAN tag on VLAN 0 filter set · 6bbac866
      Greg Rose 提交于
      When the 8021q driver is loaded it sets VLAN 0 filters on all devices.
      This does not mean that any VLAN tagged packet should be accepted.
      Instead accept only VLAN 0 tagged packets so that upper layers can
      interpret the priority bits.
      
      Change-Id: I17274a540b613749612ffe23a3aef2b8ee6ff6a4
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NSibai Li <sibai.li@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6bbac866
    • G
      i40e: Do not enable broadcast promiscuous by default · 1a10370a
      Greg Rose 提交于
      Broadcast promiscuous should only be turned on when general
      promiscuous mode is turned on, otherwise VLAN tagged packets out of
      the assigned VLAN domain are received.
      
      Add a broadcast MAC filter in order to continue to receive
      broadcast traffic on VLANs, MAIN or VMDQ VSI.
      
      Change-Id: I99d8e382a082ee51201228f1226af3b46452ac55
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NSibai Li <sibai.li@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1a10370a
    • A
      i40e: Expose AQ debugfs hooks · f1143c4b
      Anjali Singhai Jain 提交于
      Add more functionality to debugfs to assist development
      and testing of AQ commands.
      
      adds:
      send aq_cmd
      send indirect aq_cmd
      
      Change-Id: I01710cddd33110a6c1e1aabf84cb6e93cda4c42a
      Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
      Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NKavindya Deegala <kavindya.s.deegala@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f1143c4b
    • Y
      net: xfrm: xfrm_policy: silence compiler warning · da7c224b
      Ying Xue 提交于
      Fix below compiler warning:
      
      net/xfrm/xfrm_policy.c:1644:12: warning: ‘xfrm_dst_alloc_copy’ defined but not used [-Wunused-function]
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      da7c224b
    • D
      Merge branch 'tipc' · 8752b5ca
      David S. Miller 提交于
      Jon Maloy says:
      
      ====================
      tipc: link setup and failover improvements
      
      This series consists of four unrelated commits with different purposes.
      
      - Commit #1 is purely cosmetic and pedagogic, hopefully making the
        failover/tunneling logics slightly easier to understand.
      - Commit #2 fixes a bug that has always been in the code, but was not
        discovered until very recently.
      - Commit #3 fixes a non-fatal race issue in the neighbour discovery
        code.
      - Commit #4 removes an unnecessary indirection step during link
        startup.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8752b5ca
    • J
      tipc: make link start event synchronous · 581465fa
      Jon Paul Maloy 提交于
      When a link is created we delay the start event by launching it
      to be executed later in a tasklet. As we hold all the
      necessary locks at the moment of creation, and there is no risk
      of deadlock or contention, this delay serves no purpose in the
      current code.
      
      We remove this obsolete indirection step, and the associated function
      link_start(). At the same time, we rename the function tipc_link_stop()
      to the more appropriate tipc_link_purge_queues().
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      581465fa
    • Y
      tipc: introduce new spinlock to protect struct link_req · f9a2c80b
      Ying Xue 提交于
      Currently, only 'bearer_lock' is used to protect struct link_req in
      the function disc_timeout(). This is unsafe, since the member fields
      'num_nodes' and 'timer_intv' might be accessed by below three different
      threads simultaneously, none of them grabbing bearer_lock in the
      critical region:
      
      link_activate()
        tipc_bearer_add_dest()
          tipc_disc_add_dest()
            req->num_nodes++;
      
      tipc_link_reset()
        tipc_bearer_remove_dest()
          tipc_disc_remove_dest()
            req->num_nodes--
            disc_update()
              read req->num_nodes
      	write req->timer_intv
      
      disc_timeout()
        read req->num_nodes
        read/write req->timer_intv
      
      Without lock protection, the only symptom of a race is that discovery
      messages occasionally may not be sent out. This is not fatal, since such
      messages are best-effort anyway. On the other hand, since discovery
      messages are not time critical, adding a protecting lock brings no
      serious overhead either. So we add a new, dedicated spinlock in
      order to guarantee absolute data consistency in link_req objects.
      This also helps reduce the overall role of the bearer_lock, which
      we want to remove completely in a later commit series.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9a2c80b
    • J
      tipc: remove 'has_redundant_link' flag from STATE link protocol messages · b9d4c339
      Jon Paul Maloy 提交于
      The flag 'has_redundant_link' is defined only in RESET and ACTIVATE
      protocol messages. Due to an ambiguity in the protocol specification it
      is currently also transferred in STATE messages. Its value is used to
      initialize a link state variable, 'permit_changeover', which is used
      to inhibit futile link failover attempts when it is known that the
      peer node has no working links at the moment, although the local node
      may still think it has one.
      
      The fact that 'has_redundant_link' incorrectly is read from STATE
      messages has the effect that 'permit_changeover' sometimes gets a wrong
      value, and permanently blocks any links from being re-established. Such
      failures can only occur in in dual-link systems, and are extremely rare.
      This bug seems to have always been present in the code.
      
      Furthermore, since commit b4b56102
      ("tipc: Ensure both nodes recognize loss of contact between them"),
      the 'permit_changeover' field serves no purpose any more. The task of
      enforcing 'lost contact' cycles at both peer endpoints is now taken
      by a new mechanism, using the flags WAIT_NODE_DOWN and WAIT_PEER_DOWN
      in struct tipc_node to abort unnecessary failover attempts.
      
      We therefore remove the 'has_redundant_link' flag from STATE messages,
      as well as the now redundant 'permit_changeover' variable.
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9d4c339
    • J
      tipc: rename functions related to link failover and improve comments · 170b3927
      Jon Paul Maloy 提交于
      The functionality related to link addition and failover is unnecessarily
      hard to understand and maintain. We try to improve this by renaming
      some of the functions, at the same time adding or improving the
      explanatory comments around them. Names such as "tipc_rcv()" etc. also
      align better with what is used in other networking components.
      
      The changes in this commit are purely cosmetic, no functional changes
      are made.
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Reviewed-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      170b3927
    • D
      net: skbuff: const-ify casts in skb_queue_* functions · fd44b93c
      Daniel Borkmann 提交于
      We should const-ify comparisons on skb_queue_* inline helper
      functions as their parameters are const as well, so lets not
      drop that.
      Suggested-by: NBrad Spengler <spender@grsecurity.net>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd44b93c
    • D
      net: xfrm: xfrm_policy: fix inline not at beginning of declaration · be7928d2
      Daniel Borkmann 提交于
      Fix three warnings related to:
      
        net/xfrm/xfrm_policy.c:1644:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
        net/xfrm/xfrm_policy.c:1656:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
        net/xfrm/xfrm_policy.c:1668:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
      
      Just removing the inline keyword is sufficient as the compiler will
      decide on its own about inlining or not.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be7928d2
    • S
      mlx4_en: Select PTP_1588_CLOCK · 74b9c3ea
      Shawn Bohrer 提交于
      Now that mlx4_en includes a PHC driver it must select PTP_1588_CLOCK.
      
         drivers/built-in.o: In function `mlx4_en_get_ts_info':
      >> en_ethtool.c:(.text+0x391a11): undefined reference to `ptp_clock_index'
         drivers/built-in.o: In function `mlx4_en_remove_timestamp':
      >> (.text+0x397913): undefined reference to `ptp_clock_unregister'
         drivers/built-in.o: In function `mlx4_en_init_timestamp':
      >> (.text+0x397b20): undefined reference to `ptp_clock_register'
      
      Fixes: ad7d4eae ("mlx4_en: Add PTP hardware clock")
      Signed-off-by: NShawn Bohrer <sbohrer@rgmadvisors.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      74b9c3ea
    • 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
    • J
      ipv4: loopback device: ignore value changes after device is upped · dfd1582d
      Jiri Pirko 提交于
      When lo is brought up, new ifa is created. Then, devconf and neigh values
      bitfield should be set so later changes of default values would not
      affect lo values.
      
      Note that the same behaviour is in ipv6. Also note that this is likely
      not an issue in many distros (for example Fedora 19) because userspace
      sets address to lo manually before bringing it up.
      Signed-off-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dfd1582d
    • F
      IPv6: add the option to use anycast addresses as source addresses in echo reply · 509aba3b
      FX Le Bail 提交于
      This change allows to follow a recommandation of RFC4942.
      
      - Add "anycast_src_echo_reply" sysctl to control the use of anycast addresses
        as source addresses for ICMPv6 echo reply. This sysctl is false by default
        to preserve existing behavior.
      - Add inline check ipv6_anycast_destination().
      - Use them in icmpv6_echo_reply().
      
      Reference:
      RFC4942 - IPv6 Transition/Coexistence Security Considerations
         (http://tools.ietf.org/html/rfc4942#section-2.1.6)
      
      2.1.6. Anycast Traffic Identification and Security
      
         [...]
         To avoid exposing knowledge about the internal structure of the
         network, it is recommended that anycast servers now take advantage of
         the ability to return responses with the anycast address as the
         source address if possible.
      Signed-off-by: NFrancois-Xavier Le Bail <fx.lebail@yahoo.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      509aba3b
    • W
      net/mlx4_en: fix error return code in mlx4_en_get_qp() · 9ba75fb0
      Wei Yongjun 提交于
      Fix to return a negative error code from the error handling
      case instead of 0.
      
      Fixes: 837052d0 ('net/mlx4_en: Add netdev support for TCP/IP offloads of vxlan tunneling')
      Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9ba75fb0
  2. 07 1月, 2014 15 次提交