linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Rajasekhar Pulluru <pullururajasekhar@gmail.com>
Cc: linux-raid@vger.kernel.org, NeilBrown <neilb@suse.de>,
	Russell King <rmk@arm.linux.org.uk>
Subject: Re: async_tx and RAID HW xor engine
Date: Mon, 30 Apr 2012 13:31:41 -0700	[thread overview]
Message-ID: <CAA9_cmc0eEW-vjAuoj-ZnbX3vOrpswjVXU-NDw_rSSxqwvpU_w@mail.gmail.com> (raw)
In-Reply-To: <CAGA5_H55asVEekOd1ae2OjkK07W5Okf1iTCg10oRSX4+M7FLEA@mail.gmail.com>

[ adding Russell and Neil for comment about the proposed change to async_tx ]

On Mon, Apr 30, 2012 at 3:05 AM, Rajasekhar Pulluru
<pullururajasekhar@gmail.com> wrote:
> Hi,
>
> I am trying to understand how are hardware xor engine's utilized by
> async_tx module. I don't get the exact link that connects async_tx and
> hardware xor engine.
> Could someone help me understand it.
>
> Registration of a RAID HW XOR engine happens in
> drivers/dma/<soc-xor.c> using dma_async_device_register(). Does this
> registration function connect the async_tx api's
> to use the HW XOR engine?

Yes, the channel registers its capabilities with dmaengine, and then
async_tx asks dmaengine (via dma_find_channel) for a resource to carry
out the operation(s).

> Or is there anything we need to support to
> make async_tx api's to take advantage of the hardware XOR engine?

Registration with dma engine should be all that is needed, but a word
of caution that the channel switching mechanism has been found to be
incompatible with the dma mapping api.  So, unless your dma channel
supports all the operations needed for raid, do not rely on async_tx's
channel switching capabilities.

An architecture where this is known to be a problem is ARM, but I
wonder if we should take the following global step until this is fixed
properly?

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index cf9da36..b812b6b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -280,6 +280,7 @@ config NET_DMA
 config ASYNC_TX_DMA
        bool "Async_tx: Offload support for the async_tx api"
        depends on DMA_ENGINE
+       depends on !ASYNC_TX_ENABLE_CHANNEL_SWITCH
        help
          This allows the async_tx api to take advantage of offload engines for
          memcpy, memset, xor, and raid6 p+q operations.  If your platform has

  reply	other threads:[~2012-04-30 20:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-30 10:05 async_tx and RAID HW xor engine Rajasekhar Pulluru
2012-04-30 20:31 ` Dan Williams [this message]
2012-05-01  0:49   ` NeilBrown
2012-05-02 19:11     ` Dan Williams

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=CAA9_cmc0eEW-vjAuoj-ZnbX3vOrpswjVXU-NDw_rSSxqwvpU_w@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=pullururajasekhar@gmail.com \
    --cc=rmk@arm.linux.org.uk \
    /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).