Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*RFC\:\s+NAPI\s+packet\s+weighting\s+patch\s*$/: 240 ]

Total 240 documents matching your query.

221. RE: RFC: NAPI packet weighting patch (score: 1)
Author: "Leonid Grossman" <leonid.grossman@xxxxxxxxxxxx>
Date: Wed, 22 Jun 2005 15:42:30 -0700
This is very hw-dependent, since there are NICs that read descriptors in batches anyways - but the second argument below is compelling. We will play around with the s2io driver as well, there seem t
/archives/netdev/2005-06/msg01149.html (14,102 bytes)

222. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Thu, 23 Jun 2005 01:13:00 +0200
The computing time must be quite long to be really a win. You need to waste a few hundred cycles at least on a modern fast CPU. -Andi
/archives/netdev/2005-06/msg01150.html (10,632 bytes)

223. Re: RFC: NAPI packet weighting patch (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 22 Jun 2005 19:19:56 -0400 (EDT)
SKB allocation more than fits this requirement, and that is exactly what the RX descriptor replenishment will do. Even if SKB allocation was only half the necessary number of cycles for the prefetch
/archives/netdev/2005-06/msg01151.html (10,537 bytes)

224. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Thu, 23 Jun 2005 01:23:45 +0200
It shouldn't in theory. Unless they did something bad to the slab allocator again when I wasn't looking ;-) If it's too small then it might be left in the noise. -Andi
/archives/netdev/2005-06/msg01152.html (11,114 bytes)

225. Re: RFC: NAPI packet weighting patch (score: 1)
Author: P@xxxxxxxxxxxxxx
Date: Thu, 23 Jun 2005 09:56:30 +0100
Yes the copy is essentially free here as the data is already cached. As a data point, I went the whole hog and used buffer recycling in my essentially packet sniffing application. I.E. there are no
/archives/netdev/2005-06/msg01153.html (12,829 bytes)

226. Re: RFC: NAPI packet weighting patch (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Thu, 23 Jun 2005 08:14:11 -0400
For the fans of the e1000 (or even the tg3 deprived people), heres a patch which originated from David Mosberger that i played around (about 9 months back) - it will need some hand patching for the l
/archives/netdev/2005-06/msg01155.html (13,479 bytes)

227. Re: RFC: NAPI packet weighting patch (score: 1)
Author: David Mosberger <davidm@xxxxxxxxxxxxxxxxx>
Date: Thu, 23 Jun 2005 10:36:11 -0700
Jamal> For the fans of the e1000 (or even the tg3 deprived people), Jamal> heres a patch which originated from David Mosberger that i Jamal> played around (about 9 months back) - it will need some h
/archives/netdev/2005-06/msg01157.html (19,888 bytes)

228. RFC: NAPI packet weighting patch (score: 1)
Author: Mitch Williams <mitch.a.williams@xxxxxxxxx>
Date: Thu, 26 May 2005 14:36:22 -0700
The following patch (which applies to 2.6.12rc4) adds a new sysctl parameter called 'netdev_packet_weight'. This parameter controls how many backlog work units each RX packet is worth. With the param
/archives/netdev/2005-05/msg02356.html (14,948 bytes)

229. RFC: NAPI packet weighting patch (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Fri, 27 May 2005 10:21:11 +0200
Hello! Some comments below. You should be able to accomplish on per-device basis with dev->weight I kind of interesting area and complex as weight setting should consider coalicing etc.as we try find
/archives/netdev/2005-05/msg02390.html (10,282 bytes)

230. Re: RFC: NAPI packet weighting patch (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Fri, 27 May 2005 07:18:52 -0400
NAPI uses already using a Weighted Round robin scheduling scheme know as DRR. I am not sure providing a weight scale on the weight is enhancing anything. Did you try to just reduce the weight instead
/archives/netdev/2005-05/msg02397.html (9,929 bytes)

231. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Fri, 27 May 2005 08:50:55 -0700
Rather than weighting each packet differently, why not just reduce the upper bound on number of packets. There are several patches is in my 2.6.12-rc5-tcp3 that make this easier: -- http://developer.
/archives/netdev/2005-05/msg02419.html (14,365 bytes)

232. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Mitch Williams <mitch.a.williams@xxxxxxxxx>
Date: Fri, 27 May 2005 13:27:04 -0700
Stephen, Robert, and Jamal all replied to my original message, and all said approximately the same thing: "Why don't you just reduce the weight in the driver? It does the same thing." To which I repl
/archives/netdev/2005-05/msg02443.html (10,944 bytes)

233. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Fri, 27 May 2005 14:01:32 -0700
Why not just allow adjusting dev->weight via sysfs?
/archives/netdev/2005-05/msg02448.html (10,781 bytes)

234. Re: RFC: NAPI packet weighting patch (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Fri, 27 May 2005 20:56:26 -0400
I think that should be good enough - and i thought your patch already did this. Adding a shift to the weight in a _weighted_ RR algorithm does sound odd. cheers, jamal
/archives/netdev/2005-05/msg02464.html (10,187 bytes)

235. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Mitch Williams <mitch.a.williams@xxxxxxxxx>
Date: Tue, 31 May 2005 10:35:26 -0700
Stephen's patch only affects the weight for the backlog device. Exporting device. Which makes perfect sense. I'll work on getting this done and verifying performance this week. Expect a patch in a fe
/archives/netdev/2005-05/msg02532.html (10,934 bytes)

236. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Tue, 31 May 2005 10:40:11 -0700
Like this (untested) patch: Index: napi-sysfs/net/core/net-sysfs.c == -- napi-sysfs.orig/net/core/net-sysfs.c +++ napi-sysfs/net/core/net-sysfs.c @@ -184,6 +184,22 @@ static ssize_t store_tx_queue_le
/archives/netdev/2005-05/msg02533.html (11,558 bytes)

237. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Mitch Williams <mitch.a.williams@xxxxxxxxx>
Date: Tue, 31 May 2005 10:43:32 -0700
Gosh, you're making my life too easy. Thanks! I'll apply this, give it a spin, and let you know what I see. -Mitch
/archives/netdev/2005-05/msg02534.html (10,813 bytes)

238. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Jon Mason <jdmason@xxxxxxxxxx>
Date: Tue, 31 May 2005 17:07:54 -0500
It seems to me that the drivers should adjust dev->weight dependent on the media speed/duplexity of the current link. A 10Mbps link will be constantly re-enabling interrupts, as the incoming traffic
/archives/netdev/2005-05/msg02545.html (11,156 bytes)

239. Re: RFC: NAPI packet weighting patch (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Tue, 31 May 2005 15:14:43 -0700 (PDT)
per cpu speed, per memory bus speed, per I/O bus speed, and add in other complications such as NUMA My point is that whatever experimental number you come up with will be good for that driver on your
/archives/netdev/2005-05/msg02546.html (10,179 bytes)

240. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Jon Mason <jdmason@xxxxxxxxxx>
Date: Tue, 31 May 2005 18:28:43 -0500
I'm not arguing against a /proc entry to tune dev->weight for those sysadmins advanced enough to do that. I am arguing that we can make the driver smarter (at little/no cost) for "out of the box" use
/archives/netdev/2005-05/msg02567.html (10,707 bytes)


This search system is powered by Namazu