Re: [patch resend] firewire: ieee1394: Move away from SG_ALL

Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> · Mon, 04 Aug 2008 21:58:23 +0200

James Bottomley wrote:

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).

The limit is 65535, following from SBP-2 clause 5.1.2, definition of 

data_size.

[Side note:  The SBP-2 s/g list (a.k.a. page table) consists of 64bit 

wide entries and needs to be contiguous in memory from the POV of the 

FireWire PCI or PCIe controller, and the SBP-2 target reads the table 

from the initiator's memory.  The (fw-)sbp2 driver builds this table as 

a copy of the kernel's s/g list; but this was certainly already to the 

reader clear from the context in the diff.]

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.

OK, with the small caveat that the current (fw-)sbp2 driver code is 

somewhat simplistic WRT page table handling and geared towards rather 

short page tables.  But this may be possible to enhance without too much 

difficulty.

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

A 3200 Mb/s spec exists :-) (though no silicon yet, to my knowledge).

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

--
Stefan Richter
-=====-==--- =--- --=--
http://arcgraph.de/sr/
--
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