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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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