Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\]\s+netif_rx\:\s+receive\s+path\s+optimization\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\]\s+netif_rx\:\s+receive\s+path\s+optimization\s*$/: 38 ]

Total 38 documents matching your query.

1. Re: [RFC] netif_rx: receive path optimization (score: 1): Author: Andi Kleen <ak@xxxxxx>; Date: Fri, 01 Apr 2005 18:40:07 +0200; We went over this a lot several years ago when Linux got multi threaded RX with softnet in 2.1. You might want to go over the archives. Some things that came out of it was a sender side TCP optimizat; /archives/netdev/2005-04/msg00018.html (8,798 bytes)
2. Re: [RFC] netif_rx: receive path optimization (score: 1): Author: Rick Jones <rick.jones2@xxxxxx>; Date: Fri, 01 Apr 2005 10:22:51 -0800; The main idea behind TOPS and prior to that IPS was to spread-out the processing of packets across as many CPUs as we could, as "correctly" as we could. Very very hard to do. Why do you say that? "Co; /archives/netdev/2005-04/msg00023.html (10,096 bytes)
3. work configs: disconnect network options from drivers (score: 1): Author: Miller" <davem@xxxxxxxxxxxxx>; Date: Thu, 31 Mar 2005 12:04:10 -0800; Here is another alternative that seems better than the earlier posting. It uses a per device receive queue for non-NAPI devices. The only issue is that then we lose the per-cpu queue's and that could; /archives/netdev/2005-03/msg01852.html (26,326 bytes)
4. ice (score: 1): Author: xxxx>; Date: 31 Mar 2005 16:10:32 -0500; The repurcassions of going from per-CPU-for-all-devices queue (introduced by softnet) to per-device-for-all-CPUs maybe huge in my opinion especially in SMP. A closer view of whats there now maybe per; /archives/netdev/2005-03/msg01859.html (10,409 bytes)
5. x: receive path optimization (score: 1): Author: aka Dino) BOIE" <util@xxxxxxxxxxxxxxx>; Date: Thu, 31 Mar 2005 13:17:07 -0800; Any real hardware only has a single receive packet source (the interrupt routine), and the only collision would be in the case of interrupt migration. So having per-device-per-CPU queue's would be ov; /archives/netdev/2005-03/msg01861.html (11,235 bytes)
6. -Device (score: 1): Author: Jay Vosburgh <fubar@xxxxxxxxxx>; Date: Thu, 31 Mar 2005 13:24:40 -0800; The repurcassions of going from per-CPU-for-all-devices queue (introduced by softnet) to per-device-for-all-CPUs maybe huge in my opinion especially in SMP. A closer view of whats there now maybe per; /archives/netdev/2005-03/msg01862.html (11,098 bytes)
7. ization (score: 1): Author: Sam Ravnborg <sam@xxxxxxxxxxxx>; Date: 31 Mar 2005 16:25:25 -0500; The idea behind the current per-CPU queues is to avoid cache ping-ponging; same queue shared across multiple CPUs with roundrobin interupts will get expensive. In other words these non-NAPI devices w; /archives/netdev/2005-03/msg01863.html (11,589 bytes)
8. x: receive path optimization (score: 1): Author: David S. Miller" <davem@xxxxxxxxxxxxx>; Date: 31 Mar 2005 16:38:04 -0500; Take the following scenario in non-NAPI. -packet 1 arrives -interupt happens, NIC bound to CPU0 - in the meantime packets 2,3 arrive - 3 packets put on queue for CPU0 - interupt processing done - pac; /archives/netdev/2005-03/msg01865.html (12,412 bytes)
9. -Device (score: 1): Author: xxxxxxxxxxxxx>; Date: Thu, 31 Mar 2005 23:43:27 +0200; Just a naive question : why at all trying to accelerate netif_rx? Isn't NAPI the best choice for high performance rx anyway? -- Eric; /archives/netdev/2005-03/msg01866.html (12,498 bytes)
10. iscuss] Summary of 2005 Kernel Summit Proposed Topics (score: 1): Author: s2@xxxxxx>; Date: Thu, 31 Mar 2005 14:02:40 -0800; It was a side-effect of trying to clean out the dead code leftover from removal of fastroute and other old experiments. netif_rx still gets used for loopback and people do benchmarks on loopback. Als; /archives/netdev/2005-03/msg01871.html (12,870 bytes)
11. ice (score: 1): Author: xxxx>; Date: Thu, 31 Mar 2005 14:42:36 -0800; At the risk of again chewing on my toes (yum), if multiple CPUs are pulling packets from the per-device queue there will be packet reordering. ;-> This happens already _today_ on Linux on non-NAPI. T; /archives/netdev/2005-03/msg01880.html (12,737 bytes)
12. ice (score: 1): Author: ler" <davem@xxxxxxxxxxxxx>; Date: Thu, 31 Mar 2005 15:03:20 -0800; Rick Jones wrote: Take the following scenario in non-NAPI. -packet 1 arrives -interupt happens, NIC bound to CPU0 - in the meantime packets 2,3 arrive - 3 packets put on queue for CPU0 - interupt pro; /archives/netdev/2005-03/msg01886.html (12,494 bytes)
13. t/netlink/af_netlink.c (126) (score: 1): Author: xxxxxxxxxx>; Date: Thu, 31 Mar 2005 15:28:16 -0800; I "never" see that because I always bind a NIC to a specific CPU :) Just about every networking-intensive benchmark report I've seen has done the same. Just a reminder that the networking-benchmark w; /archives/netdev/2005-03/msg01891.html (12,249 bytes)
14. x: receive path optimization (score: 1): Author: xxxxxx>; Date: 31 Mar 2005 18:36:47 -0500; Do you have to be so clever? ;-> No reordering there. But if interupt happens on "wrong" cpu - and you decide higher level processing is to be done on the "right" cpu (i assume queueing on some per C; /archives/netdev/2005-03/msg01893.html (10,981 bytes)
15. ion (score: 1): Author: t Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Thu, 31 Mar 2005 16:07:54 -0800; Note Linux is quiet resilient to reordering compared to other OSes (as you may know) but avoiding this is a better approach - hence my suggestion to use NAPI when you want to do serious TCP. Would th; /archives/netdev/2005-03/msg01896.html (12,428 bytes)
16. -Device (score: 1): Author: x>; Date: Thu, 31 Mar 2005 16:10:16 -0800; And do they like the resulting data corruption.; /archives/netdev/2005-03/msg01897.html (11,078 bytes)
17. ization (score: 1): Author: erbert@xxxxxxxxxxxxxxxxxxx>; Date: Thu, 31 Mar 2005 16:30:25 -0800; Rick Jones wrote: Well, I'm in an email discussion with someone who seems to bump their TCP windows quite large, and disable timestamps... Ah, an oldie but a goodie :), disabling route inheritance as; /archives/netdev/2005-03/msg01898.html (10,667 bytes)
18. ization (score: 1): Author: <hadi@xxxxxxxxxx>; Date: Thu, 31 Mar 2005 16:42:11 -0800; Well, I'm in an email discussion with someone who seems to bump their TCP windows quite large, and disable timestamps... And do they like the resulting data corruption. Minor nit - potential data cor; /archives/netdev/2005-03/msg01899.html (11,142 bytes)
19. x: receive path optimization (score: 1): Author: eear <greearb@xxxxxxxxxxxxxxx>; Date: 31 Mar 2005 20:17:10 -0500; Not sure i followed: Your TCP app (server probably) is running on CPU X; You therefore want to tie the NIC which it goes out on the same CPU X? AFAIK, Linux scheduler will reschedule a process on the; /archives/netdev/2005-03/msg01901.html (11,973 bytes)
20. Re: [RFC] netif_rx: receive path optimization (score: 1): Author: Andi Kleen <ak@xxxxxx>; Date: Fri, 01 Apr 2005 18:40:07 +0200; We went over this a lot several years ago when Linux got multi threaded RX with softnet in 2.1. You might want to go over the archives. Some things that came out of it was a sender side TCP optimizat; /archives/netdev/2005-04/msg01154.html (9,080 bytes)

Current List: 1 - 20
Page: [1] [2]