1. 03 8月, 2006 9 次提交
  2. 26 7月, 2006 1 次提交
  3. 25 7月, 2006 2 次提交
  4. 22 7月, 2006 2 次提交
  5. 13 7月, 2006 3 次提交
  6. 09 7月, 2006 2 次提交
  7. 04 7月, 2006 3 次提交
  8. 01 7月, 2006 4 次提交
  9. 30 6月, 2006 3 次提交
  10. 28 6月, 2006 1 次提交
  11. 23 6月, 2006 4 次提交
    • H
      [IPSEC]: Handle GSO packets · 09b8f7a9
      Herbert Xu 提交于
      This patch segments GSO packets received by the IPsec stack.  This can
      happen when a NIC driver injects GSO packets into the stack which are
      then forwarded to another host.
      
      The primary application of this is going to be Xen where its backend
      driver may inject GSO packets into dom0.
      
      Of course this also can be used by other virtualisation schemes such as
      VMWare or UML since the tap device could be modified to inject GSO packets
      received through splice.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      09b8f7a9
    • H
      [NET]: Merge TSO/UFO fields in sk_buff · 7967168c
      Herbert Xu 提交于
      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
      field.
      
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7967168c
    • Y
      [IPV6] ADDRCONF: Fix default source address selection without CONFIG_IPV6_PRIVACY · 5e2707fa
      YOSHIFUJI Hideaki 提交于
      We need to update hiscore.rule even if we don't enable CONFIG_IPV6_PRIVACY,
      because we have more less significant rule; longest match.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5e2707fa
    • Ł
      [IPV6]: Fix source address selection. · 102128e3
      Łukasz Stelmach 提交于
      Two additional labels (RFC 3484, sec. 10.3) for IPv6 addreses
      are defined to make a distinction between global unicast
      addresses and Unique Local Addresses (fc00::/7, RFC 4193) and
      Teredo (2001::/32, RFC 4380). It is necessary to avoid attempts
      of connection that would either fail (eg. fec0:: to 2001:feed::)
      or be sub-optimal (2001:0:: to 2001:feed::).
      Signed-off-by: NŁukasz Stelmach <stlman@poczta.fm>
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      102128e3
  12. 18 6月, 2006 6 次提交