summaryrefslogtreecommitdiff
path: root/include/net/inetpeer.h
AgeCommit message (Collapse)AuthorFilesLines
2007-11-12[INET]: Use list_head-s in inetpeer.cPavel Emelyanov1-1/+1
The inetpeer.c tracks the LRU list of inet_perr-s, but makes it by hands. Use the list_head-s for this. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-10-20[IPV4] inet_peer: Group together avl_left, avl_right, v4daddr to speedup ↵Eric Dumazet1-3/+4
lookups on some CPUS Lot of routers/embedded devices still use CPUS with 16/32 bytes cache lines. (486, Pentium, ... PIII) It makes sense to group together fields used at lookup time so they fit in one cache line. This reduce cache footprint and speedup lookups. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-10-15[NET]: reduce sizeof(struct inet_peer), cleanup, change in peer_check_expire()Eric Dumazet1-15/+2
1) shrink struct inet_peer on 64 bits platforms.
2006-09-28[IPV4]: inetpeer annotationsAl Viro1-2/+2
This one is interesting - we use net-endian value as search key, but order the tree by *host-endian* comparisons of keys. OK since we only care about lookups. Annotated inet_getpeer() and friends. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-01-03[IPV4]: Safer reassemblyHerbert Xu1-0/+1
Another spin of Herbert Xu's "safer ip reassembly" patch for 2.6.16. (The original patch is here: http://marc.theaimsgroup.com/?l=linux-netdev&m=112281936522415&w=2 and my only contribution is to have tested it.) This patch (optionally) does additional checks before accepting IP fragments, which can greatly reduce the possibility of reassembling fragments which originated from different IP datagrams. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Arthur Kepner <akepner@sgi.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+66
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!