public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: adam@yggdrasil.com
Cc: akpm@zip.com.au, axboe@suse.de, linux-kernel@vger.kernel.org
Subject: Re: RFC: turn scatterlist into a linked list, eliminate bio_vec
Date: Mon, 24 Jun 2002 05:39:15 -0700 (PDT)	[thread overview]
Message-ID: <20020624.053915.132743979.davem@redhat.com> (raw)
In-Reply-To: <200206241142.EAA04136@adam.yggdrasil.com>

   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.

  reply	other threads:[~2002-06-24 12:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-24 11:42 RFC: turn scatterlist into a linked list, eliminate bio_vec Adam J. Richter
2002-06-24 12:39 ` David S. Miller [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-06-25 21:27 Adam J. Richter
2002-06-25 14:35 Adam J. Richter
2002-06-24 20:44 Adam J. Richter
2002-06-25 13:58 ` David S. Miller
2002-06-23 23:58 Adam J. Richter
2002-06-24  6:24 ` David S. Miller
2002-06-24 19:29 ` William Lee Irwin III

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020624.053915.132743979.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=adam@yggdrasil.com \
    --cc=akpm@zip.com.au \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox