sbp2 scatter/gather - pointless complication?

Pat LaVarre lavarre at
Wed Jul 4 06:31:45 PDT 2001

* From the T10 Reflector (t10 at, posted by:
* "Pat LaVarre" <lavarre at>
 > we could not identify any reason
 > to bother with the "normalized page table".
 > since support for unrestricted page tables
 > is mandatory.

 > As a target, you should fully support
 > unrestricted page tables,
 > and make no assumptions ...

I'd like to carefully distinguish failing to supply mandatory support for a 
rare case - the evil into which some silicon vendors have apparently fallen - 
|from failing to optimise a comparatively rare case.

For example, if I try accessing the blocks of disk drive backwards, suddenly 
I see that the people who designed the so-called random-access disk drive 
(and maybe the software above it) optimised for forward access.  Myself, on 
the bus, I've seen 120X degradation in speed, under this stress.

Being an ex-gate-level designer myself, I can see clearly enough that the 
simplest silicon works only with normalized page tables.  This preference 
arises from the same causes that lead many RISC CPUs to choke over memory 
accesses aligned to less than the word size of the processor.

 > failing to optimise a comparatively rare case

Silicon that divides a page table segment of x9E0 into transfers of x800 + 
x1E0 is likely to be making two misaligned accesses rather than one 
misaligned access followed by an aligned access.

This too is a failure to optimise a common case.

Myself, I'd like to think my first thought would be to not to do it that 
way.  Maybe this specific failure to optimise rarely matters?

 > we could not identify any reason
 > to bother with the "normalized page table".

Somebody somewhere once upon a time invented the normalized page table?  That 
person then must have had a reason?  And I've been told unrestricted page 
tables came later?  Anybody have a clue who when thought normalize page 
tables were a Good Idea (TM)?

Lately I've heard unrestricted page tables "were added for Win98".  Also 
added for Apple, I take it?  Did any real hosts ever favour "normalized page 

 > [nonzero page_size]
 > offers no advantage to either the OS
 > or the target, as far as I can tell,

Can you elaborate why politely setting page_size nonzero to admit the use of 
a normalized page table is so obviously useless to you?

Me, coming from Usb, I was surprised to see an ORB with a page table nowhere 
tells the target the count of bytes that the initiator expects to move.  The 
target only discovers the expected total transfer size implicitly - by way of 
summing all the byte sizes of segments, a task it can complete only by 
fetching all the elements of the page table.

In that context, I'd say making page_size nonzero to tell the device to 
expect a normalized page table is advance, redundant info.

And yes, in general, advance redundant info is useful.  (It's also 
perniciously treacherous, in the case where the advance info is wrong - where 
it doesn't agree with the info that follows.)

 > Apple ... could not identify any reason
 > to bother with the "normalized page table".

Then I wish this feature was absent from the spec.

If I won't give offence, may I ask, was Apple present & voting against 
it?  (I know I wasn't.)

Ironic to find us now speaking with pain of silicon vendors who could not 
identify any reason to bother with the unrestricted page tables.

Thanks again in advance.    Pat LaVarre <p.lavarre at>

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list