Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Route\s+cache\s+performance\s+under\s+stress\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Route\s+cache\s+performance\s+under\s+stress\s*$/: 364 ]

Total 364 documents matching your query.

181. Re: Route cache performance under stress (score: 1): Author: avem@xxxxxxxxxx>; Date: Mon, 26 May 2003 00:29:34 -0700 (PDT); From: Florian Weimer <fw@xxxxxxxxxxxxx> Date: Mon, 26 May 2003 09:18:19 +0200 Cisco IOS doesn't have this hash collisions problem, they have moved away from hash tables ages ago. Let their loss be ou; /archives/netdev/2003-05/msg00320.html (11,039 bytes)
182. Re: Route cache performance under stress (score: 1): Author: xxxxxxxxxxxxx>; Date: Mon, 26 May 2003 11:29:02 +0200; The vc[] table is used to generate packets which don't fall victim to widely implemented source address checks (e.g. "ip verify unicast source reachable-via any" on recent Cisco routers). I've checke; /archives/netdev/2003-05/msg00322.html (10,675 bytes)
183. Re: Route cache performance under stress (score: 1): Author: davem@xxxxxxxxxx>; Date: Mon, 26 May 2003 11:34:37 +0200; Exactly, as a result you get stateless IP forwarding whose performance is mostly independent of the traffic characteristics. They do this for dCEF. In this case the CEF data structure are replicated; /archives/netdev/2003-05/msg00323.html (13,311 bytes)
184. Re: Route cache performance under stress (score: 1): Author: llwig <hch@xxxxxx>; Date: Mon, 26 May 2003 23:32:11 -0700 (PDT); From: Florian Weimer <fw@xxxxxxxxxxxxx> Date: Mon, 26 May 2003 11:34:37 +0200 Of course, this will result in vastly decreased functionality (no arbitary netmasks, no policy-based routing, code will b; /archives/netdev/2003-05/msg00329.html (9,909 bytes)
185. Re: Route cache performance under stress (score: 1): Author: fsson <gandalf@xxxxxxxxxxxxxx>; Date: Thu, 29 May 2003 13:51:25 -0700; Sorry for the delay -- I was away for a few days. Here are profile results from the same machine (still with XT-PIC), the same 300000 route entries, and your original patch that fixes the hashing. I; /archives/netdev/2003-05/msg00357.html (17,465 bytes)
186. Re: Route cache performance under stress (score: 1): Author: xxxx>; Date: 05 Apr 2003 20:17:09 +0200; It's correct that ip_conntrack has similar issues. There's been some work on the hashalgorithm used but no patch has been made yet. And yes it doesn't scale well at all (especially on SMP), I'm about; /archives/netdev/2003-04/msg00059.html (8,168 bytes)
187. Re: Route cache performance under stress (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Mon, 2 Jun 2003 12:58:31 +0200; 8896 rt_garbage_collect 9.4237 8959 ip_route_input_slow 3.8885 10516 dst_alloc 73.0278 10666 kmem_cache_free 66.6625 15339 tg3_rx 16.2489 16553 ipt_do_table 14.9937 20193 fn_hash_lookup 70.1146 26833; /archives/netdev/2003-06/msg00904.html (12,018 bytes)
188. Re: Route cache performance under stress (score: 1): Author: Simon Kirby <sim@xxxxxxxxxxxxx>; Date: Mon, 2 Jun 2003 08:18:52 -0700; ... This reminds me of the situation we experienced with the dst cache overflowing in early 2.2 kernels. This was a long time ago, when our traffic was only about 10 Mbits/second. We had recently upg; /archives/netdev/2003-06/msg00905.html (11,847 bytes)
189. Re: Route cache performance under stress (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Mon, 2 Jun 2003 18:36:37 +0200; We are given more work than we have resources for (max_size) what else than refuse can we do? But yes we have invested pretty much work already. Also remember we are looking into runs were 100% of in; /archives/netdev/2003-06/msg00906.html (11,563 bytes)
190. Re: Route cache performance under stress (score: 1): Author: Simon Kirby <sim@xxxxxxxxxxxxx>; Date: Mon, 2 Jun 2003 11:05:37 -0700; Well, this is the problem. We do not and cannot know which entries we really want to remember (legitimate traffic). Adding code to actually refuse new dst entries is just going to make the DoS effect; /archives/netdev/2003-06/msg00909.html (11,300 bytes)
191. Re: Route cache performance under stress (score: 1): Author: Florian Weimer <fw@xxxxxxxxxxxxx>; Date: Sun, 08 Jun 2003 13:39:49 +0200; Even non-CIDR netmasks? AFAIK, it's hard to find dedicated networking devices (and routing protocols!) which support them. 8-/ Anyway, I've played a bit with something inspired by CEF (more precisely; /archives/netdev/2003-06/msg01048.html (14,607 bytes)
192. Re: Route cache performance under stress (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Sun, 08 Jun 2003 05:05:00 -0700 (PDT); Even non-CIDR netmasks? AFAIK, it's hard to find dedicated networking devices (and routing protocols!) which support them. 8-/ Yes, people use source based routing to block specific IPs and subnets,; /archives/netdev/2003-06/msg01049.html (10,426 bytes)
193. Re: Route cache performance under stress (score: 1): Author: Florian Weimer <fw@xxxxxxxxxxxxx>; Date: Sun, 08 Jun 2003 15:10:25 +0200; Most things in this area are patented, and the patents are extremely fuzzy (e.g. policy-based routing with hierarchical sequence of decisions has been patented countless times). 8-( The branchless va; /archives/netdev/2003-06/msg01050.html (10,938 bytes)
194. Re: Route cache performance under stress (score: 1): Author: Pekka Savola <pekkas@xxxxxxxxxx>; Date: Sun, 8 Jun 2003 20:58:57 +0300 (EEST); Do you mean netmasks like "255.128.255.0" ? Those are a real abomination and probably not supported.. and I don't know of anything that would require them. Or do you mean netmasks such as 1.1.1.1/19?; /archives/netdev/2003-06/msg01052.html (9,554 bytes)
195. Re: Route cache performance under stress (score: 1): Author: Simon Kirby <sim@xxxxxxxxxxxxx>; Date: Sun, 8 Jun 2003 16:49:26 -0700; What is the problem with the current approach? Does the overhead come from having to iterate through the hashes for each prefix? Simon [ Simon Kirby ][ Network Operations ] [ sim@xxxxxxxxxxxxx ][ Net; /archives/netdev/2003-06/msg01053.html (10,676 bytes)
196. RE: Route cache performance under stress (score: 1): Author: "CIT/Paul" <xerox@xxxxxxxxxx>; Date: Sun, 8 Jun 2003 19:55:58 -0400; The problem with the route cache as it stands is that it adds every new packet that isn't in the route cache to the cache, say you have A denial of service attack going on, OR you just have millions; /archives/netdev/2003-06/msg01054.html (12,740 bytes)
197. RE: Route cache performance under stress (score: 1): Author: Jamal Hadi <hadi@xxxxxxxxxxxxxxxx>; Date: Sun, 8 Jun 2003 23:15:46 -0400 (EDT); foo have you tried the latest patches posted recently? get the latest kernel 2.5.x and try it out. BTW, i dont think it is true you can die with 10mbps. I was reading some emails where someone said i; /archives/netdev/2003-06/msg01057.html (14,980 bytes)
198. RE: Route cache performance under stress (score: 1): Author: "CIT/Paul" <xerox@xxxxxxxxxx>; Date: Mon, 9 Jun 2003 01:27:48 -0400; Ahah Jamal!! Yes I have tried.. It does absoutely nothing for the constant randomness of packets. It increases the overall distribution of the hash in the cache but it does nothing for the addition o; /archives/netdev/2003-06/msg01059.html (17,015 bytes)
199. Re: Route cache performance under stress (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Sun, 08 Jun 2003 22:38:25 -0700 (PDT); What is the problem with the current approach? Does the overhead come from having to iterate through the hashes for each prefix? It comes from doing the slow path, which actually had a bug (wouldn't; /archives/netdev/2003-06/msg01060.html (10,603 bytes)
200. Re: Route cache performance under stress (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxx>; Date: Sun, 08 Jun 2003 22:44:46 -0700 (PDT); The problem with the route cache as it stands is that it adds every new packet that isn't in the route cache to the cache, say you have A denial of service attack going on, OR you just have millions; /archives/netdev/2003-06/msg01061.html (11,832 bytes)

Current List: 181 - 200
Page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]