diff for duplicates of <1115054880.20081127042629@emcraft.com> diff --git a/a/1.txt b/N1/1.txt index 91b4e60..3715582 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,5 +1,4 @@ - - Hello Dan, +=0D=0A Hello Dan, On Saturday, November 15, 2008 you wrote: @@ -10,12 +9,12 @@ On Saturday, November 15, 2008 you wrote: > 1/ I don't see code for handling cases where the src_cnt exceeds the > hardware maximum. - Right, actually the ADMA devices we used (ppc440spe DMA engines) has -no limitations on the src_cnt (well, actually there is the limit - the -size of descriptors FIFO, but it's more than the number of drives -which may be handled with the current RAID-6 driver, i.e. > 256), but -I agree - the ASYNC_TX functions should not assume that any ADMA -device will have such a feature. So we'll implement this, and then + Right, actually the ADMA devices we used (ppc440spe DMA engines) has=20 +no limitations on the src_cnt (well, actually there is the limit - the=20 +size of descriptors FIFO, but it's more than the number of drives=20 +which may be handled with the current RAID-6 driver, i.e. > 256), but=20 +I agree - the ASYNC_TX functions should not assume that any ADMA=20 +device will have such a feature. So we'll implement this, and then=20 re-post the patches. > 2/ dmaengine.h defines DMA_PQ_XOR but these patches should really @@ -27,23 +26,28 @@ re-post the patches. > 3/ In my implementation (unfinished) of async_pq I decided to make the > prototype: - May I ask do you have in plans to finish and release your + May I ask do you have in plans to finish and release your=20 implementation? > +/** -> + * async_pq - attempt to generate p (xor) and q (Reed-Solomon code) with a -> + * dma engine for a given set of blocks. This routine assumes a field of -> + * GF(2^8) with a primitive polynomial of 0x11d and a generator of {02}. +> + * async_pq - attempt to generate p (xor) and q (Reed-Solomon code) with= + a +> + * dma engine for a given set of blocks. This routine assumes a fie= +ld of +> + * GF(2^8) with a primitive polynomial of 0x11d and a generator of {= +02}. > + * In the synchronous case the p and q blocks are used as temporary > + * storage whereas dma engines have their own internal buffers. The > + * ASYNC_TX_PQ_ZERO_P and ASYNC_TX_PQ_ZERO_Q flags clear the > + * destination(s) before they are used. -> + * @blocks: source block array ordered from 0..src_cnt with the p destination +> + * @blocks: source block array ordered from 0..src_cnt with the p destin= +ation > + * at blocks[src_cnt] and q at blocks[src_cnt + 1] -> + * NOTE: client code must assume the contents of this array are destroyed +> + * NOTE: client code must assume the contents of this array are dest= +royed > + * @offset: offset in pages to start transaction -> + * @src_cnt: number of source pages: 2 < src_cnt <= 255 +> + * @src_cnt: number of source pages: 2 < src_cnt <=3D 255 > + * @len: length in bytes > + * @flags: ASYNC_TX_ACK, ASYNC_TX_DEP_ACK > + * @depend_tx: p+q operation depends on the result of this transaction. @@ -51,8 +55,10 @@ implementation? > + * @cb_param: parameter to pass to the callback routine > + */ > +struct dma_async_tx_descriptor * -> +async_pq(struct page **blocks, unsigned int offset, int src_cnt, size_t len, -> + enum async_tx_flags flags, struct dma_async_tx_descriptor *depend_tx, +> +async_pq(struct page **blocks, unsigned int offset, int src_cnt, size_t = +len, +> + enum async_tx_flags flags, struct dma_async_tx_descriptor *depen= +d_tx, > + dma_async_tx_callback cb_fn, void *cb_param) > Where p and q are not specified separately. This matches more closely @@ -60,10 +66,10 @@ implementation? > requiring any changes to existing software raid6 interface. > Thoughts? - Understood. Our goal was to be more close to the ASYNC_TX interfaces, -so we specified the destinations separately. Though I'm fine with your -prototype, since doubling the same address is no good, so, we'll -change this. + Understood. Our goal was to be more close to the ASYNC_TX interfaces,=20 +so we specified the destinations separately. Though I'm fine with your=20 +prototype, since doubling the same address is no good, so, we'll=20 +change this.=20 Any comments regarding the drivers/md/raid5.c part ? diff --git a/a/content_digest b/N1/content_digest index 2561962..3ed9af0 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -12,8 +12,7 @@ " Ilya Yanok <yanok@emcraft.com>\0" "\00:1\0" "b\0" - "\n" - " Hello Dan,\n" + "=0D=0A Hello Dan,\n" "\n" "On Saturday, November 15, 2008 you wrote:\n" "\n" @@ -24,12 +23,12 @@ "> 1/ I don't see code for handling cases where the src_cnt exceeds the\n" "> hardware maximum.\n" "\n" - " Right, actually the ADMA devices we used (ppc440spe DMA engines) has \n" - "no limitations on the src_cnt (well, actually there is the limit - the \n" - "size of descriptors FIFO, but it's more than the number of drives \n" - "which may be handled with the current RAID-6 driver, i.e. > 256), but \n" - "I agree - the ASYNC_TX functions should not assume that any ADMA \n" - "device will have such a feature. So we'll implement this, and then \n" + " Right, actually the ADMA devices we used (ppc440spe DMA engines) has=20\n" + "no limitations on the src_cnt (well, actually there is the limit - the=20\n" + "size of descriptors FIFO, but it's more than the number of drives=20\n" + "which may be handled with the current RAID-6 driver, i.e. > 256), but=20\n" + "I agree - the ASYNC_TX functions should not assume that any ADMA=20\n" + "device will have such a feature. So we'll implement this, and then=20\n" "re-post the patches.\n" "\n" "> 2/ dmaengine.h defines DMA_PQ_XOR but these patches should really\n" @@ -41,23 +40,28 @@ "> 3/ In my implementation (unfinished) of async_pq I decided to make the\n" "> prototype:\n" "\n" - " May I ask do you have in plans to finish and release your \n" + " May I ask do you have in plans to finish and release your=20\n" "implementation?\n" "\n" "\n" "> +/**\n" - "> + * async_pq - attempt to generate p (xor) and q (Reed-Solomon code) with a\n" - "> + * dma engine for a given set of blocks. This routine assumes a field of\n" - "> + * GF(2^8) with a primitive polynomial of 0x11d and a generator of {02}.\n" + "> + * async_pq - attempt to generate p (xor) and q (Reed-Solomon code) with=\n" + " a\n" + "> + * dma engine for a given set of blocks. This routine assumes a fie=\n" + "ld of\n" + "> + * GF(2^8) with a primitive polynomial of 0x11d and a generator of {=\n" + "02}.\n" "> + * In the synchronous case the p and q blocks are used as temporary\n" "> + * storage whereas dma engines have their own internal buffers. The\n" "> + * ASYNC_TX_PQ_ZERO_P and ASYNC_TX_PQ_ZERO_Q flags clear the\n" "> + * destination(s) before they are used.\n" - "> + * @blocks: source block array ordered from 0..src_cnt with the p destination\n" + "> + * @blocks: source block array ordered from 0..src_cnt with the p destin=\n" + "ation\n" "> + * at blocks[src_cnt] and q at blocks[src_cnt + 1]\n" - "> + * NOTE: client code must assume the contents of this array are destroyed\n" + "> + * NOTE: client code must assume the contents of this array are dest=\n" + "royed\n" "> + * @offset: offset in pages to start transaction\n" - "> + * @src_cnt: number of source pages: 2 < src_cnt <= 255\n" + "> + * @src_cnt: number of source pages: 2 < src_cnt <=3D 255\n" "> + * @len: length in bytes\n" "> + * @flags: ASYNC_TX_ACK, ASYNC_TX_DEP_ACK\n" "> + * @depend_tx: p+q operation depends on the result of this transaction.\n" @@ -65,8 +69,10 @@ "> + * @cb_param: parameter to pass to the callback routine\n" "> + */\n" "> +struct dma_async_tx_descriptor *\n" - "> +async_pq(struct page **blocks, unsigned int offset, int src_cnt, size_t len,\n" - "> + enum async_tx_flags flags, struct dma_async_tx_descriptor *depend_tx,\n" + "> +async_pq(struct page **blocks, unsigned int offset, int src_cnt, size_t =\n" + "len,\n" + "> + enum async_tx_flags flags, struct dma_async_tx_descriptor *depen=\n" + "d_tx,\n" "> + dma_async_tx_callback cb_fn, void *cb_param)\n" "\n" "> Where p and q are not specified separately. This matches more closely\n" @@ -74,10 +80,10 @@ "> requiring any changes to existing software raid6 interface.\n" "> Thoughts?\n" "\n" - " Understood. Our goal was to be more close to the ASYNC_TX interfaces, \n" - "so we specified the destinations separately. Though I'm fine with your \n" - "prototype, since doubling the same address is no good, so, we'll \n" - "change this. \n" + " Understood. Our goal was to be more close to the ASYNC_TX interfaces,=20\n" + "so we specified the destinations separately. Though I'm fine with your=20\n" + "prototype, since doubling the same address is no good, so, we'll=20\n" + "change this.=20\n" "\n" " Any comments regarding the drivers/md/raid5.c part ?\n" "\n" @@ -87,4 +93,4 @@ " Yuri Tikhonov, Senior Software Engineer\n" Emcraft Systems, www.emcraft.com -a321e977f0d18ee4011be884770ce97ff58226a70383b34680e18f46581b3a79 +01b24b895ebd3870f58048ed4b456719b18d22bc09fecae4e29f8a0a3320958f
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.