linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: linux-raid@vger.kernel.org,
	Device mapper devel list <dm-devel@redhat.com>,
	Jens Axboe <axboe@suse.de>
Subject: Re: [RFC] Hardware RAID offload
Date: Mon, 12 Jul 2004 13:09:07 +0100	[thread overview]
Message-ID: <1089634146.11248.6.camel@localhost.localdomain> (raw)
In-Reply-To: <40F1A04E.8070105@pobox.com>

On Sul, 2004-07-11 at 21:17, Jeff Garzik wrote:
> 1) Transaction sequencing.  Consider that N disk transactions comprise a 
> single RAID1 write.  The hardware can be set up to wait until all N 
> transactions are complete, before sending an interrupt.  This is 
> applicable to Marvell and Promise SATA, among others.

So this is basically IRQ mitigation. Can you flip the "cause an IRQ"
status on the fly ?

> 2) Copy elimination.  All disk transactions on the Promise SX4 go 
> through an on-board DIMM (128M - 2G), before being sent to the attached 
> controllers.  I would love to use this to eliminate data duplication on 
> RAID1 and RAID5 writes.

Big win for PCI cards because it cuts PCI bandwidth way down. It
doesn't seem like it should be that hard to add to the drivers either
depending upon how the RAM is presented. Is it mapped into PCI space ?

> Or maybe, allow the user to set a flag that tells md to pass a request 
> directly through to the low-level driver, in certain situations ("pass 
> through all RAID1 writes, but handle everything else in software").  /me 
> thinks out loud...

As some kind of driver "md_ops" or as a separate raid1-promise plugin ?



      reply	other threads:[~2004-07-12 12:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-11 20:17 [RFC] Hardware RAID offload Jeff Garzik
2004-07-12 12:09 ` Alan Cox [this message]

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=1089634146.11248.6.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=axboe@suse.de \
    --cc=dm-devel@redhat.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-raid@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;
as well as URLs for NNTP newsgroup(s).