mirror of
https://github.com/torvalds/linux.git
synced 2024-12-01 00:21:32 +00:00
8b5c171bb3
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: David S. Miller <davem@davemloft.net> |
||
---|---|---|
.. | ||
netfilter | ||
af_decnet.c | ||
dn_dev.c | ||
dn_fib.c | ||
dn_neigh.c | ||
dn_nsp_in.c | ||
dn_nsp_out.c | ||
dn_route.c | ||
dn_rules.c | ||
dn_table.c | ||
dn_timer.c | ||
Kconfig | ||
Makefile | ||
README | ||
sysctl_net_decnet.c | ||
TODO |
Linux DECnet Project ====================== The documentation for this kernel subsystem is available in the Documentation/networking subdirectory of this distribution and also on line at http://www.chygwyn.com/DECnet/ Steve Whitehouse <SteveW@ACM.org>