linux-toradex.git/net/decnet/dn_neigh.c, branch v3.13.7

net: proc: change proc_net_remove to remove_proc_entry

2013-02-18T19:53:08+00:00

proc_net_remove is only used to remove proc entries
that under /proc/net,it's not a general function for
removing proc entries of netns. if we want to remove
some proc entries which under /proc/net/stat/, we still
need to call remove_proc_entry.

this patch use remove_proc_entry to replace proc_net_remove.
we can remove proc_net_remove after this patch.

Signed-off-by: Gao feng 
Signed-off-by: David S. Miller

net: proc: change proc_net_fops_create to proc_create

2013-02-18T19:53:08+00:00

Right now, some modules such as bonding use proc_create
to create proc entries under /proc/net/, and other modules
such as ipv4 use proc_net_fops_create.

It looks a little chaos.this patch changes all of
proc_net_fops_create to proc_create. we can remove
proc_net_fops_create after this patch.

Signed-off-by: Gao feng 
Signed-off-by: David S. Miller

net neighbour, decnet: Ensure to align device private data on preferred alignment.

2013-02-11T05:21:44+00:00

To allow both of protocol-specific data and device-specific data
attached with neighbour entry, and to eliminate size calculation
cost when allocating entry, sizeof protocol-speicic data must be
multiple of NEIGH_PRIV_ALIGN.  On 64bit archs,
sizeof(struct dn_neigh) is multiple of NEIGH_PRIV_ALIGN, but on
32bit archs, it was not.

Introduce NEIGH_ENTRY_SPACE() macro to ensure that protocol-specific
entry-size meets our requirement.

Reported-by: Fengguang Wu 
Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller

decnet: Use neighbours privately in dn_route struct.

2012-07-05T08:12:14+00:00

This allows an easy conversion away from dst_get_neighbour*().

Signed-off-by: David S. Miller

net: use consume_skb() in place of kfree_skb()

2012-06-04T15:27:40+00:00

Remove some dropwatch/drop_monitor false positives.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

net: Convert net_ratelimit uses to net__ratelimited

2012-05-15T17:45:03+00:00

Standardize the net core ratelimited logging functions.

Coalesce formats, align arguments.
Change a printk then vprintk sequence to use printf extension %pV.

Signed-off-by: Joe Perches 
Signed-off-by: David S. Miller

decnet: Add missing neigh->ha locking to dn_neigh_output_packet()

2012-02-01T21:34:25+00:00

Basically, mirror the logic in neigh_connected_output().

Signed-off-by: David S. Miller

ipv6: Use universal hash for NDISC.

2011-12-28T20:06:58+00:00

In order to perform a proper universal hash on a vector of integers,
we have to use different universal hashes on each vector element.

Which means we need 4 different hash randoms for ipv6.

Signed-off-by: David S. Miller

net: Rename dst_get_neighbour{, _raw} to dst_get_neighbour_noref{, _raw}.

2011-12-05T20:20:19+00:00

To reflect the fact that a refrence is not obtained to the
resulting neighbour entry.

Signed-off-by: David S. Miller 
Acked-by: Roland Dreier

neigh: new unresolved queue limits

2011-11-14T05:47:54+00:00

Le mercredi 09 novembre 2011 à 16:21 -0500, David Miller a écrit :
> From: David Miller 
> Date: Wed, 09 Nov 2011 16:16:44 -0500 (EST)
>
> > From: Eric Dumazet 
> > 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