Stefan Richter wrote:
...
And Windows Vista will drop the IP over 1394 functionality,
which is another data point about how widely used this standard is.
If we cared what Windows supports or does not support, we would have gap
count optimization by now, but no support of IEEE 1394b-2002.
Yeah, my point wasn't that we need to drop it because Windows dropped it, it
was just a data point backing up the claim that IP 1394 isn't very widely used.
And as for gap count optimization, I just added that to my git repo. I
thought about adding it before sending out these patches, but I was running
late on getting them out -- I ended up spending too much time chasing down a
stupid spinlock recursion. It is pretty simple to implement in the new stack,
since we have all the topology information available. I did a quick,
unscientific benchmark (md5summing 10 32M files) and the optimization is
definitely noticable. This is a setup where the box and the disk are both
connected to a hub so the max hops is 2, so we're using gap count 4:
real 0m10.021s
user 0m1.435s
sys 0m0.356s
compared to no optimization, ie gap count 63:
real 0m14.537s
user 0m1.390s
sys 0m0.402s
Though I see that Mac OS X uses a more conservative setting for a similiar
topology, so maybe we need to add a bit or "margin" to the numbers from the
table from 1394.
I'm not planning to port the pcilynx driver either. I think it's a sore
point for the old stack as it is - nobody uses it or tests it and it's
continously bit-rotting. So I'd rather not support it.
Here I agree.
However, it can
perform as well as an OHCI card for SBP-2. If you set up a
self-modifying DMA program it can read and write system memory without
CPU intervention too.
OK, I didn't know that although I suspected something like this might be
possible. Of course this remains a potential feature as long as there is
no manpower to actually implement it. (Nor is there a userbase to speak
of to appreciate such an effort.)
Exactly. It's a cool hack (it's mentioned briefly in appendix E.1 of the
PCILynx functional specification) and it would be fun to make it work, but I
don't really see a userbase here. And if somebody has a PCILynx card and want
to use the new stack, I'll trade them for a OHCI controller :) I have a much
more useful way to put PCILynx cards to work using my firewire sniffer
(http://bitplanet.net/nosy).
cheers,
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
