1. 17 11月, 2011 1 次提交
  2. 09 5月, 2011 1 次提交
    • M
      net: Allow ethtool to set interface in loopback mode. · eed2a12f
      Mahesh Bandewar 提交于
      This patch enables ethtool to set the loopback mode on a given interface.
      By configuring the interface in loopback mode in conjunction with a policy
      route / rule, a userland application can stress the egress / ingress path
      exposing the flows of the change in progress and potentially help developer(s)
      understand the impact of those changes without even sending a packet out
      on the network.
      
      Following set of commands illustrates one such example -
          a) ip -4 addr add 192.168.1.1/24 dev eth1
          b) ip -4 rule add from all iif eth1 lookup 250
          c) ip -4 route add local 0/0 dev lo proto kernel scope host table 250
          d) arp -Ds 192.168.1.100 eth1
          e) arp -Ds 192.168.1.200 eth1
          f) sysctl -w net.ipv4.ip_nonlocal_bind=1
          g) sysctl -w net.ipv4.conf.all.accept_local=1
          # Assuming that the machine has 8 cores
          h) taskset 000f netserver -L 192.168.1.200
          i) taskset 00f0 netperf -t TCP_CRR -L 192.168.1.100 -H 192.168.1.200 -l 30
      Signed-off-by: NMahesh Bandewar <maheshb@google.com>
      Acked-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eed2a12f
  3. 18 4月, 2011 1 次提交
    • K
      ip6_pol_route panic: Do not allow VLAN on loopback · 0553c891
      Krishna Kumar 提交于
      Several tests in the ipv6 routing code check IFF_LOOPBACK, and
      allowing stacking such as VLAN'ing on top of loopback results in a
      netdevice which reports IFF_LOOPBACK but really isn't the loopback
      device.
      
      Instead of spamming the ipv6 routing code with even more special tests,
      simply disallow VLAN over loopback.
      
      The result of this patch is:
      
      # modprobe 8021q
      # vconfig add lo 43
      ERROR: trying to add VLAN #43 to IF -:lo:-  error: Operation not supported
      Signed-off-by: NKrishna Kumar <krkumar2@in.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0553c891
  4. 18 2月, 2011 1 次提交
  5. 06 10月, 2010 1 次提交
    • E
      net: add a core netdev->rx_dropped counter · caf586e5
      Eric Dumazet 提交于
      In various situations, a device provides a packet to our stack and we
      drop it before it enters protocol stack :
      - softnet backlog full (accounted in /proc/net/softnet_stat)
      - bad vlan tag (not accounted)
      - unknown/unregistered protocol (not accounted)
      
      We can handle a per-device counter of such dropped frames at core level,
      and automatically adds it to the device provided stats (rx_dropped), so
      that standard tools can be used (ifconfig, ip link, cat /proc/net/dev)
      
      This is a generalization of commit 8990f468 (net: rx_dropped
      accounting), thus reverting it.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      caf586e5
  6. 27 9月, 2010 1 次提交
  7. 08 7月, 2010 1 次提交
    • E
      net: fix 64 bit counters on 32 bit arches · 28172739
      Eric Dumazet 提交于
      There is a small possibility that a reader gets incorrect values on 32
      bit arches. SNMP applications could catch incorrect counters when a
      32bit high part is changed by another stats consumer/provider.
      
      One way to solve this is to add a rtnl_link_stats64 param to all
      ndo_get_stats64() methods, and also add such a parameter to
      dev_get_stats().
      
      Rule is that we are not allowed to use dev->stats64 as a temporary
      storage for 64bit stats, but a caller provided area (usually on stack)
      
      Old drivers (only providing get_stats() method) need no changes.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28172739
  8. 26 6月, 2010 1 次提交
  9. 15 6月, 2010 1 次提交
  10. 17 2月, 2010 1 次提交
  11. 02 12月, 2009 1 次提交
  12. 26 11月, 2009 1 次提交
  13. 03 10月, 2009 1 次提交
  14. 01 9月, 2009 1 次提交
  15. 06 7月, 2009 1 次提交
  16. 19 5月, 2009 1 次提交
    • E
      net: release dst entry in dev_hard_start_xmit() · 93f154b5
      Eric Dumazet 提交于
      One point of contention in high network loads is the dst_release() performed
      when a transmited skb is freed. This is because NIC tx completion calls
      dev_kree_skb() long after original call to dev_queue_xmit(skb).
      
      CPU cache is cold and the atomic op in dst_release() stalls. On SMP, this is
      quite visible if one CPU is 100% handling softirqs for a network device,
      since dst_clone() is done by other cpus, involving cache line ping pongs.
      
      It seems right place to release dst is in dev_hard_start_xmit(), for most
      devices but ones that are virtual, and some exceptions.
      
      David Miller suggested to define a new device flag, set in alloc_netdev_mq()
      (so that most devices set it at init time), and carefuly unset in devices
      which dont want a NULL skb->dst in their ndo_start_xmit().
      
      List of devices that must clear this flag is :
      
      - loopback device, because it calls netif_rx() and quoting Patrick :
          "ip_route_input() doesn't accept loopback addresses, so loopback packets
           already need to have a dst_entry attached."
      - appletalk/ipddp.c : needs skb->dst in its xmit function
      
      - And all devices that call again dev_queue_xmit() from their xmit function
      (as some classifiers need skb->dst) : bonding, vlan, macvlan, eql, ifb, hdlc_fr
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93f154b5
  17. 20 4月, 2009 1 次提交
    • E
      loopback: packet drops accounting · 7eebb0b2
      Eric Dumazet 提交于
      We can in some situations drop packets in netif_rx()
      
      loopback driver does not report these (unlikely) drops to its stats,
      and incorrectly change packets/bytes counts.
      
      After this patch applied, "ifconfig lo" can reports these drops as in :
      
      # ifconfig lo
      lo        Link encap:Local Loopback
                inet addr:127.0.0.1  Mask:255.0.0.0
                UP LOOPBACK RUNNING  MTU:16436  Metric:1
                RX packets:692562900 errors:3228 dropped:3228 overruns:0 frame:0
                TX packets:692562900 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:0
                RX bytes:2865674174 (2.6 GiB)  TX bytes:2865674174 (2.6 GiB)
      
      I initialy chose to reflect those errors only in tx_dropped/tx_errors, but David
      convinced me that it was really RX errors, as loopback_xmit() really starts
      a RX process. (calling eth_type_trans() for example, that itself pulls the ethernet header)
      
      These errors are accounted in rx_dropped/rx_errors.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7eebb0b2
  18. 21 11月, 2008 1 次提交
  19. 20 11月, 2008 1 次提交
  20. 08 11月, 2008 2 次提交
  21. 06 11月, 2008 1 次提交
    • E
      net: Guaranetee the proper ordering of the loopback device. · ae33bc40
      Eric W. Biederman 提交于
      I was recently hunting a bug that occurred in network namespace
      cleanup.  In looking at the code it became apparrent that we have
      and will continue to have cases where if we have anything going
      on in a network namespace there will be assumptions that the
      loopback device is present.   Things like sending igmp unsubscribe
      messages when we bring down network devices invokes the routing
      code which assumes that at least the loopback driver is present.
      
      Therefore to avoid magic initcall ordering hackery that is hard
      to follow and hard to get right insert a call to register the
      loopback device directly from net_dev_init().    This guarantes
      that the loopback device is the first device registered and
      the last network device to go away.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae33bc40
  22. 04 11月, 2008 1 次提交
  23. 31 10月, 2008 1 次提交
  24. 16 8月, 2008 3 次提交
  25. 18 7月, 2008 1 次提交
  26. 26 3月, 2008 1 次提交
  27. 29 1月, 2008 1 次提交
  28. 13 1月, 2008 1 次提交
  29. 13 11月, 2007 1 次提交
  30. 27 10月, 2007 1 次提交
    • E
      [NET]: Marking struct pernet_operations __net_initdata was inappropriate · 2b008b0a
      Eric W. Biederman 提交于
      It is not safe to to place struct pernet_operations in a special section.
      We need struct pernet_operations to last until we call unregister_pernet_subsys.
      Which doesn't happen until module unload.
      
      So marking struct pernet_operations is a disaster for modules in two ways.
      - We discard it before we call the exit method it points to.
      - Because I keep struct pernet_operations on a linked list discarding
        it for compiled in code removes elements in the middle of a linked
        list and does horrible things for linked insert.
      
      So this looks safe assuming __exit_refok is not discarded
      for modules.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b008b0a
  31. 16 10月, 2007 1 次提交
  32. 11 10月, 2007 6 次提交
新手
引导
客服 返回
顶部