All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ilya Yanok <yanok@emcraft.com>,
	"H. Peter Anvin" <h.peter.anvin@intel.com>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"neilb@suse.de" <neilb@suse.de>,
	"Sosnowski, Maciej" <maciej.sosnowski@intel.com>,
	Yuri Tikhonov <yur@emcraft.com>
Subject: Re: [PATCH 06/13] async_tx: add support for asynchronous GF multiplication
Date: Sat, 21 Mar 2009 08:19:26 -0700	[thread overview]
Message-ID: <e9c3a7c20903210819r222cd4acwb466d2a11d3388f6@mail.gmail.com> (raw)
In-Reply-To: <49C45159.8020503@zytor.com>

On Fri, Mar 20, 2009 at 7:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Ilya Yanok wrote:
>>
>> async_gen_syndrome() takes element of GF^n(256) and returns result of
>> scalar multiplication of it with constant ({01}, {02}, {02}^2, ...,
>> {02}^n) vector.
>
> For any n (which would mean any GF field)?  In that case, that is
> generic scalar-vector multiplication...
>
>> async_pq() takes two vectors from GF^n(256) and returns their scalar
>> multiplication.
>>
>> We need async_pq() function if we want to offload D_x = A * (P + P_{xy})
>> + B * (Q + Q_{xy}) part of DD recovery and D_x = (Q + Q_x) * g^{-x} part
>> of DP recovery.
>
>
> No, you don't.  A and B (and g^{-x}) are scalars, meaning they're the
> same for every element.  This is simpler to do.

