From: "Adam J. Richter" <adam@yggdrasil.com>
Date: Mon, 24 Jun 2002 04:42:45 -0700
Sorry if I was not clear enough about the purpose of of
the new scatterlist->driver_priv field. It is a "streaming" data
structure to use the terminology of DMA-maping.txt (i.e., one that
would typically only be allocated for a few microseconds as an IO is
built up and sent). Its purpose is to hold the hardware-specific
gather-scatter segment descriptor, which typically look something like this:
struct foo_corporation_scsi_controller_sg_element {
u64 data_addr;
u64 next_addr;
u16 data_len;
u16 reserved;
u32 various_flags;
}
This is small, about one cacheline, and thus is not to be used
with non-consistent memory. Also, if you use streaming memory, where
is the structure written to and where is the pci_dma_sync_single
(which is a costly cache flush on many systems btw, another reason to
use consistent memory) between the CPU writes and giving the
descriptor to the device?
Again, reread DMA-mapping.txt a few more times before composing
your response to me. I really meant that you don't understand
the purpose of consistent vs. streaming memory.
Come to think of it, my use of pci_map_single is incorrect
after all, because the driver has not yet filled in that data structure
at that point. Since the data structures are being allocated from a
single contiguous block that spans a couple of pages that is being used
only for this purpose, perhaps I would be fastest to pci_alloc_consistent
the whole memory pool for those little descriptors at initialization time
and then change that loop to do the following.
Please use PCI pools, this is what they were designed for. Pools of
like-sized objects allocated out of consistent DMA memory.
So as it stands I still think your proposal is buggy.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 30 2002 - 22:00:07 EST