empirical character of SBP2 scatter/gather lists?

Pat LaVarre lavarre at iomega.com
Tue Jun 26 17:46:22 PDT 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <lavarre at iomega.com>
*
 > mailto:stds-1394 at majordomo.ieee.org

Hey, hi, has anyone here already dug into the empirical character of ORBs?

How about in particular the actual content of the theoretically "unrestricted 
page table"s to which ORBs point?  I ask because me, glancing over bus 
traces, I'm seeing both More and Less variety than I knew to expect in page 
tables.

Me, I first learned to spell FireWire about three weeks ago.  Now I'm looking 
to connect with less clueless folk, hoping to provoke you to share your 
history of pain and thereby shortcut my learning curve.  Me, I'm trying to 
make sense of actual bus traces.

I'm wondering how completely I have misunderstood what's going on in how the 
popular shipping operating systems actually manage the virtual memory 
involved in block i/o?

Me, I had the idea that block i/o involved a length of blocks at a virtual 
address.  This virtual memory, once pinned, would appear in physical memory 
as a leading fragment of a page, then a series of whole pages, then a 
trailing fragment.

Offline two different volunteers told me my summary is none too clear, so 
let's try a specific example.  Given a block device that stores x200 (512) 
bytes per block and a host that allocates physical memory in chunks of x1000 
(4096) bytes each, I thought I might someday see the scatter/gather list for 
a physically fragmented, but virtually contiguous, region of memory look 
something like:

         for a total of ,........... x3400 bytes

         from address x1234:5FFF for x0001 bytes
         from address x6789:A000 for x1000 bytes
         from address xBCDE:F000 for x2000 bytes
         from address x0123:4000 for x03FF bytes

A scatter/gather list like this has LOS of structure.

All but the first fragment begins at a x1000-byte boundary.  All but the last 
fragment ends at a x1000-byte boundary.  The byte length of any middle 
fragment is a multiple of x1000.  The sum of the lengths of the first and 
last fragments is a multiple of x200 bytes.  Like I said, LOTS of structure.

But the scatter/gather lists (aka "unrestricted page table"s) that I see in 
actual bus traces of 1394 sbp2 traffic have both less and more structure than 
this example.

In particular, I see four surprises ...

1) I see more structure than I expect:

Some hosts seemingly enforce a less than minimal alignment: every starting 
"segment_base" address appears as a multiple of x10 and correspondingly every 
byte length ends up a multiple of x10.  I imagine somebody out there is 
double-buffering.

WHERE in CSR space does the device get to share its opinion of what optimal 
double-buffering is?

2) I see less structure than I expect:

I've heard on some hosts the virtual memory page size is x1000 bytes 
(4KB).  Indisputably (log2(x1000) - 8) is 4.  But the "page_size" fields of 
the ORB's I see isn't 4: it is 0.  Somebody out there wants to say I'll be 
seeing "unrestricted page table"s?

WHY favour "unrestricted page table"s?

WHERE in CSR space does the device get to express its preference for 
restricted page tables?

3) Less structure than I expect:

Smack in the middle of an sbp2 page table, on occasion, I see 
"segment_length"s that are not multiples of x1000.

HOW can an app make that happen?

4) Less structure than I expect:

I see a variety of "max_payload" values in the ORBs.  I think I understand 
the "max_payload" value, if small, can tell the device to subdivide access of 
even a single element of a page table.

As the "max_payload" value, mostly I see 7 to 9, where I was expecting to see 
xA i.e. (log2(x1000) - 2).

 > mailto:sbp3 at isg.apple.com

Please tell me if I'd do better to ask there, rather than here (t10 at t10.org).

Thanks in advance.    PatLaVarre 

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




More information about the T10 mailing list