1. 02 12月, 2011 2 次提交
    • E
      ipv4: use a 64bit load/store in output path · 84f9307c
      Eric Dumazet 提交于
      gcc compiler is smart enough to use a single load/store if we
      memcpy(dptr, sptr, 8) on x86_64, regardless of
      CONFIG_CC_OPTIMIZE_FOR_SIZE
      
      In IP header, daddr immediately follows saddr, this wont change in the
      future. We only need to make sure our flowi4 (saddr,daddr) fields wont
      break the rule.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84f9307c
    • A
      dsa: Include linux/if_ether.h to fix build error · ea1f51be
      Axel Lin 提交于
      Include linux/if_ether.h to fix below build errors:
      
        CC      arch/arm/mach-kirkwood/common.o
      In file included from arch/arm/mach-kirkwood/common.c:19:
      include/net/dsa.h: In function 'dsa_uses_dsa_tags':
      include/net/dsa.h:192: error: 'ETH_P_DSA' undeclared (first use in this function)
      include/net/dsa.h:192: error: (Each undeclared identifier is reported only once
      include/net/dsa.h:192: error: for each function it appears in.)
      include/net/dsa.h: In function 'dsa_uses_trailer_tags':
      include/net/dsa.h:197: error: 'ETH_P_TRAILER' undeclared (first use in this function)
      make[1]: *** [arch/arm/mach-kirkwood/common.o] Error 1
      make: *** [arch/arm/mach-kirkwood] Error 2
      Signed-off-by: NAxel Lin <axel.lin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ea1f51be
  2. 01 12月, 2011 8 次提交
  3. 30 11月, 2011 1 次提交
    • E
      flow_dissector: use a 64bit load/store · 4d77d2b5
      Eric Dumazet 提交于
      Le lundi 28 novembre 2011 à 19:06 -0500, David Miller a écrit :
      > From: Dimitris Michailidis <dm@chelsio.com>
      > Date: Mon, 28 Nov 2011 08:25:39 -0800
      >
      > >> +bool skb_flow_dissect(const struct sk_buff *skb, struct flow_keys
      > >> *flow)
      > >> +{
      > >> +	int poff, nhoff = skb_network_offset(skb);
      > >> +	u8 ip_proto;
      > >> +	u16 proto = skb->protocol;
      > >
      > > __be16 instead of u16 for proto?
      >
      > I'll take care of this when I apply these patches.
      
      ( CC trimmed )
      
      Thanks David !
      
      Here is a small patch to use one 64bit load/store on x86_64 instead of
      two 32bit load/stores.
      
      [PATCH net-next] flow_dissector: use a 64bit load/store
      
      gcc compiler is smart enough to use a single load/store if we
      memcpy(dptr, sptr, 8) on x86_64, regardless of
      CONFIG_CC_OPTIMIZE_FOR_SIZE
      
      In IP header, daddr immediately follows saddr, this wont change in the
      future. We only need to make sure our flow_keys (src,dst) fields wont
      break the rule.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d77d2b5
  4. 29 11月, 2011 3 次提交
  5. 27 11月, 2011 5 次提交
  6. 24 11月, 2011 2 次提交
  7. 23 11月, 2011 3 次提交
  8. 22 11月, 2011 7 次提交
  9. 18 11月, 2011 1 次提交
  10. 17 11月, 2011 1 次提交
  11. 14 11月, 2011 3 次提交
    • E
      neigh: new unresolved queue limits · 8b5c171b
      Eric Dumazet 提交于
      Le mercredi 09 novembre 2011 à 16:21 -0500, David Miller a écrit :
      > From: David Miller <davem@davemloft.net>
      > Date: Wed, 09 Nov 2011 16:16:44 -0500 (EST)
      >
      > > From: Eric Dumazet <eric.dumazet@gmail.com>
      > > Date: Wed, 09 Nov 2011 12:14:09 +0100
      > >
      > >> unres_qlen is the number of frames we are able to queue per unresolved
      > >> neighbour. Its default value (3) was never changed and is responsible
      > >> for strange drops, especially if IP fragments are used, or multiple
      > >> sessions start in parallel. Even a single tcp flow can hit this limit.
      > >  ...
      > >
      > > Ok, I've applied this, let's see what happens :-)
      >
      > Early answer, build fails.
      >
      > Please test build this patch with DECNET enabled and resubmit.  The
      > decnet neigh layer still refers to the removed ->queue_len member.
      >
      > Thanks.
      
      Ouch, this was fixed on one machine yesterday, but not the other one I
      used this morning, sorry.
      
      [PATCH V5 net-next] neigh: new unresolved queue limits
      
      unres_qlen is the number of frames we are able to queue per unresolved
      neighbour. Its default value (3) was never changed and is responsible
      for strange drops, especially if IP fragments are used, or multiple
      sessions start in parallel. Even a single tcp flow can hit this limit.
      
      $ arp -d 192.168.20.108 ; ping -c 2 -s 8000 192.168.20.108
      PING 192.168.20.108 (192.168.20.108) 8000(8028) bytes of data.
      8008 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.322 ms
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b5c171b
    • A
      6LoWPAN: add fragmentation support · 719269af
      alex.bluesman.smirnov@gmail.com 提交于
      This patch adds support for frame fragmentation.
      Signed-off-by: NAlexander Smirnov <alex.bluesman.smirnov@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      719269af
    • E
      ipv6: reduce percpu needs for icmpv6msg mibs · 2a24444f
      Eric Dumazet 提交于
      Reading /proc/net/snmp6 on a machine with a lot of cpus is very
      expensive (can be ~88000 us).
      
      This is because ICMPV6MSG MIB uses 4096 bytes per cpu, and folding
      values for all possible cpus can read 16 Mbytes of memory (32MBytes on
      non x86 arches)
      
      ICMP messages are not considered as fast path on a typical server, and
      eventually few cpus handle them anyway. We can afford an atomic
      operation instead of using percpu data.
      
      This saves 4096 bytes per cpu and per network namespace.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2a24444f
  12. 12 11月, 2011 4 次提交