Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*netif_rx\s+packet\s+dumping\s*$/: 102 ]

Total 102 documents matching your query.

1. netif_rx packet dumping (score: 1)
Author: >
Date: Thu, 3 Mar 2005 12:38:11 -0800
Both BIC TCP 1.1 and TCP-H include patches to disable the queue throttling behaviour of netif_rx. The existing throttling algorithm causes all packets to be dumped (until queue emptys) when the packe
/archives/netdev/2005-03/msg00143.html (8,841 bytes)

2. Re: netif_rx packet dumping (score: 1)
Author:
Date: Thu, 3 Mar 2005 12:55:56 -0800
Even without NAPI, netif_rx() ends up using the quota etc. machanisms when the queue gets processed via process_backlog(). ksoftirqd should handle cpu starvation issues at a higher level. I think it
/archives/netdev/2005-03/msg00152.html (9,614 bytes)

3. Re: netif_rx packet dumping (score: 1)
Author: . Miller" <davem@xxxxxxxxxxxxx>
Date: Thu, 3 Mar 2005 13:01:57 -0800
Okay, already have patchset to clean out the sample_stats and other leftovers so I'll add it to the tail of that.
/archives/netdev/2005-03/msg00154.html (10,422 bytes)

4. Re: netif_rx packet dumping (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: 03 Mar 2005 16:18:08 -0500
A couple of issues with this - the rx softirq uses netif_max_backlog as a contraint on how long to run before yielding. Could probably fix by having a different variable. It may be fair to decouple t
/archives/netdev/2005-03/msg00156.html (11,241 bytes)

5. Re: netif_rx packet dumping (score: 1)
Author: xxxxxx>
Date: Thu, 3 Mar 2005 13:21:43 -0800
My plan is to keep netif_max_backlog but bump it up to something bigger by default. Maybe even autosize it based on memory available. But get rid of the "dump till empty" behaviour that screws over T
/archives/netdev/2005-03/msg00157.html (11,851 bytes)

6. Re: netif_rx packet dumping (score: 1)
Author: Hemminger <shemminger@xxxxxxxx>
Date: 03 Mar 2005 16:24:25 -0500
Ok, this does sound more reasonable. Out of curiosity, are packets being dropped at the socket queue? Why is "dump till empty" behaviour screwing over TCP. cheers, jamal
/archives/netdev/2005-03/msg00158.html (9,938 bytes)

7. Re: netif_rx packet dumping (score: 1)
Author: xxxxxx>
Date: Thu, 03 Mar 2005 21:26:58 +0000
Stephen Hemminger wrote: Both BIC TCP 1.1 and TCP-H include patches to disable the queue throttling behaviour of netif_rx. The existing throttling algorithm causes all packets to be dumped (until que
/archives/netdev/2005-03/msg00159.html (11,330 bytes)

8. Re: netif_rx packet dumping (score: 1)
Author:
Date: Thu, 3 Mar 2005 13:32:37 -0800
Because it does the same thing tail-drop in routers do. It makes everything back off a lot and go into slow start. If we'd just drop 1 packet per flow or something like that (so it could be fixed wit
/archives/netdev/2005-03/msg00162.html (10,311 bytes)

9. Re: netif_rx packet dumping (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Thu, 3 Mar 2005 13:36:59 -0800
Please split up your patches properly this time. Last time you split up the patches, there was common changes in several of the patch files. It looked like you just hand edited the patches in order t
/archives/netdev/2005-03/msg00164.html (10,470 bytes)

10. Re: netif_rx packet dumping (score: 1)
Author: . Miller" <davem@xxxxxxxxxxxxx>
Date: Thu, 03 Mar 2005 21:44:52 +0000
David S. Miller wrote: On Thu, 03 Mar 2005 21:26:58 +0000 Baruch Even <baruch@xxxxxxxxx> wrote: I have patches for the SACK processing to improve performance which should reduce the problems with the
/archives/netdev/2005-03/msg00169.html (11,765 bytes)

11. Re: netif_rx packet dumping (score: 1)
Author: oph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 03 Mar 2005 22:54:24 +0100
There may be free space left over in skb->cb that you can use for this. -Andi
/archives/netdev/2005-03/msg00171.html (10,041 bytes)

12. Re: netif_rx packet dumping (score: 1)
Author: xxxxxxx>
Date: Thu, 3 Mar 2005 13:54:16 -0800
Maybe a simple Random Exponential Drop (RED) would be more friendly. Still need some bound, because if process_backlog is running slower than the net; then the queue could grow till memory exhausted
/archives/netdev/2005-03/msg00172.html (11,167 bytes)

13. Re: netif_rx packet dumping (score: 1)
Author: Hemminger <shemminger@xxxxxxxx>
Date: Thu, 3 Mar 2005 13:57:18 -0800
I'm sure you can find a way to steal sizeof(void *) from "struct tcp_skb_cb" :-) It is currently 36 bytes on both 32-bit and 64-bit platforms. This means if you can squeeze out 4 bytes (so that it fi
/archives/netdev/2005-03/msg00173.html (10,524 bytes)

14. Re: netif_rx packet dumping (score: 1)
Author: . Miller" <davem@xxxxxxxxxxxxx>
Date: 03 Mar 2005 17:01:37 -0500
Thats true; but it's the RX interrupt disabling that worries me. And the fact that memory is finite. Let me throw some worst case scenarios: In the (ahem) "old" days when 100Mbps was hip, 148kpps (tr
/archives/netdev/2005-03/msg00174.html (12,061 bytes)

15. Re: netif_rx packet dumping (score: 1)
Author: xxxxxx>
Date: Thu, 3 Mar 2005 17:02:39 -0500 (EST)
That would probably not be appropriate. This queue is only for absorbing micro-scale bursts. It should not hold any data in steady state like a router queue can. The receive window can handle the mac
/archives/netdev/2005-03/msg00175.html (11,156 bytes)

16. Re: netif_rx packet dumping (score: 1)
Author: John Heffner <jheffner@xxxxxxx>
Date: 03 Mar 2005 17:03:06 -0500
It will help to post on this list when such issues are noticed. It could be a simple a driver bug: such a the one posted on by Lennert 2 days ago on e1000 NAPI - such a bug could have had serious rep
/archives/netdev/2005-03/msg00176.html (9,516 bytes)

17. Re: netif_rx packet dumping (score: 1)
Author: xxxxxx>
Date: Thu, 3 Mar 2005 14:04:29 -0800
There is 4 bytes, enough for 32-bit but not 64-bit platforms. Also, see my other reply to his posting.
/archives/netdev/2005-03/msg00177.html (10,276 bytes)

18. Re: netif_rx packet dumping (score: 1)
Author: . Miller" <davem@xxxxxxxxxxxxx>
Date: Thu, 03 Mar 2005 22:14:35 +0000
David S. Miller wrote: On Thu, 03 Mar 2005 21:44:52 +0000 Baruch Even <baruch@xxxxxxxxx> wrote: The current linked list goes over all the packets, the linked list we add is for the packets that were
/archives/netdev/2005-03/msg00178.html (11,362 bytes)

19. Re: netif_rx packet dumping (score: 1)
Author:
Date: 03 Mar 2005 17:26:51 -0500
recall this is a queue that is potentially shared by many many flows from potentially many many interfaces i.e it deals with many many micro-scale bursts. Clearly, the best approach is to have lots a
/archives/netdev/2005-03/msg00179.html (11,492 bytes)

20. Re: netif_rx packet dumping (score: 1)
Author: xxxxxx>
Date: Thu, 03 Mar 2005 22:31:28 +0000
jamal wrote: On Thu, 2005-03-03 at 16:26, Baruch Even wrote: NAPI was not used because it caused skews in the performance, I haven't tested it myself, just passing hearsay. It will help to post on th
/archives/netdev/2005-03/msg00180.html (9,977 bytes)


This search system is powered by Namazu