Search String: Display: Description: Sort:

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.

281. Re: Route cache performance under stress (score: 1)
Author: Ralph Doncaster <ralph@xxxxxxxxx>
Date: Tue, 10 Jun 2003 13:33:01 -0400 (EDT)
That sounds good. Is there a sysctl I can use to define "certain level"? -Ralph
/archives/netdev/2003-06/msg01196.html (12,042 bytes)

282. Re: Route cache performance under stress (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Tue, 10 Jun 2003 11:21:50 -0700
One waring about e1000's, make sure you have active airflow across the NICs if you put two together. Otherwise, buy a dual port NIC...it has a single chip and you will have less cooling issues. I ju
/archives/netdev/2003-06/msg01197.html (12,870 bytes)

283. Re: Route cache performance under stress (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Tue, 10 Jun 2003 20:34:50 +0200
Dave! I ripped out the route hash just to test the slow path. Seems like your patch was very good as we see the same performance w/o dst hash ~114 kpps. So my test system drops from 450 kpps to 114 k
/archives/netdev/2003-06/msg01198.html (15,402 bytes)

284. Re: Route cache performance under stress (score: 1)
Author: Florian Weimer <fw@xxxxxxxxxxxxx>
Date: Tue, 10 Jun 2003 20:41:00 +0200
Unfortunately, compromised hosts do send such traffic, and DoS victims receive it. 8-( You don't want your core routers to break down just because a couple of the 150,000 hosts in your regional netwo
/archives/netdev/2003-06/msg01199.html (13,417 bytes)

285. Re: Route cache performance under stress (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 10 Jun 2003 11:57:59 -0700 (PDT)
How did you "rip it out"? Just never look into the routing cache hash and never add entries there? If so, then yes it is excellent simulation for pure slow path. This is not purely an algorithmic pro
/archives/netdev/2003-06/msg01200.html (11,096 bytes)

286. Re: Route cache performance under stress (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Tue, 10 Jun 2003 21:53:33 +0200
Look at the patch... hash lookup is bypassed -> always slow path. no lookup in rt_intern_hash but we keep the entry in the hash and ip_rt_dst_alloc is changed to run do __rt_hash_shrink for each call
/archives/netdev/2003-06/msg01203.html (11,588 bytes)

287. RE: Route cache performance under stress (score: 1)
Author: "CIT/Paul" <xerox@xxxxxxxxxx>
Date: Tue, 10 Jun 2003 17:36:14 -0400
Why do you need source validation if we are going to use it for a core router :) Is there anything else in there that may or may not be necessary depending on the circumstances that we are using the
/archives/netdev/2003-06/msg01207.html (11,589 bytes)

288. Re: Route cache performance under stress (score: 1)
Author: Ralph Doncaster <ralph@xxxxxxxxx>
Date: Tue, 10 Jun 2003 17:39:44 -0400 (EDT)
Looking at Simon's profile numbers, these seem to contribute a lot more than fib_validate_source: 1237 ipt_route_hook 19.3281 3120 do_gettimeofday 21.6667 8299 ip_packet_match 24.6994 8031 fib_lookup
/archives/netdev/2003-06/msg01208.html (12,415 bytes)

289. Re: Route cache performance under stress (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 10 Jun 2003 15:20:20 -0700 (PDT)
Ignore all the fib_rule*() and associated overhead, Simon is going to turn of policy routing support so that stuff drops out of the profiles. The fib_lookup() will decrease significantly from the pro
/archives/netdev/2003-06/msg01209.html (11,745 bytes)

290. Re: Route cache performance under stress (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 10 Jun 2003 16:57:59 -0700 (PDT)
I'm not aware of anything in IP routing that requires a timestamp for every packet. To me it sounds like we could rip that out too. Guess you never run tcpdump nor use packet schedulers.
/archives/netdev/2003-06/msg01213.html (10,792 bytes)

291. Re: Route cache performance under stress (score: 1)
Author: Ralph Doncaster <ralph@xxxxxxxxx>
Date: Tue, 10 Jun 2003 19:58:47 -0400 (EDT)
I'm not aware of anything in IP routing that requires a timestamp for every packet. To me it sounds like we could rip that out too. -Ralph
/archives/netdev/2003-06/msg01214.html (11,603 bytes)

292. Re: Route cache performance under stress (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Tue, 10 Jun 2003 17:51:57 -0700
Every packet records a timestamp. I'm not aware of anything in IP routing that requires a timestamp for every packet. To me it sounds like we could rip that out too. -Ralph Maybe as a configurable op
/archives/netdev/2003-06/msg01215.html (13,210 bytes)

293. Re: Route cache performance under stress (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 10 Jun 2003 17:58:54 -0700 (PDT)
From: Ralph Doncaster <ralph@xxxxxxxxx> Date: Tue, 10 Jun 2003 20:41:13 -0400 (EDT) This sounded so unbelievable to me that I took a quick look at the code to see what I'd have to do to get rid of it
/archives/netdev/2003-06/msg01216.html (10,924 bytes)

294. Re: Route cache performance under stress (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 10 Jun 2003 17:58:13 -0700 (PDT)
So because some (in the case of a core router almost none) of the packets will need a timestamp, you do it for every single one of them? In order to be accurate, we must obtain the timestamp exactly
/archives/netdev/2003-06/msg01217.html (11,206 bytes)

295. Re: Route cache performance under stress (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 10 Jun 2003 18:01:20 -0700 (PDT)
From: Ben Greear <greearb@xxxxxxxxxxxxxxx> Date: Tue, 10 Jun 2003 17:51:57 -0700 Maybe as a configurable option, since it would make tcpdump less useful. Seems like we could kludge it up so that we u
/archives/netdev/2003-06/msg01218.html (11,465 bytes)

296. Re: Route cache performance under stress (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Tue, 10 Jun 2003 18:15:36 -0700
David S. Miller wrote: From: Ben Greear <greearb@xxxxxxxxxxxxxxx> Date: Tue, 10 Jun 2003 17:51:57 -0700 Maybe as a configurable option, since it would make tcpdump less useful. Seems like we could kl
/archives/netdev/2003-06/msg01219.html (12,891 bytes)

297. Re: Route cache performance under stress (score: 1)
Author: Ralph Doncaster <ralph@xxxxxxxxx>
Date: Tue, 10 Jun 2003 20:41:13 -0400 (EDT)
So because some (in the case of a core router almost none) of the packets will need a timestamp, you do it for every single one of them? This sounded so unbelievable to me that I took a quick look at
/archives/netdev/2003-06/msg01220.html (12,278 bytes)

298. Re: Route cache performance under stress (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 10 Jun 2003 18:22:34 -0700 (PDT)
From: Ben Greear <greearb@xxxxxxxxxxxxxxx> Date: Tue, 10 Jun 2003 18:15:36 -0700 What determines whether or not we use the "TSC do_gettimeofday". Does it automagically happen when you compile for P-I
/archives/netdev/2003-06/msg01221.html (10,845 bytes)

299. Re: Route cache performance under stress (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Tue, 10 Jun 2003 18:23:38 -0700 (PDT)
Aren't the read_lock_irqsave and restore expensive? If x86 has an inefficient implementation, well... :-) This can be done without locks, nobody has done the x86 implementation of that that's all. I
/archives/netdev/2003-06/msg01222.html (10,879 bytes)

300. Re: Route cache performance under stress (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Tue, 10 Jun 2003 18:51:17 -0700
Do we know when we are being asked for this value? We have to take the timestamp at netif_receive_skb() for it to be accurate. We don't even know if this packet is for this host until a long time la
/archives/netdev/2003-06/msg01223.html (11,965 bytes)

Current List: 281 - 300
Page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]
This search system is powered by Namazu