From: boaz@plexistor.com (Boaz Harrosh)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/8] ARM: mvebu: Add support for RAID6 PQ offloading
Date: Wed, 27 May 2015 14:52:34 +0300 [thread overview]
Message-ID: <5565B002.5090404@plexistor.com> (raw)
In-Reply-To: <CAPcyv4i06Mwis_CSrKV1Yo6crD1vrjb9it6RtYdtwbgOOY9a4g@mail.gmail.com>
On 05/26/2015 07:31 PM, Dan Williams wrote:
> [ adding Boaz as this discussion has implications for ore_raid ]
>
<>
>> You're not talking about deprecating it, you're talking about removing
>> it entirely.
>
> True, and adding more users makes that removal more difficult. I'm
> willing to help out on the design and review for this work, I just
> can't commit to doing the implementation and testing.
>
<>
Hi
So for ore_raid, Yes it uses both xor and pq functions, and I expect
that to work also after the API changes.
That said, I never really cared for the HW offload engines of these
APIs. Actually I never met any. On a modern machine I always got
the DCE/MMX kick in or one of the other CPU variants. With preliminary
testing of XOR I got an almost memory speed for xor (read n pages
+ write one) So with multy-core CPUs I fail to see how an HW do
better, memory caching and all. The PQ was not that far behind.
All I need is an abstract API that gives me the best implementation
on any ARCH / configuration. Actually the async_tx API is a pain
and a sync API would make things simple. I do not use the concurrent
async submit, wait later at all. I submit then wait.
So anything you change this to, as long as you keep the wonderful
dce implementation is good with me, just that the code keeps running
after the new API is fine with me.
(And the common structures between XOR and PQ was also nice, but I
can also use a union, its always either or in ore_raid)
Once you make API changes and modify code, CC me I'll run tests
good luck
Boaz
next prev parent reply other threads:[~2015-05-27 11:52 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-12 15:37 [PATCH 0/8] ARM: mvebu: Add support for RAID6 PQ offloading Maxime Ripard
2015-05-12 15:37 ` [PATCH 1/8] dmaengine: mv_xor: Rename function for consistent naming Maxime Ripard
2015-05-12 15:37 ` [PATCH 2/8] dmaengine: mv_xor: add support for a38x command in descriptor mode Maxime Ripard
2015-05-12 15:49 ` Arnd Bergmann
2015-05-12 15:54 ` Thomas Petazzoni
2015-05-12 16:03 ` Arnd Bergmann
2015-05-13 8:15 ` Maxime Ripard
2015-05-13 8:46 ` Arnd Bergmann
2015-05-12 15:49 ` Thomas Petazzoni
2015-05-12 15:58 ` Andrew Lunn
2015-05-12 16:05 ` Thomas Petazzoni
2015-05-13 8:23 ` Maxime Ripard
2015-05-12 15:37 ` [PATCH 3/8] dmaengine: mv_xor: Enlarge descriptor pool size Maxime Ripard
2015-05-12 15:37 ` [PATCH 4/8] dmaengine: mv_xor: improve descriptors list handling and reduce locking Maxime Ripard
2015-05-12 15:37 ` [PATCH 5/8] dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup Maxime Ripard
2015-05-12 15:51 ` Thomas Petazzoni
2015-05-12 15:37 ` [PATCH 6/8] async_tx: adding mult and sum_product flags Maxime Ripard
2015-05-12 16:05 ` Andrew Lunn
2015-05-13 8:45 ` Maxime Ripard
2015-05-12 15:37 ` [PATCH 7/8] dmaengine: mv_xor: add support for a38x RAID6 support Maxime Ripard
2015-05-12 15:37 ` [PATCH 8/8] ARM: mvebu: a38x: Enable A38x XOR engine features Maxime Ripard
2015-05-12 16:13 ` Andrew Lunn
2015-05-13 7:16 ` Lior Amsalem
2015-05-13 8:33 ` Maxime Ripard
2015-05-12 16:05 ` [PATCH 0/8] ARM: mvebu: Add support for RAID6 PQ offloading Dan Williams
2015-05-13 9:17 ` Maxime Ripard
2015-05-13 16:00 ` Dan Williams
2015-05-18 9:14 ` Maxime Ripard
2015-05-18 17:06 ` Dan Williams
2015-05-26 9:45 ` Maxime Ripard
2015-05-26 16:31 ` Dan Williams
2015-05-27 11:52 ` Boaz Harrosh [this message]
2015-06-02 14:41 ` Maxime Ripard
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=5565B002.5090404@plexistor.com \
--to=boaz@plexistor.com \
--cc=linux-arm-kernel@lists.infradead.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).