Understood.  However this routine also needs to cover the non-generic
and non-constant case where we have a separate coefficient per
element.  I suppose it could scan the coefficient list to see if it
can bypass the 2-dimensional lookup multiply.  At the very least we
need something like the following, because async_pq is really only a
helper routine for async_r6recov.c which knows how to avoid the
synchronous path.

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index da47a29..c1087a2 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -236,6 +236,7 @@ async_pq(struct page **blocks, unsigned int
offset, int src_cnt,
                                 flags, depend_tx, cb_fn, cb_param);
        } else {
                /* run pq synchronously */
+               WARN_ONCE(1, "INFO: async_pq entered synchronous path\n");
                if (!blocks[src_cnt+1]) { /* only p requested, just xor */
                        flags |= ASYNC_TX_XOR_ZERO_DST;
                        return async_xor(blocks[src_cnt], blocks, offset,
@@ -252,7 +253,6 @@ async_pq(struct page **blocks, unsigned int
offset, int src_cnt,

        return tx;
 }
-EXPORT_SYMBOL_GPL(async_pq);

Looking closer, the only other caller, async_pq_zero_sum, can be
deleted because it has no users.  So async_pq can become a static
routine in async_r6recov.

Thanks,
Dan

WARNING: multiple messages have this Message-ID (diff)
From: Dan Williams <dan.j.williams@intel.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ilya Yanok <yanok@emcraft.com>,
	"H. Peter Anvin" <h.peter.anvin@intel.com>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"neilb@suse.de" <neilb@suse.de>,
	"Sosnowski, Maciej" <maciej.sosnowski@intel.com>,
	Yuri Tikhonov <yur@emcraft.com>
Subject: Re: [PATCH 06/13] async_tx: add support for asynchronous GF  multiplication
Date: Sat, 21 Mar 2009 08:19:26 -0700	[thread overview]
Message-ID: <e9c3a7c20903210819r222cd4acwb466d2a11d3388f6@mail.gmail.com> (raw)
In-Reply-To: <49C45159.8020503@zytor.com>

On Fri, Mar 20, 2009 at 7:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Ilya Yanok wrote:
>>
>> async_gen_syndrome() takes element of GF^n(256) and returns result of
>> scalar multiplication of it with constant ({01}, {02}, {02}^2, ...,
>> {02}^n) vector.
>
> For any n (which would mean any GF field)?  In that case, that is
> generic scalar-vector multiplication...
>
>> async_pq() takes two vectors from GF^n(256) and returns their scalar
>> multiplication.
>>
>> We need async_pq() function if we want to offload D_x = A * (P + P_{xy})
>> + B * (Q + Q_{xy}) part of DD recovery and D_x = (Q + Q_x) * g^{-x} part
>> of DP recovery.
>
>
> No, you don't.  A and B (and g^{-x}) are scalars, meaning they're the
> same for every element.  This is simpler to do.

Understood.  However this routine also needs to cover the non-generic
and non-constant case where we have a separate coefficient per
element.  I suppose it could scan the coefficient list to see if it
can bypass the 2-dimensional lookup multiply.  At the very least we
need something like the following, because async_pq is really only a
helper routine for async_r6recov.c which knows how to avoid the
synchronous path.

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index da47a29..c1087a2 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -236,6 +236,7 @@ async_pq(struct page **blocks, unsigned int
offset, int src_cnt,
                                 flags, depend_tx, cb_fn, cb_param);
        } else {
                /* run pq synchronously */
+               WARN_ONCE(1, "INFO: async_pq entered synchronous path\n");
                if (!blocks[src_cnt+1]) { /* only p requested, just xor */
                        flags |= ASYNC_TX_XOR_ZERO_DST;
                        return async_xor(blocks[src_cnt], blocks, offset,
@@ -252,7 +253,6 @@ async_pq(struct page **blocks, unsigned int
offset, int src_cnt,

        return tx;
 }
-EXPORT_SYMBOL_GPL(async_pq);

Looking closer, the only other caller, async_pq_zero_sum, can be
deleted because it has no users.  So async_pq can become a static
routine in async_r6recov.

Thanks,
Dan

  parent reply	other threads:[~2009-03-21 15:19 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-18 19:20 [PATCH 00/13] Asynchronous raid6 acceleration (part 1 of 2) Dan Williams
2009-03-18 19:20 ` [PATCH 01/13] md/raid6: move raid6 data processing to raid6_pq.ko Dan Williams
2009-03-19 20:09   ` Andre Noll
2009-03-22 17:22     ` Dan Williams
2009-03-22 17:22       ` Dan Williams
2009-03-18 19:20 ` [PATCH 02/13] async_tx: don't use src_list argument of async_xor() for dma addresses Dan Williams
2009-03-19 20:10   ` Andre Noll
2009-03-25 17:11     ` Dan Williams
2009-03-25 17:11       ` Dan Williams
2009-03-26 10:39       ` Andre Noll
2009-03-18 19:20 ` [PATCH 03/13] async_tx: provide __async_inline for HAS_DMA=n archs Dan Williams
2009-03-18 19:20 ` [PATCH 04/13] async_tx: kill needless module_{init|exit} Dan Williams
2009-03-18 19:20 ` [PATCH 05/13] async_tx: add sum check flags Dan Williams
2009-03-18 19:20 ` [PATCH 06/13] async_tx: add support for asynchronous GF multiplication Dan Williams
2009-03-19 16:06   ` H. Peter Anvin
2009-03-19 17:20     ` Dan Williams
2009-03-19 17:20       ` Dan Williams
2009-03-20 22:43       ` H. Peter Anvin
2009-03-20 23:00         ` Ilya Yanok
2009-03-20 23:25           ` H. Peter Anvin
2009-03-21  0:06             ` Ilya Yanok
2009-03-21  2:30               ` H. Peter Anvin
2009-03-21 10:19                 ` Ilya Yanok
2009-03-21 19:16                   ` H. Peter Anvin
2009-03-21 15:19                 ` Dan Williams [this message]
2009-03-21 15:19                   ` Dan Williams
2009-03-21 19:15                   ` H. Peter Anvin
2009-03-21 22:14                     ` Dan Williams
2009-03-21 22:14                       ` Dan Williams
2009-03-21 22:26                       ` Ilya Yanok
2009-03-21 22:46                         ` Dan Williams
2009-03-21 22:46                           ` Dan Williams
2009-03-21 20:05     ` Ilya Yanok
2009-03-21 22:00       ` Dan Williams
2009-03-21 22:00         ` Dan Williams
2009-03-21 22:43         ` Ilya Yanok
2009-03-21 22:53           ` Dan Williams
2009-03-21 22:53             ` Dan Williams
2009-03-22 21:37             ` Ilya Yanok
2009-03-19 20:09   ` Andre Noll
2009-03-30 14:30   ` Sosnowski, Maciej
2009-03-18 19:20 ` [PATCH 07/13] async_tx: add support for asynchronous RAID6 recovery operations Dan Williams
2009-03-23 10:11   ` Andre Noll
2009-03-30 14:30   ` Sosnowski, Maciej
2009-03-18 19:20 ` [PATCH 08/13] iop-adma: P+Q support for iop13xx adma engines Dan Williams
2009-03-18 19:21 ` [PATCH 09/13] iop-adma: P+Q self test Dan Williams
2009-03-20  0:14   ` Neil Brown
2009-03-20  0:19     ` Dan Williams
2009-03-20  0:19       ` Dan Williams
2009-03-30 14:30   ` Sosnowski, Maciej
2009-03-18 19:21 ` [PATCH 10/13] dmaengine: allow dma support for async_tx to be toggled Dan Williams
2009-03-18 19:21 ` [PATCH 11/13] dmatest: add xor test Dan Williams
2009-03-18 19:21 ` [PATCH 12/13] dmatest: add dma interrupts and callbacks Dan Williams
2009-03-18 19:21 ` [PATCH 13/13] dmatest: add pq support Dan Williams
2009-03-18 23:43 ` [PATCH 00/13] Asynchronous raid6 acceleration (part 1 of 2) Andi Kleen
2009-03-19 17:08   ` Dan Williams
2009-03-19 17:08     ` Dan Williams
2009-03-20  0:30 ` Neil Brown

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=e9c3a7c20903210819r222cd4acwb466d2a11d3388f6@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=h.peter.anvin@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=maciej.sosnowski@intel.com \
    --cc=neilb@suse.de \
    --cc=yanok@emcraft.com \
    --cc=yur@emcraft.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.