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.

121. Re: RFC: NAPI packet weighting patch (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Thu, 02 Jun 2005 08:26:46 -0400
What is the point of making the driver "smarter"? Recall, the algorithm used to schedule the netdevices is based on an extension of Weighted Round Robin from Varghese et al known as DRR (ask gooogle
/archives/netdev/2005-06/msg00625.html (11,765 bytes)

122. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Thu, 2 Jun 2005 10:30:52 -0700
In fact, since the default weighting should be based on the amount of cpu time expended per frame rather than link speed. The point is that a more "heavy weight" driver shouldn't starve out all the o
/archives/netdev/2005-06/msg00633.html (12,551 bytes)

123. RE: RFC: NAPI packet weighting patch (score: 1)
Author: "Ronciak, John" <john.ronciak@xxxxxxxxx>
Date: Thu, 2 Jun 2005 14:19:55 -0700
The DRR algorithm assumes a perfect world, where hardware resources are infinite, packets arrive continuously (or separated by very long delays), there are no bus latencies, and CPU speed is infinite
/archives/netdev/2005-06/msg00649.html (14,003 bytes)

124. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Thu, 2 Jun 2005 14:31:26 -0700
This is like saying each CPU vendor should write their own process scheduler for Linux. Now with NUMA and HT, it is getting almost that bad but we still try and keep it CPU neutral. For networking th
/archives/netdev/2005-06/msg00650.html (12,815 bytes)

125. Re: RFC: NAPI packet weighting patch (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Thu, 02 Jun 2005 14:40:03 -0700 (PDT)
I totally agree, even the mere concept of driver-centric decisions in this area is pretty bogus. I don't understand why nobody is investigating doing this stuff by generic measurements that the core
/archives/netdev/2005-06/msg00652.html (10,611 bytes)

126. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Jon Mason <jdmason@xxxxxxxxxx>
Date: Thu, 2 Jun 2005 16:51:48 -0500
I think there is a way for a generic driver NAPI enhancement. That is to modify the weight dependent on link speed. Here is the problem as I see it, NAPI enablement for slow media speeds causes unnee
/archives/netdev/2005-06/msg00653.html (11,379 bytes)

127. Re: RFC: NAPI packet weighting patch (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Thu, 02 Jun 2005 15:12:12 -0700 (PDT)
Why do this when we can adjust the weight in one spot, namely the upper level NAPI ->poll() running loop? It can measure the overhead, how many packets processed, etc. and make intelligent decisions
/archives/netdev/2005-06/msg00655.html (10,793 bytes)

128. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Fri, 3 Jun 2005 00:15:50 +0200
Differentiate the meaning of weight a bit. Let weight only limit the number of pkts we deliver per ->poll Have some other mechanism or threshold to control when interrupts are to be turned on. The fi
/archives/netdev/2005-06/msg00656.html (12,547 bytes)

129. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Jon Mason <jdmason@xxxxxxxxxx>
Date: Thu, 2 Jun 2005 17:19:46 -0500
Yes, a much better idea to do this generically. I 100% agree with you.
/archives/netdev/2005-06/msg00657.html (11,469 bytes)

130. RE: RFC: NAPI packet weighting patch (score: 1)
Author: "Ronciak, John" <john.ronciak@xxxxxxxxx>
Date: Thu, 2 Jun 2005 17:11:20 -0700
I like this idea as well but I do an issue with it. How would this stack code find out that the weight is too high and pacekts are being dropped (not being polled fast enough)? It would have to check
/archives/netdev/2005-06/msg00665.html (12,274 bytes)

131. Re: RFC: NAPI packet weighting patch (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Thu, 02 Jun 2005 17:18:12 -0700 (PDT)
What more do you need other than checking the statistics counter? The drop statistics (the ones we care about) are incremented in real time by the ->poll() code, so it's not like we have to trigger s
/archives/netdev/2005-06/msg00667.html (10,941 bytes)

132. Re: RFC: NAPI packet weighting patch (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Thu, 02 Jun 2005 22:32:33 -0400
I am reading through all the emails and I think either the problem is not being clearly stated or not understood. I was going to say "or i am on crack "- but I know i am clean ;-> Heres what i think
/archives/netdev/2005-06/msg00674.html (13,216 bytes)

133. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Mitch Williams <mitch.a.williams@xxxxxxxxx>
Date: Fri, 3 Jun 2005 10:43:32 -0700
Well, that was me. Or at least I was the original poster on this thread. But my theory (if you can call it that) really wasn't about CPU time. I spent several weeks in our lab with the somewhat nebul
/archives/netdev/2005-06/msg00697.html (15,223 bytes)

134. RE: RFC: NAPI packet weighting patch (score: 1)
Author: "Ronciak, John" <john.ronciak@xxxxxxxxx>
Date: Fri, 3 Jun 2005 10:40:47 -0700
I think that there is some more confusion here. I'm talking about frames dropped by the Ethernet controller at the hardware level (no descriptor available). This for example is happening now with ou
/archives/netdev/2005-06/msg00698.html (10,946 bytes)

135. RE: RFC: NAPI packet weighting patch (score: 1)
Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Fri, 3 Jun 2005 20:08:48 +0200
It's not obvious that weight is to blame for frames dropped. I would look into RX ring size in relation to HW mitigation. And of course if you system is very loaded the RX softirq gives room for othe
/archives/netdev/2005-06/msg00699.html (11,691 bytes)

136. RE: RFC: NAPI packet weighting patch (score: 1)
Author: "Ronciak, John" <john.ronciak@xxxxxxxxx>
Date: Fri, 3 Jun 2005 11:19:02 -0700
With the same system (fairly high end with nothing major running on it) we got rid of the dropped frames by just reducing the weight for 64. So the weight did have something to do with the dropped f
/archives/netdev/2005-06/msg00700.html (10,668 bytes)

137. Re: RFC: NAPI packet weighting patch (score: 1)
Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Fri, 03 Jun 2005 11:33:00 -0700
With the same system (fairly high end with nothing major running on it) we got rid of the dropped frames by just reducing the weight for 64. So the weight did have something to do with the dropped f
/archives/netdev/2005-06/msg00701.html (12,387 bytes)

138. Re: RFC: NAPI packet weighting patch (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Fri, 03 Jun 2005 11:38:17 -0700 (PDT)
I really don't see how changing the weight can change things in the single adapter case. When we hit the quota, we just loop and process more packets. It doesn't fundamentally change anything about h
/archives/netdev/2005-06/msg00702.html (11,999 bytes)

139. Re: RFC: NAPI packet weighting patch (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Fri, 03 Jun 2005 14:42:30 -0400
When you reduce the weight, the system is spending less time in the softirq processing packets before softirq yields. If this gives more opportunity to your app to run, then the performance will go u
/archives/netdev/2005-06/msg00703.html (16,969 bytes)

140. Re: RFC: NAPI packet weighting patch (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Fri, 03 Jun 2005 11:49:50 -0700 (PDT)
Exactly my thoughts as well :) In a reply I just sent out to this thread, I postulate that the jiffies check is hitting earlier with a lower weight value, a quick look at /proc/net/softnet_stat durin
/archives/netdev/2005-06/msg00704.html (11,426 bytes)

Current List: 121 - 140
Page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
This search system is powered by Namazu