On Mon, 2008-08-04 at 20:08 +0200, Stefan Richter wrote: > As a discussion reminded me today, I believe I should merge the > following patch (could have done so much earlier in fact). Or is there > anything speaking against it? The value 255 is chosen because it worked before. What you need to do is establish what the upper limit for firewire is (or indeed if it has one). > Meanwhile, SG_ALL has been redefined from 255 to SCSI_MAX_SG_SEGMENTS = > 128 without me noticing it. But since several popular architectures > define ARCH_HAS_SG_CHAIN, we may want to go back to 255 in (fw-)sbp2. > (Besides, we should also do some tests to figure out an actual optimum. > And fw-sbp2.c's struct sbp2_command_orb should become variably sized.) Don't bother with optmium ... that's block's job based on what it sees from the completions. All we need to know is maximum. > Does the most relevant user of large transfers with SBP-2 devices, > sd-mod, use chained s/g lists? pass, but firewire is a reasonably slow bus by modern standards, and you have the protocol overhead for each ORB, so I'd guess there's a point at which increasing the transaction size doesn't buy anything. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
