Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Tigon3\s+5701\s+PCI\-X\s+recv\s+performance\s+problem\s*$/: 88 ]

Total 88 documents matching your query.

61. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Tue, 11 Nov 2003 16:32:00 -0500
On Tue, 11 Nov 2003 14:04:50 -0600 Why are you depending upon MCKINLEY? Don't all ia64 cpus give traps for unaligned memory accesses? I have no evidence of a problem with Itanium1, only on Itanium2
/archives/netdev/2003-11/msg00873.html (12,531 bytes)

62. Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: John Partridge <johnip@xxxxxxx>
Date: Wed, 08 Oct 2003 12:12:24 -0500
I am seeing a problem with PCI-X recv performance on the Broadcom 5701 cards. This is due to a known PCI-X errata with the DMA engine when buffers are non zero offset aligned. As well as performance
/archives/netdev/2003-10/msg00986.html (10,323 bytes)

63. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 8 Oct 2003 10:10:46 -0700
Oh yeah? What are your numbers like if you just disable the ia64 kernel unaligned access printk()?
/archives/netdev/2003-10/msg00987.html (8,613 bytes)

64. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: John Partridge <johnip@xxxxxxx>
Date: Wed, 08 Oct 2003 12:52:57 -0500
Not too much different mig125:~ # nttcp -r -T -l262144 -w1024 -n1000 10.50.1.130 -l262144 -w1024 Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s l318341120 10.00 9.96 254.6131 255.62
/archives/netdev/2003-10/msg00988.html (9,921 bytes)

65. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: Steve Modica <modica@xxxxxxx>
Date: Wed, 08 Oct 2003 13:21:50 -0500
Hi David, it's definitely not the printk. They have that throttled so it only prints once for a large number of occurances. The problem is that on the Altix platform they have to deal with unaligned
/archives/netdev/2003-10/msg00989.html (11,201 bytes)

66. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 8 Oct 2003 11:26:57 -0700
The problem is that your change is arch-dependant yet you make it run on all platforms. On x86 we don't want to do what your change is doing, the unaligned accesses are cheap enough. We need to abstr
/archives/netdev/2003-10/msg00991.html (9,513 bytes)

67. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 8 Oct 2003 11:29:57 -0700
You mean, ia64. Has anyone optimized the unaligned trap handler on ia64 (perhaps coding it in raw assembler) to see what the situation looks like then? Nobody wants to ever comment on this... But it
/archives/netdev/2003-10/msg00992.html (10,490 bytes)

68. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Wed, 8 Oct 2003 20:37:42 +0200
Atomicity should not be needed to access a private skb. Maybe you didn't want to change the core stack to use the unaligned access mechanism? In that case it may be better to fix the stack with some
/archives/netdev/2003-10/msg00994.html (10,684 bytes)

69. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: John Partridge <johnip@xxxxxxx>
Date: Wed, 08 Oct 2003 14:02:57 -0500
OK, fair enough, you mean like :- if (len > RX_COPY_THRESHOLD && tp->rx_offset == 2) { if (len > RX_COPY_THRESHOLD) { Not too much different The problem is that your change is arch-dependant yet you
/archives/netdev/2003-10/msg00995.html (10,806 bytes)

70. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: Steve Modica <modica@xxxxxxx>
Date: Wed, 08 Oct 2003 14:11:47 -0500
I think it'd be better to create some macro like this: Then replace the code in the if with the new macro. We can define FORCE_SKB_ALIGNMENT in our build environment as can others if necessary. other
/archives/netdev/2003-10/msg00996.html (11,786 bytes)

71. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 8 Oct 2003 12:15:24 -0700
Please, do this right. Make a "CONFIG_UNALIGNED_VERY_SLOW" or something that platforms can define, and then drivers can ifdef upon.
/archives/netdev/2003-10/msg00997.html (10,268 bytes)

72. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 8 Oct 2003 12:22:23 -0700
I have a very strong feeling that we'd really need both options to arrive at an optimal implementation on all platforms. Something that makes drivers copy packets, and something else that traps packe
/archives/netdev/2003-10/msg00998.html (11,787 bytes)

73. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 8 Oct 2003 13:24:02 -0700
Frankly, I just want to shut all the ia64 users up because they keep barking due to the kernel unaligned trap message that port spits out. We could write some helper routines. Andi, stop right there,
/archives/netdev/2003-10/msg01000.html (11,588 bytes)

74. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Wed, 8 Oct 2003 22:33:06 +0200
Well, this thread was about the tigon3 and I don't see that as an el cheapo card. If SGI uses it on the Altix I guess they want it to perform well with many CPUs. Anyways, it was just a brain dump r
/archives/netdev/2003-10/msg01001.html (11,715 bytes)

75. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 8 Oct 2003 13:32:48 -0700
It's one of the oldest variants of the tg3 chip and it's full of hardware bugs when used in PCI-X. The page chunk allocator is meant to make it easier to put the non-header parts in the frag list of
/archives/netdev/2003-10/msg01003.html (12,232 bytes)

76. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Wed, 8 Oct 2003 22:46:18 +0200
Ok. Why do we care about it then? Copying should be fine for that. Sure, but to handle the sub allocation you need a destructor per fragment. (otherwise how do you want to share a page between differ
/archives/netdev/2003-10/msg01004.html (13,229 bytes)

77. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Wed, 8 Oct 2003 22:22:48 +0200
I agree that it would be the best solution, but isn't it a bit late in 2.6 now for that? Sounds more like a great 2.7.0 project. It's not that it's a new problem - we had this since the Alpha port a
/archives/netdev/2003-10/msg01005.html (12,256 bytes)

78. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 8 Oct 2003 13:50:30 -0700
Aha, no you don't, this is the beauty of it. Let's say we've packed 4 packets into a page (or 10 in 2 pages, whatever the optimal packing is), as you attach each chunk to a SKB you up the page count
/archives/netdev/2003-10/msg01006.html (13,163 bytes)

79. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: Steve Modica <modica@xxxxxxx>
Date: Fri, 10 Oct 2003 14:05:35 -0500
For 2.6 short term probably some bandaid like the CONFIG_UNALIGNMENT_COSTLY and doing driver copies is better. Question. Is there a way for us to create a CONFIG entry like this, but also allow for
/archives/netdev/2003-10/msg01039.html (11,911 bytes)

80. Re: Tigon3 5701 PCI-X recv performance problem (score: 1)
Author: Andi Kleen <ak@xxxxxxx>
Date: Fri, 10 Oct 2003 21:20:36 +0200
Doesn't it already have a rx_copy_break argument? If yes just set it to zero and it will always copy. If not add it. -Andi
/archives/netdev/2003-10/msg01041.html (11,044 bytes)


This search system is powered by Namazu