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