Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[E1000\-devel\]\s+Transmission\s+limit\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[E1000\-devel\]\s+Transmission\s+limit\s*$/: 110 ]

Total 110 documents matching your query.

61. Re: [E1000-devel] Transmission limit (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Wed, 1 Dec 2004 17:47:24 +0100; Thanks for the the info. Well we'll be forced to get into those problems when the HW is capable. I'll guess it will be w. the 10 GIGE cards. --ro; /archives/netdev/2004-12/msg00957.html (12,745 bytes)
62. Re: [E1000-devel] Transmission limit (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Wed, 1 Dec 2004 18:37:37 +0100; Huh. I've got a deja-vu feeling. What will happen if we remove almost all events (interrupts) and just have the timer waking up once-in-a-while? --ro; /archives/netdev/2004-12/msg00959.html (12,727 bytes)
63. Re: [E1000-devel] Transmission limit (score: 1): Author: Lennert Buytenhek <buytenh@xxxxxxxxxxxxxx>; Date: Wed, 1 Dec 2004 19:29:43 +0100; Dual Xeon 2.4GHz, a 82540EM and a 82541GI both on 32/66 on separate PCI buses. BEFORE performance is approx the same for both, ~620kpps. AFTER performance is ~730kpps, also approx the same for both.; /archives/netdev/2004-12/msg00960.html (12,966 bytes)
64. Re: [E1000-devel] Transmission limit (score: 1): Author: Lennert Buytenhek <buytenh@xxxxxxxxxxxxxx>; Date: Wed, 1 Dec 2004 22:35:50 +0100; Pretty graph attached. From ~220B packets or so it does wire speed, but there's still an odd drop in performance around 256B packets (which is also there without your patch.) From 350B packets or so,; /archives/netdev/2004-12/msg00963.html (13,722 bytes)
65. Re: [E1000-devel] Transmission limit (score: 1): Author: Scott Feldman <sfeldma@xxxxxxxxx>; Date: Wed, 01 Dec 2004 22:13:33 -0800; Seems this is helping PCI nics but not PCI-X. I was using PCI 32/33. Can't explain the dip around 256B. Idea#1 Is the write of TDT causing interference with DMA transactions? In addition to my patch,; /archives/netdev/2004-12/msg00968.html (14,761 bytes)
66. Re: [E1000-devel] Transmission limit (score: 1): Author: Marco Mellia <mellia@xxxxxxxxxxxxxxxxxxxx>; Date: 02 Dec 2004 14:39:32 +0100; We'll be glad to spend some time trying this out. Please, we are not very confortable with the linux bitkeeper maintenance method. Can we ask you to provide us a patch to a standard kernel/driver (w; /archives/netdev/2004-12/msg00975.html (13,121 bytes)
67. Re: [E1000-devel] Transmission limit (score: 1): Author: Marco Mellia <mellia@xxxxxxxxxxxxxxxxxxxx>; Date: 02 Dec 2004 18:24:34 +0100; I double checked with the people that actually did the job. They indeed tested both cases, i.e., dropping packets either using IRQ (therefore using netif_rx()) or using NAPI (therefore using netif_r; /archives/netdev/2004-12/msg00977.html (14,425 bytes)
68. Re: [E1000-devel] Transmission limit (score: 1): Author: Marco Mellia <mellia@xxxxxxxxxxxxxxxxxxxx>; Date: 02 Dec 2004 18:31:30 +0100; Here are the numbers in our setup: vanilla kernel [2.4.20 + packetgen + driver e1000 5.4.11] 4096 Descr => 356 Mbps (60 bytes long frames) => 941Mbps (1500 bytes lonf frames) 256 Descr => 354 Mbps (6; /archives/netdev/2004-12/msg00979.html (13,873 bytes)
69. Re: [E1000-devel] Transmission limit (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Thu, 2 Dec 2004 18:54:32 +0100; Scott! I've rerun some of the tests. I've set maxcpus=1 make sure all things happens on one CPU. Some HW as yesterday. I see a now lot variation in the results from your patch. vanilla 804353pps 411M; /archives/netdev/2004-12/msg00981.html (12,867 bytes)
70. Re: [E1000-devel] Transmission limit (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Thu, 2 Dec 2004 19:23:24 +0100; Hello! Below is little patch to clean skb at xmit. It's old jungle trick Jamal and I used w. tulip. Note we can now even decrease the size of TX ring. It can increase TX performance from 800 kpps to; /archives/netdev/2004-12/msg00982.html (13,961 bytes)
71. Re: [E1000-devel] Transmission limit (score: 1): Author: Lennert Buytenhek <buytenh@xxxxxxxxxxxxxx>; Date: Fri, 3 Dec 2004 00:25:31 +0100; Robert, there is something weird with your setup with packets sizes under 160 bytes. Can you check if you also get wildly variable numbers on a baseline kernel perhaps? The numbers you sent me of pac; /archives/netdev/2004-12/msg00989.html (12,605 bytes)
72. Re: [E1000-devel] Transmission limit (score: 1): Author: Scott Feldman <sfeldma@xxxxxxxxx>; Date: Thu, 02 Dec 2004 21:23:30 -0800; These are the best numbers reported so far, right? Did you try combining the two? You want to use E1000_DESC_UNUSED here because of the ring wrap. ;-) -scott; /archives/netdev/2004-12/msg00993.html (13,354 bytes)
73. Re: [E1000-devel] Transmission limit (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 03 Dec 2004 08:07:49 -0500; Would a -rcX patch be fine for you? 2.6.10-rc2; which means you willl take 2.6.9 patch it with the patch-2.6.10-rc2.gz from kernel.org/v2.6/testing directory then patch one more time with patch i giv; /archives/netdev/2004-12/msg00996.html (12,045 bytes)
74. Re: [E1000-devel] Transmission limit (score: 1): Author: jamal <hadi@xxxxxxxxxx>; Date: 03 Dec 2004 08:24:49 -0500; Interesting thought. I also saw improvements with my batching patch for PCI 32/32 but nothing noticeable in PCI-X 64/66. cheers, jamal; /archives/netdev/2004-12/msg00997.html (13,262 bytes)
75. Re: [E1000-devel] Transmission limit (score: 1): Author: Lennert Buytenhek <buytenh@xxxxxxxxxxxxxx>; Date: Fri, 3 Dec 2004 21:57:06 +0100; Attached is a graph of my numbers with and without your patch for: - An 82540 at PCI 32/33, idle 33MHz card on the same bus forcing it to 33MHz. - An 82541 at PCI 32/66. - An 82546 at PCI-X 64/100, N; /archives/netdev/2004-12/msg01001.html (13,998 bytes)
76. Re: [E1000-devel] Transmission limit (score: 1): Author: Lennert Buytenhek <buytenh@xxxxxxxxxxxxxx>; Date: Sat, 4 Dec 2004 11:36:26 +0100; When extrapolating these numbers to the 0-byte packet case (which then tells you the per-packet overhead), I get the following approximate numbers: case overhead phi-32-33-82540-2.6.9 1.86 us phi-32-; /archives/netdev/2004-12/msg01006.html (12,532 bytes)
77. Re: [E1000-devel] Transmission limit (score: 1): Author: Martin Josefsson <gandalf@xxxxxxxxxxxxxx>; Date: Fri, 10 Dec 2004 17:24:12 +0100; Just a small unimportant note. This patch is pretty broken, I doubt you want to call e1000_clean_tx_ring(), I think you want some variant of e1000_clean_tx_irq() :) e1000_clean_tx_irq() takes adapter; /archives/netdev/2004-12/msg01233.html (14,334 bytes)
78. Re: [E1000-devel] Transmission limit (score: 1): Author: P@xxxxxxxxxxxxxx; Date: Fri, 26 Nov 2004 14:05:26 +0000; I'm forwarding this to netdev, as these are very interesting results (even if I don't beleive them). If you point us at the code/versions we will be better able to answer. We found something which is; /archives/netdev/2004-11/msg01981.html (11,997 bytes)
79. Re: [E1000-devel] Transmission limit (score: 1): Author: Marco Mellia <mellia@xxxxxxxxxxxxxxxxxxxx>; Date: 26 Nov 2004 16:31:21 +0100; If you don't trust us, please, ignore this email. Sorry. That's the number we have. And are actually very similar from what other colleagues of us got. The point is: while a PCI-X linux or (or click); /archives/netdev/2004-11/msg01984.html (15,469 bytes)
80. Re: [E1000-devel] Transmission limit (score: 1): Author: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>; Date: Fri, 26 Nov 2004 16:40:04 +0100; In more detail please... The RX ring must be refilled? And HW DMA's the to memory-buffer? But I assume data it not touched otherwise. Touching the packet-data givs a major impact. See eth_type_trans; /archives/netdev/2004-11/msg01986.html (13,776 bytes)

Current List: 61 - 80
Page: [1] [2] [3] [4] [5] [6]