1. 26 4月, 2007 17 次提交
  2. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  3. 11 2月, 2007 1 次提交
  4. 26 1月, 2007 1 次提交
  5. 09 12月, 2006 1 次提交
  6. 04 12月, 2006 1 次提交
  7. 03 12月, 2006 6 次提交
  8. 29 9月, 2006 2 次提交
  9. 23 9月, 2006 4 次提交
  10. 01 9月, 2006 1 次提交
    • W
      [IPV4]: Fix SNMPv2 "ipFragFails" counter error · 0668b472
      Wei Dong 提交于
        When I tested Linux kernel 2.6.17.7 about statistics
      "ipFragFails",found that this counter couldn't increase correctly. The
      criteria is RFC2011:
      RFC2011
        ipFragFails OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
                  "The number of IP datagrams that have been discarded because
                  they needed to be fragmented at this entity but could not
                  be, e.g., because their Don't Fragment flag was set."
          ::= { ip 18 }
      
      When I send big IP packet to a router with DF bit set to 1 which need to
      be fragmented, and router just sends an ICMP error message
      ICMP_FRAG_NEEDED but no increments for this counter(in the function
      ip_fragment).
      Signed-off-by: NWei Dong <weid@nanjing-fnst.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0668b472
  11. 14 8月, 2006 1 次提交
    • H
      [INET]: Use pskb_trim_unique when trimming paged unique skbs · e9fa4f7b
      Herbert Xu 提交于
      The IPv4/IPv6 datagram output path was using skb_trim to trim paged
      packets because they know that the packet has not been cloned yet
      (since the packet hasn't been given to anything else in the system).
      
      This broke because skb_trim no longer allows paged packets to be
      trimmed.  Paged packets must be given to one of the pskb_trim functions
      instead.
      
      This patch adds a new pskb_trim_unique function to cover the IPv4/IPv6
      datagram output path scenario and replaces the corresponding skb_trim
      calls with it.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9fa4f7b
  12. 03 8月, 2006 1 次提交
    • W
      [IPV6]: SNMPv2 "ipv6IfStatsOutFragCreates" counter error · dafee490
      Wei Dong 提交于
        When I tested linux kernel 2.6.71.7 about statistics
      "ipv6IfStatsOutFragCreates", and found that it couldn't increase
      correctly. The criteria is RFC 2465:
      
        ipv6IfStatsOutFragCreates OBJECT-TYPE
            SYNTAX      Counter32
            MAX-ACCESS  read-only
            STATUS      current
            DESCRIPTION
               "The number of output datagram fragments that have
               been generated as a result of fragmentation at
               this output interface."
            ::= { ipv6IfStatsEntry 15 }
      
      I think there are two issues in Linux kernel. 
      1st:
      RFC2465 specifies the counter is "The number of output datagram
      fragments...". I think increasing this counter after output a fragment
      successfully is better. And it should not be increased even though a
      fragment is created but failed to output.
      
      2nd:
      If we send a big ICMP/ICMPv6 echo request to a host, and receive
      ICMP/ICMPv6 echo reply consisted of some fragments. As we know that in
      Linux kernel first fragmentation occurs in ICMP layer(maybe saying
      transport layer is better), but this is not the "real"
      fragmentation,just do some "pre-fragment" -- allocate space for date,
      and form a frag_list, etc. The "real" fragmentation happens in IP layer
      -- set offset and MF flag and so on. So I think in "fast path" for
      ip_fragment/ip6_fragment, if we send a fragment which "pre-fragment" by
      upper layer we should also increase "ipv6IfStatsOutFragCreates".
      Signed-off-by: NWei Dong <weid@nanjing-fnst.com>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dafee490
  13. 09 7月, 2006 1 次提交
  14. 01 7月, 2006 2 次提交
    • H
      [IPV6]: Added GSO support for TCPv6 · f83ef8c0
      Herbert Xu 提交于
      This patch adds GSO support for IPv6 and TCPv6.  This is based on a patch
      by Ananda Raju <Ananda.Raju@neterion.com>.  His original description is:
      
      	This patch enables TSO over IPv6. Currently Linux network stacks
      	restricts TSO over IPv6 by clearing of the NETIF_F_TSO bit from
      	"dev->features". This patch will remove this restriction.
      
      	This patch will introduce a new flag NETIF_F_TSO6 which will be used
      	to check whether device supports TSO over IPv6. If device support TSO
      	over IPv6 then we don't clear of NETIF_F_TSO and which will make the
      	TCP layer to create TSO packets. Any device supporting TSO over IPv6
      	will set NETIF_F_TSO6 flag in "dev->features" along with NETIF_F_TSO.
      
      	In case when user disables TSO using ethtool, NETIF_F_TSO will get
      	cleared from "dev->features". So even if we have NETIF_F_TSO6 we don't
      	get TSO packets created by TCP layer.
      
      	SKB_GSO_TCPV4 renamed to SKB_GSO_TCP to make it generic GSO packet.
      	SKB_GSO_UDPV4 renamed to SKB_GSO_UDP as UFO is not a IPv4 feature.
      	UFO is supported over IPv6 also
      
      	The following table shows there is significant improvement in
      	throughput with normal frames and CPU usage for both normal and jumbo.
      
      	--------------------------------------------------
      	|          |     1500        |      9600         |
      	|          ------------------|-------------------|
      	|          | thru     CPU    |  thru     CPU     |
      	--------------------------------------------------
      	| TSO OFF  | 2.00   5.5% id  |  5.66   20.0% id  |
      	--------------------------------------------------
      	| TSO ON   | 2.63   78.0 id  |  5.67   39.0% id  |
      	--------------------------------------------------
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f83ef8c0
    • J
      Remove obsolete #include <linux/config.h> · 6ab3d562
      Jörn Engel 提交于
      Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      6ab3d562