1. 26 6月, 2013 5 次提交
  2. 13 6月, 2013 2 次提交
    • J
      macvtap: fix uninitialized return value macvtap_ioctl_set_queue() · f57855a5
      Jason Wang 提交于
      Return -EINVAL on illegal flag instead of uninitialized value. This fixes the
      kbuild test warning.
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f57855a5
    • J
      macvtap: slient sparse warnings · d9a90a31
      Jason Wang 提交于
      This patch silents the following sparse warnings:
      
      drivers/net/macvtap.c:98:9: warning: incorrect type in assignment (different
      address spaces)
      drivers/net/macvtap.c:98:9:    expected struct macvtap_queue *<noident>
      drivers/net/macvtap.c:98:9:    got struct macvtap_queue [noderef]
      <asn:4>*<noident>
      drivers/net/macvtap.c:120:9: warning: incorrect type in assignment (different
      address spaces)
      drivers/net/macvtap.c:120:9:    expected struct macvtap_queue *<noident>
      drivers/net/macvtap.c:120:9:    got struct macvtap_queue [noderef]
      <asn:4>*<noident>
      drivers/net/macvtap.c:151:22: error: incompatible types in comparison expression
      (different address spaces)
      drivers/net/macvtap.c:233:23: error: incompatible types in comparison expression
      (different address spaces)
      drivers/net/macvtap.c:243:23: error: incompatible types in comparison expression
      (different address spaces)
      drivers/net/macvtap.c:247:15: error: incompatible types in comparison expression
      (different address spaces)
        CC [M]  drivers/net/macvtap.o
      drivers/net/macvlan.c:232:24: error: incompatible types in comparison expression
      (different address spaces)
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d9a90a31
  3. 08 6月, 2013 6 次提交
  4. 29 5月, 2013 1 次提交
  5. 28 3月, 2013 1 次提交
  6. 27 3月, 2013 1 次提交
  7. 28 2月, 2013 1 次提交
  8. 14 2月, 2013 1 次提交
    • P
      net: Fix possible wrong checksum generation. · c9af6db4
      Pravin B Shelar 提交于
      Patch cef401de (net: fix possible wrong checksum
      generation) fixed wrong checksum calculation but it broke TSO by
      defining new GSO type but not a netdev feature for that type.
      net_gso_ok() would not allow hardware checksum/segmentation
      offload of such packets without the feature.
      
      Following patch fixes TSO and wrong checksum. This patch uses
      same logic that Eric Dumazet used. Patch introduces new flag
      SKBTX_SHARED_FRAG if at least one frag can be modified by
      the user. but SKBTX_SHARED_FRAG flag is kept in skb shared
      info tx_flags rather than gso_type.
      
      tx_flags is better compared to gso_type since we can have skb with
      shared frag without gso packet. It does not link SHARED_FRAG to
      GSO, So there is no need to define netdev feature for this.
      Signed-off-by: NPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9af6db4
  9. 28 1月, 2013 1 次提交
    • E
      net: fix possible wrong checksum generation · cef401de
      Eric Dumazet 提交于
      Pravin Shelar mentioned that GSO could potentially generate
      wrong TX checksum if skb has fragments that are overwritten
      by the user between the checksum computation and transmit.
      
      He suggested to linearize skbs but this extra copy can be
      avoided for normal tcp skbs cooked by tcp_sendmsg().
      
      This patch introduces a new SKB_GSO_SHARED_FRAG flag, set
      in skb_shinfo(skb)->gso_type if at least one frag can be
      modified by the user.
      
      Typical sources of such possible overwrites are {vm}splice(),
      sendfile(), and macvtap/tun/virtio_net drivers.
      
      Tested:
      
      $ netperf -H 7.7.8.84
      MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
      7.7.8.84 () port 0 AF_INET
      Recv   Send    Send
      Socket Socket  Message  Elapsed
      Size   Size    Size     Time     Throughput
      bytes  bytes   bytes    secs.    10^6bits/sec
      
       87380  16384  16384    10.00    3959.52
      
      $ netperf -H 7.7.8.84 -t TCP_SENDFILE
      TCP SENDFILE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.8.84 ()
      port 0 AF_INET
      Recv   Send    Send
      Socket Socket  Message  Elapsed
      Size   Size    Size     Time     Throughput
      bytes  bytes   bytes    secs.    10^6bits/sec
      
       87380  16384  16384    10.00    3216.80
      
      Performance of the SENDFILE is impacted by the extra allocation and
      copy, and because we use order-0 pages, while the TCP_STREAM uses
      bigger pages.
      Reported-by: NPravin Shelar <pshelar@nicira.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cef401de
  10. 13 8月, 2012 1 次提交
  11. 08 6月, 2012 1 次提交
  12. 12 5月, 2012 1 次提交
  13. 02 5月, 2012 5 次提交
  14. 14 2月, 2012 1 次提交
  15. 21 12月, 2011 1 次提交
  16. 24 11月, 2011 1 次提交
  17. 21 10月, 2011 5 次提交
  18. 21 9月, 2011 1 次提交
  19. 16 9月, 2011 1 次提交
  20. 07 7月, 2011 1 次提交
  21. 12 6月, 2011 1 次提交
    • J
      virtio_net: introduce VIRTIO_NET_HDR_F_DATA_VALID · 10a8d94a
      Jason Wang 提交于
      There's no need for the guest to validate the checksum if it have been
      validated by host nics. So this patch introduces a new flag -
      VIRTIO_NET_HDR_F_DATA_VALID which is used to bypass the checksum
      examing in guest. The backend (tap/macvtap) may set this flag when
      met skbs with CHECKSUM_UNNECESSARY to save cpu utilization.
      
      No feature negotiation is needed as old driver just ignore this flag.
      
      Iperf shows 12%-30% performance improvement for UDP traffic. For TCP,
      when gro is on no difference as it produces skb with partial
      checksum. But when gro is disabled, 20% or even higher improvement
      could be measured by netperf.
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10a8d94a
  22. 08 3月, 2011 1 次提交