1. 02 Dec, 2006 6 commits
  2. 28 Sep, 2006 2 commits
  3. 22 Sep, 2006 4 commits
  4. 31 Aug, 2006 1 commit
    • Wei Dong's avatar
      [IPV4]: Fix SNMPv2 "ipFragFails" counter error · 0668b472
      Wei Dong authored
        When I tested Linux kernel about statistics
      "ipFragFails",found that this counter couldn't increase correctly. The
      criteria is RFC2011:
        ipFragFails OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
                  "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
      Signed-off-by: default avatarWei Dong <weid@nanjing-fnst.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  5. 13 Aug, 2006 1 commit
    • Herbert Xu's avatar
      [INET]: Use pskb_trim_unique when trimming paged unique skbs · e9fa4f7b
      Herbert Xu authored
      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
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  6. 02 Aug, 2006 1 commit
    • Wei Dong's avatar
      [IPV6]: SNMPv2 "ipv6IfStatsOutFragCreates" counter error · dafee490
      Wei Dong authored
        When I tested linux kernel 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
               "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. 
      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.
      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: default avatarWei Dong <weid@nanjing-fnst.com>
      Acked-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  7. 08 Jul, 2006 1 commit
  8. 30 Jun, 2006 2 commits
    • Herbert Xu's avatar
      [IPV6]: Added GSO support for TCPv6 · f83ef8c0
      Herbert Xu authored
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Jörn Engel's avatar
  9. 23 Jun, 2006 1 commit
    • Herbert Xu's avatar
      [NET]: Merge TSO/UFO fields in sk_buff · 7967168c
      Herbert Xu authored
      Having separate fields in sk_buff for TSO/UFO (tso_size/ufo_size) is not
      going to scale if we add any more segmentation methods (e.g., DCCP).  So
      let's merge them.
      They were used to tell the protocol of a packet.  This function has been
      subsumed by the new gso_type field.  This is essentially a set of netdev
      feature bits (shifted by 16 bits) that are required to process a specific
      skb.  As such it's easy to tell whether a given device can process a GSO
      skb: you just have to and the gso_type field and the netdev's features
      I've made gso_type a conjunction.  The idea is that you have a base type
      (e.g., SKB_GSO_TCPV4) that can be modified further to support new features.
      For example, if we add a hardware TSO type that supports ECN, they would
      declare NETIF_F_TSO | NETIF_F_TSO_ECN.  All TSO packets with CWR set would
      have a gso_type of SKB_GSO_TCPV4 | SKB_GSO_TCPV4_ECN while all other TSO
      packets would be SKB_GSO_TCPV4.  This means that only the CWR packets need
      to be emulated in software.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 17 Jun, 2006 2 commits
  11. 14 Apr, 2006 1 commit
  12. 09 Apr, 2006 1 commit
  13. 22 Mar, 2006 1 commit
  14. 12 Mar, 2006 1 commit
  15. 15 Feb, 2006 1 commit
    • Patrick McHardy's avatar
      [XFRM]: Fix SNAT-related crash in xfrm4_output_finish · 48d5cad8
      Patrick McHardy authored
      When a packet matching an IPsec policy is SNATed so it doesn't match any
      policy anymore it looses its xfrm bundle, which makes xfrm4_output_finish
      crash because of a NULL pointer dereference.
      This patch directs these packets to the original output path instead. Since
      the packets have already passed the POST_ROUTING hook, but need to start at
      the beginning of the original output path which includes another
      POST_ROUTING invocation, a flag is added to the IPCB to indicate that the
      packet was rerouted and doesn't need to pass the POST_ROUTING hook again.
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  16. 09 Jan, 2006 1 commit
  17. 07 Jan, 2006 2 commits
  18. 06 Jan, 2006 1 commit
  19. 05 Jan, 2006 1 commit
  20. 03 Jan, 2006 1 commit
  21. 29 Nov, 2005 1 commit
  22. 08 Nov, 2005 2 commits
  23. 28 Oct, 2005 1 commit
    • Ananda Raju's avatar
      [IPv4/IPv6]: UFO Scatter-gather approach · e89e9cf5
      Ananda Raju authored
      Attached is kernel patch for UDP Fragmentation Offload (UFO) feature.
      1. This patch incorporate the review comments by Jeff Garzik.
      2. Renamed USO as UFO (UDP Fragmentation Offload)
      3. udp sendfile support with UFO
      This patches uses scatter-gather feature of skb to generate large UDP
      datagram. Below is a "how-to" on changes required in network device
      driver to use the UFO interface.
      UDP Fragmentation Offload (UFO) Interface:
      UFO is a feature wherein the Linux kernel network stack will offload the
      IP fragmentation functionality of large UDP datagram to hardware. This
      will reduce the overhead of stack in fragmenting the large UDP datagram to
      MTU sized packets
      1) Drivers indicate their capability of UFO using
      dev->features |= NETIF_F_UFO | NETIF_F_HW_CSUM | NETIF_F_SG
      NETIF_F_HW_CSUM is required for UFO over ipv6.
      2) UFO packet will be submitted for transmission using driver xmit routine.
      UFO packet will have a non-zero value for
      skb_shinfo(skb)->ufo_size will indicate the length of data part in each IP
      fragment going out of the adapter after IP fragmentation by hardware.
      skb->data will contain MAC/IP/UDP header and skb_shinfo(skb)->frags[]
      contains the data payload. The skb->ip_summed will be set to CHECKSUM_HW
      indicating that hardware has to do checksum calculation. Hardware should
      compute the UDP checksum of complete datagram and also ip header checksum of
      each fragmented IP packet.
      For IPV6 the UFO provides the fragment identification-id in
      skb_shinfo(skb)->ip6_frag_id. The adapter should use this ID for generating
      IPv6 fragments.
      Signed-off-by: default avatarAnanda Raju <ananda.raju@neterion.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (forwarded)
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@mandriva.com>
  24. 25 Oct, 2005 1 commit
  25. 22 Oct, 2005 1 commit
  26. 29 Aug, 2005 2 commits