Messages in this thread | | | Date | Wed, 20 Dec 2006 15:06:13 -0500 | From | Kristian Høgsberg <> | Subject | Re: [PATCH 0/4] New firewire stack - updated patches |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |