stds-1394: empirical character of SBP2 scatter/gather lists?

Pat LaVarre lavarre at IOMEGA.COM
Tue Jun 26 17:46:22 PDT 2001


> 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




More information about the T10 mailing list