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

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.

21. Re: RFC: NAPI packet weighting patch (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Fri, 03 Jun 2005 11:59:35 -0700; David S. Miller wrote: From: Ben Greear <greearb@xxxxxxxxxxxxxxx> Maybe the poll is disabling the IRQs on the NIC for too long, or something like that? In a reply I just sent out to this thread, I po; /archives/netdev/2005-06/msg00105.html (12,428 bytes)
22. Re: RFC: NAPI packet weighting patch (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Fri, 03 Jun 2005 12:01:26 -0700 (PDT); Jamal, this is my current theory as well, we hit the jiffies check. It it the only logical explanation I can come up with for the single adapter case. There are some ways we can mitigate this. Here i; /archives/netdev/2005-06/msg00106.html (11,585 bytes)
23. Re: RFC: NAPI packet weighting patch (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Fri, 03 Jun 2005 12:02:57 -0700 (PDT); It allows his application to get onto the CPU faster.; /archives/netdev/2005-06/msg00107.html (10,998 bytes)
24. Re: RFC: NAPI packet weighting patch (score: 1): Author: Mitch Williams <mitch.a.williams@xxxxxxxxx>; Date: Fri, 3 Jun 2005 12:28:10 -0700; Well, I hate to mess up your guys' theories, but the real reason is simpler: hardware receive resources, specifically descriptors and buffers. In a typical NAPI polling loop, the driver processes rec; /archives/netdev/2005-06/msg00109.html (13,196 bytes)
25. Re: RFC: NAPI packet weighting patch (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: Fri, 03 Jun 2005 15:40:50 -0400; I think you are more than likely right. If we can instrument it Mitch could check it out. Mitch would you like to try something that will instrument this? I know i have seen this behavior but it was; /archives/netdev/2005-06/msg00110.html (13,016 bytes)
26. Re: RFC: NAPI packet weighting patch (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: Fri, 03 Jun 2005 15:59:31 -0400; What you said above is unfortunately also speculation ;-> But one that you could validate by putting proper hooks. As an example, try to restore a descriptor every time you pick one - for an example; /archives/netdev/2005-06/msg00111.html (13,351 bytes)
27. RE: RFC: NAPI packet weighting patch (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Fri, 3 Jun 2005 22:17:31 +0200; It is possible that a lower weight forced your driver to disable interrupts and do packet reception w/o interrupts often this is more efficient as we get rid intr. latency etc. Again I think weight s; /archives/netdev/2005-06/msg00112.html (11,237 bytes)
28. Re: RFC: NAPI packet weighting patch (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Fri, 03 Jun 2005 13:22:57 -0700 (PDT); This is why you should replenish RX packets _IN_ your RX packet receive processing, not via some tasklet or other seperate work processing context. No wonder I never see this on tg3. It is the only w; /archives/netdev/2005-06/msg00113.html (11,127 bytes)
29. Re: RFC: NAPI packet weighting patch (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: Fri, 03 Jun 2005 16:23:25 -0400; Sorry, Its already there as Dave said in his email. Look for time_squeeze. Its the column i labeled XXXX below. -- $ cat /proc/net/softnet_stat 0000f938 00000000 XXXXXXX 00000000 00000000 00000000 00; /archives/netdev/2005-06/msg00115.html (11,533 bytes)
30. Re: RFC: NAPI packet weighting patch (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Fri, 03 Jun 2005 13:29:22 -0700 (PDT); Actually, the problem is slightly different. E1000 processes the full QUOTA of RX packets, _THEN_ replenishes with new RX buffers. No wonder the chip runs out of RX descriptors. You should replenish; /archives/netdev/2005-06/msg00116.html (11,438 bytes)
31. Re: RFC: NAPI packet weighting patch (score: 1): Author: Mitch Williams <mitch.a.williams@xxxxxxxxx>; Date: Fri, 3 Jun 2005 13:28:57 -0700; I might not be able to get into the lab today (they keep making me do work!), but I should be able to pop in Monday and take a look. Shouldn't take too long. Thanks, Mitch; /archives/netdev/2005-06/msg00117.html (11,796 bytes)
32. Re: RFC: NAPI packet weighting patch (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Fri, 03 Jun 2005 13:30:41 -0700 (PDT); I don't think this is it. What's happening is that E1000 pulls up to a full dev->quota of packets off the ring, and _THEN_ goes back and does RX buffer replenishing. It is very clear why E1000 runs o; /archives/netdev/2005-06/msg00118.html (11,094 bytes)
33. Re: RFC: NAPI packet weighting patch (score: 1): Author: Ben Greear <greearb@xxxxxxxxxxxxxxx>; Date: Fri, 03 Jun 2005 13:30:54 -0700; Mitch Williams wrote: On Fri, 3 Jun 2005, David S. Miller wrote: From: jamal <hadi@xxxxxxxxxx> Date: Fri, 03 Jun 2005 14:42:30 -0400 When you reduce the weight, the system is spending less time in th; /archives/netdev/2005-06/msg00119.html (15,859 bytes)
34. Re: RFC: NAPI packet weighting patch (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Fri, 03 Jun 2005 13:31:33 -0700 (PDT); Yes, this in my mind is exactly the problem. TG3 does this properly, as do several other drivers. You should never defer RX buffer replenishment, you should always do it as you grab packets off of th; /archives/netdev/2005-06/msg00120.html (10,810 bytes)
35. Re: RFC: NAPI packet weighting patch (score: 1): Author: "Michael Chan" <mchan@xxxxxxxxxxxx>; Date: Fri, 03 Jun 2005 12:49:29 -0700; Yes, in tg3, rx buffers are replenished and put back into the ring as completed packets are taken off the ring. But we don't tell the chip about these new buffers until we get to the end of the loop,; /archives/netdev/2005-06/msg00124.html (11,124 bytes)
36. Re: RFC: NAPI packet weighting patch (score: 1): Author: Lennert Buytenhek <buytenh@xxxxxxxxxxxxxx>; Date: Fri, 3 Jun 2005 22:59:45 +0200; Which makes a lot more sense, since you'd rather do one MMIO write at the end of the loop than one per iteration, especially if your MMIO read (flush) latency is high. (Any subsequent MMIO read will; /archives/netdev/2005-06/msg00125.html (11,778 bytes)
37. Re: RFC: NAPI packet weighting patch (score: 1): Author: Edgar E Iglesias <edgar.iglesias@xxxxxxxx>; Date: Fri, 3 Jun 2005 23:07:01 +0200; Maybe it would be better to put a fixed weight at this level, return the descriptors to the HW after every X packets. That way you can keep the NAPI weight at 64 (or what ever) and still give back de; /archives/netdev/2005-06/msg00126.html (12,611 bytes)
38. Re: RFC: NAPI packet weighting patch (score: 1): Author: Jon Mason <jdmason@xxxxxxxxxx>; Date: Fri, 3 Jun 2005 16:12:10 -0500; e1000 isn't the only driver to do things this way. r8169, via-velocity, dl2k, and skge (and I'm sure many more). Might be nice to perform a driver audit to see what drivers do this.; /archives/netdev/2005-06/msg00127.html (11,324 bytes)
39. Re: RFC: NAPI packet weighting patch (score: 1): Author: "Michael Chan" <mchan@xxxxxxxxxxxx>; Date: Fri, 03 Jun 2005 13:35:22 -0700; I agree on the merit of issuing only one IO at the end. What I'm saying is that doing so will make it similar to e1000 where all the buffers are replenished at the end. Isn't that so or am I missing; /archives/netdev/2005-06/msg00133.html (12,077 bytes)
40. Re: RFC: NAPI packet weighting patch (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: Fri, 03 Jun 2005 18:29:58 -0400; I think the main issue would be a lot less CPU used in your case (because of the single MMIO). So when you write the MMIO, 25 buffers are replenished or is this auto magically happening in the backgr; /archives/netdev/2005-06/msg00135.html (12,546 bytes)

Current List: 21 - 40
Page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]