• Eric Dumazet's avatar
    neigh: new unresolved queue limits · 8b5c171b
    Eric Dumazet authored
    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: default avatarDavid S. Miller <davem@davemloft.net>
    8b5c171b
clip.c 24.1 KB