ide prd table size

ide prd table size

[Gerald Champagne]

I have a question about the calculation of the PRD_ENTRIES constant used
in the ide code  The documentation for the size of PRD_ENTRIES says
this:
-----------------------------
/*
Our Physical Region Descriptor (PRD) table should be large enough to
handle the biggest I/O request we are likely to see.  Since requests can
have no more than 256 sectors, and since the typical blocksize is two or
more sectors, we could get by with a limit of 128 entries here for the
usual worst case.  Most requests seem to include some contiguous blocks,
further reducing the number of table entries required.

As it turns out though, we must allocate a full 4KB page for this, so
the two PRD tables (ide0 & ide1) will each get half of that, allowing
each to have about 256 entries (8 bytes each) from this.
*/
#define PRD_BYTES	8
#define PRD_ENTRIES	(PAGE_SIZE / (2 * PRD_BYTES))
-----------------------------


This looks a little outdated, but I'm interested in the second
paragraph.  I don't see where multiple interfaces are sharing the same
page.  The documentation here and for pci_alloc_consistent says that
blocks are allocated in full pages.  This implies that the unused
portion is wasted.

So...

- Is the code wasting half of the page, and should PRD_ENTRIES be
redefined to be larger?

- Am I misunderstanding the documentation, and is the other half of the
page used somewhere else?

- Am I misunderstanding the code, and do multiple interfaces share the
page?

- Should this be modified to use the pci_pool interface as defined in
DMA-mapping.txt?

Thanks!

Gerald

Re: ide prd table size

[Marcin Dalecki]

Użytkownik Gerald Champagne napisał:
> I have a question about the calculation of the PRD_ENTRIES constant used
> in the ide code  The documentation for the size of PRD_ENTRIES says
> this:
> -----------------------------
> /*
> Our Physical Region Descriptor (PRD) table should be large enough to
> handle the biggest I/O request we are likely to see.  Since requests can
> have no more than 256 sectors, and since the typical blocksize is two or
> more sectors, we could get by with a limit of 128 entries here for the
> usual worst case.  Most requests seem to include some contiguous blocks,
> further reducing the number of table entries required.
> 
> As it turns out though, we must allocate a full 4KB page for this, so
> the two PRD tables (ide0 & ide1) will each get half of that, allowing
> each to have about 256 entries (8 bytes each) from this.
> */
> #define PRD_BYTES	8
> #define PRD_ENTRIES	(PAGE_SIZE / (2 * PRD_BYTES))
> -----------------------------
> 
> 
> This looks a little outdated, but I'm interested in the second
> paragraph.  I don't see where multiple interfaces are sharing the same
> page.  The documentation here and for pci_alloc_consistent says that
> blocks are allocated in full pages.  This implies that the unused
> portion is wasted.
> 
> So...
> 
> - Is the code wasting half of the page, and should PRD_ENTRIES be
> redefined to be larger?
> 
> - Am I misunderstanding the documentation, and is the other half of the
> page used somewhere else?
> 
> - Am I misunderstanding the code, and do multiple interfaces share the
> page?
> 
> - Should this be modified to use the pci_pool interface as defined in
> DMA-mapping.txt?
> 
> Thanks!

Well the documentation is a bit inadequate.
The reality is a bit more complicated and reveals if you look at the
actual usage pattern:

1. Two drives on a channel share them.
2. primary and secondary channel are tightly coupled by the
    host controller hardware (in esp the PIIX) and have to
    be allocated in one go.
3. Some host controllers don't like it if you really use the last entry.
4. trm380 can deal with much more then anybody else.

Re: ide prd table size

[Gerald Champagne]

On Sat, 2002-08-03 at 18:32, Marcin Dalecki wrote:
> Well the documentation is a bit inadequate.
> The reality is a bit more complicated and reveals if you look at the
> actual usage pattern:
> 
> 1. Two drives on a channel share them.
> 2. primary and secondary channel are tightly coupled by the
>     host controller hardware (in esp the PIIX) and have to
>     be allocated in one go.

The comments say that happens, but it doesn't.  Here's the code as I see
it:

- setup_pci_device calls setup_host_channel once for ATA_PRIMARY and
once for ATA_SECONDARY.

- setup_host_channel calls setup_channel_dma, which calls the host-
specific dma init routine, which calls ata_init_dma.

- The routine ata_init_dma allocates the prd table.  It says that it
will allocate enough room for the primary and secondary interface.  In
reality, it allocates a page of memory for a table when called for the
primary controller and uses half of it.  Then it does the same thing
when called for the secondary controller.  Two different tables are
defined separately with no guarantees about their placement, and neither
interface uses the other table at all.

None of this is a big issue, but with the new code that constant is
exported to the bio code and it's not just an internal definition in the
ide driver any more.  Since that constant is now a little more
important, I think it should have a little more accurate definition.  Or
at least a little more accurate description if the number happens to
remain the same.

Thanks.

Gerald