| To: | Harald Welte <laforge@xxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH 2.4] backport neighbour cache redesign |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Mon, 4 Oct 2004 14:16:51 -0700 |
| Cc: | netdev@xxxxxxxxxxx |
| In-reply-to: | <20041004211158.GG27499@xxxxxxxxxxxxxxxxxxxxxxx> |
| References: | <20040930154753.GD1860@xxxxxxxxxxxxxxxxxxxxxxx> <20041004121759.26798f1d.davem@xxxxxxxxxxxxx> <20041004201525.GF27499@xxxxxxxxxxxxxxxxxxxxxxx> <20041004132034.00cfe23c.davem@xxxxxxxxxxxxx> <20041004211158.GG27499@xxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Mon, 4 Oct 2004 23:11:58 +0200 Harald Welte <laforge@xxxxxxxxxxxx> wrote: > yes, I remember that email. I didn't think further about it, since I > got the feeling that there is significant movement to get rid of the > neighbour cache at some point (if/when there is some fast lookup > algorithm implemented) - and if we look at ipv6, there is no routing > cache. Another idea is to dynamically grow the thresholds based upon usage just as we do for the hash tables. For example, if we find say %90 of neighbour entries in-use at forced GC time, we increment the thresholds by some factor. Note that the "in-use" part is very important, it prevents a DoS spam from growing the neighbour cache since such traffic causes neighbour entries to quickly become unused. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 2.4] backport neighbour cache redesign, Harald Welte |
|---|---|
| Next by Date: | [BK PATCHES] 2.6.x net driver fixes, Jeff Garzik |
| Previous by Thread: | Re: [PATCH 2.4] backport neighbour cache redesign, Harald Welte |
| Next by Thread: | [PATCH 2.6.9-rc3-mm2 1/5] r8169: Tx timeout rework, Francois Romieu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |