dmatest: masking tests for channel capabilities
Subsystems (2)
PATCH 1/1 dmatest: masking tests for channel capabilities
The current dmatest module tests all the hardware capabilities (MEMCPY, XOR and PQ) supported by a particular DMA channel and these tests are performed concurrently by default. This patch allows the user to enable or disable the test performed for any particular capability. The mask bits for enabling the tests are set using the debugfs.
--- Documentation/dmatest.txt | 32 ++++++++++++++++++++++++++++++++ drivers/dma/dmatest.c | 41 ++++++++++++++++++++++++++++++++++++++--- 2 files changed, 70 insertions(+), 3 deletions(-)
Documentation/dmatest.txt +32 -0
@@ -79,3 +79,35 @@ Comparison between buffers is stored to the dedicated structure. Note that the verify result is now accessible only via file 'results' in the debugfs. + + Part 5 - Masking tests for channel capabilities + +By default, the dmatest module concurrently tests all the hardware capabilities +(MEMCPY, XOR and PQ) supported by a particular DMA channel. In order to disable +any capability/capabilities from being tested, the user needs to modify the +file 'cap_mask' in debugfs. + +Method to enable the capabilities: + +PATH = /sys/kernel/debug/dmatest/cap_mask +(DEFAULT) echo 0x07 > $PATH // Set Bits 0,1,2 for MEMCPY, XOR and PQ + echo 0x01 > $PATH // Set bit 0 to enable MEMCPY + echo 0x02 > $PATH // Set bit 1 to enable XOR + echo 0x04 > $PATH // Set bit 2 to enable PQ + +Example to perform only MEMCPY and PQ mode tests (0x01 | 0x04 = 0x05): + + % modprobe dmatest + % echo dma0chan0 > /sys/kernel/debug/dmatest/channel + % echo 5 > /sys/kernel/debug/dmatest/cap_mask + % echo 1 > /sys/kernel/debug/dmatest/iterations + % echo 1 > /sys/kernel/debug/dmatest/run + + Output: + % cat /sys/kernel/debug/dmatest/results + + dma0chan0-copy0: #1: No errors with src_off=0xXX dst_off=0xXX len=0xXX + dma0chan0-pq0: #1: No errors with src_off=0xXX dst_off=0xXX len=0xXX + +Note that the result is available only for the enabled capabilities of +particular channel.
drivers/dma/dmatest.c +38 -3
96 lines not on this page · raw message
Signature · 1 line
1.7.9.5
Quoted 5 lines · Jubin Mehta
The current dmatest module tests all the hardware capabilities (MEMCPY, XOR and PQ) supported by a particular DMA channel and these tests are performed concurrently by default. This patch allows the user to enable or disable the test performed for any particular capability. The mask bits for enabling the tests are set using the debugfs.
This approach I like better.
Dan, Vinod, what is your opinion?
I have couple of comments below.
Documentation/dmatest.txt Comparison between buffers is stored to the dedicated structure. · line 96
Quoted 9 lines
+++
b/Documentation/dmatest.txtDocumentation/dmatest.txt +7
-0+Method to enable the capabilities: + +PATH = /sys/kernel/debug/dmatest/cap_mask +(DEFAULT) echo 0x07 > $PATH // Set Bits 0,1,2 for MEMCPY, XOR and PQ + echo 0x01 > $PATH // Set bit 0 to enable MEMCPY + echo 0x02 > $PATH // Set bit 1 to enable XOR + echo 0x04 > $PATH // Set bit 2 to enable PQ
What if we make examples followed by # and comments? And move (DEFAULT) to the commentary.
Quoted 4 lines
+++
b/drivers/dma/dmatest.cdrivers/dma/dmatest.c +2
-0+/* +* Capability Mask Bits.The bits in the cap_mask denote the masking of
drivers/dma/dmatest.c line 38
Quoted 10 lines
drivers/dma/dmatest.c +10
-0+* the hardware capabilities of the dma channel. +* +* DMA_CAP_MEMCPY: Bit 0 for enabling DMA_MEMCPY capability +* DMA_CAP_XOR: Bit 1 for enabling DMA_XOR capabilit +* DMA_CAP_PQ: Bit 2 for enabling DMA_PQ capability +* DMA_CAP_ALL: Enable all the capabilities of the channel +*/ +#define DMA_CAP_MEMCPY (1 << 0) +#define DMA_CAP_XOR (1 << 1) +#define DMA_CAP_PQ (1 << 2)
Can we reuse DMA_MEMCPY and so on from enum dma_transaction_type?
--
With Best Regards,
Andy Shevchenko
Quoted 9 lines · Andy Shevchenko
Quoted 5 lines · Jubin Mehta
The current dmatest module tests all the hardware capabilities (MEMCPY, XOR and PQ) supported by a particular DMA channel and these tests are performed concurrently by default. This patch allows the user to enable or disable the test performed for any particular capability. The mask bits for enabling the tests are set using the debugfs.
This approach I like better.
Dan, Vinod, what is your opinion?
I withdraw my path in favor of this one.
Thanks,
Jon
Quoted 35 lines
I have couple of comments below.
Documentation/dmatest.txt Comparison between buffers is stored to the dedicated structure. · line 96
Quoted 9 lines
+++
b/Documentation/dmatest.txtDocumentation/dmatest.txt +7
-0+Method to enable the capabilities: + +PATH = /sys/kernel/debug/dmatest/cap_mask +(DEFAULT) echo 0x07 > $PATH // Set Bits 0,1,2 for MEMCPY, XOR and PQ + echo 0x01 > $PATH // Set bit 0 to enable MEMCPY + echo 0x02 > $PATH // Set bit 1 to enable XOR + echo 0x04 > $PATH // Set bit 2 to enable PQWhat if we make examples followed by # and comments? And move (DEFAULT) to the commentary.
Quoted 4 lines
+++
b/drivers/dma/dmatest.cdrivers/dma/dmatest.c +2
-0+/* +* Capability Mask Bits.The bits in the cap_mask denote the masking of drivers/dma/dmatest.c line 38
Quoted 10 lines
drivers/dma/dmatest.c +10
-0+* the hardware capabilities of the dma channel. +* +* DMA_CAP_MEMCPY: Bit 0 for enabling DMA_MEMCPY capability +* DMA_CAP_XOR: Bit 1 for enabling DMA_XOR capabilit +* DMA_CAP_PQ: Bit 2 for enabling DMA_PQ capability +* DMA_CAP_ALL: Enable all the capabilities of the channel +*/ +#define DMA_CAP_MEMCPY (1 << 0) +#define DMA_CAP_XOR (1 << 1) +#define DMA_CAP_PQ (1 << 2)Can we reuse
DMA_MEMCPYand so on from enumdma_transaction_type?--
With Best Regards,
Andy Shevchenko
Quoted 15 lines · Andy Shevchenko
drivers/dma/dmatest.c line 38
Quoted 13 lines · Jubin Mehta
+++
b/drivers/dma/dmatest.cdrivers/dma/dmatest.c +12
-0+/* +* Capability Mask Bits.The bits in the cap_mask denote the masking of +* the hardware capabilities of the dma channel. +* +* DMA_CAP_MEMCPY: Bit 0 for enabling DMA_MEMCPY capability +* DMA_CAP_XOR: Bit 1 for enabling DMA_XOR capabilit +* DMA_CAP_PQ: Bit 2 for enabling DMA_PQ capability +* DMA_CAP_ALL: Enable all the capabilities of the channel +*/ +#define DMA_CAP_MEMCPY (1 << 0) +#define DMA_CAP_XOR (1 << 1) +#define DMA_CAP_PQ (1 << 2)Can we reuse
DMA_MEMCPYand so on from enumdma_transaction_type?
The issue is that the originals are enum types. We can't pass bitmap type (dma_cap_mask_t) through sysfs. So to use those enums for what we want to do it would have to be someting like:
(1 << DMA_MEMCPY)
And also in that case for user scripts you have bits that are here and there for the bitmask instead of something simple and sequential.
Signature · 4 lines
Dave Jiang Application Engineer, Storage Divsion Intel Corp. [email protected]
Quoted 9 lines · Andy Shevchenko
Documentation/dmatest.txt Comparison between buffers is stored to the dedicated structure. · line 96
Quoted 5 lines
Documentation/dmatest.txt +5
-0+PATH = /sys/kernel/debug/dmatest/cap_mask +(DEFAULT) echo 0x07 > $PATH // Set Bits 0,1,2 for MEMCPY, XOR and PQ + echo 0x01 > $PATH // Set bit 0 to enable MEMCPY + echo 0x02 > $PATH // Set bit 1 to enable XOR + echo 0x04 > $PATH // Set bit 2 to enable PQWhat if we make examples followed by # and comments? And move (DEFAULT) to the commentary.
Yes, I shall fix the issue in the next patch.
Regards,
Jubin
A message that is not in the archive (sent off-list or not yet received): CAA9_cmf5y_z_XeX7N2Jno9uvUkrFK83RN1XrxTwVqZJnbdfEWA@mail.gmail.com
[ apologies for the resend, gmail defaulted to html ]
Quoted 20 lines · Dan Williams
Documentation/dmatest.txt Comparison between buffers is stored to the dedicated structure. · line 104
Quoted 7 lines
Documentation/dmatest.txt +7
-0+Example to perform only MEMCPY and PQ mode tests (0x01 | 0x04 = 0x05): + + % modprobe dmatest + % echo dma0chan0 > /sys/kernel/debug/dmatest/channel + % echo 5 > /sys/kernel/debug/dmatest/cap_mask + % echo 1 > /sys/kernel/debug/dmatest/iterations + % echo 1 > /sys/kernel/debug/dmatest/runHmmm, I should have paid more attention when the debugfs support was initially proposed for dmatest. As it is I see duplication and configuration parameters getting out of sync with their module parameter equivalents versus just having all configuration go through module parameters.
module_param_call()can be used for the more complex options. Debugfs at this point looks like overkill for what amounts to some simple configuration variables and a result line.--
Dan
Quoted 17 lines · Dan Williams
Quoted 9 lines · Dan Williams
Documentation/dmatest.txt Comparison between buffers is stored to the dedicated structure. · line 104
Quoted 7 lines
Documentation/dmatest.txt +7
-0+Example to perform only MEMCPY and PQ mode tests (0x01 | 0x04 = 0x05): + + % modprobe dmatest + % echo dma0chan0 > /sys/kernel/debug/dmatest/channel + % echo 5 > /sys/kernel/debug/dmatest/cap_mask + % echo 1 > /sys/kernel/debug/dmatest/iterations + % echo 1 > /sys/kernel/debug/dmatest/runQuoted 7 lines
Hmmm, I should have paid more attention when the debugfs support was initially proposed for dmatest. As it is I see duplication and configuration parameters getting out of sync with their module parameter equivalents versus just having all configuration go through module parameters.
module_param_call()can be used for the more complex options. Debugfs at this point looks like overkill for what amounts to some simple configuration variables and a result line.
There two main issues we fight against:
- test automation, where we can collect results and use them later
- annoying modprobe / modprobe -r for each test case
The module parameters were left to support old behaviour of the module.
--
With Best Regards,
Andy Shevchenko
Quoted 23 lines · Dan Williams
[ apologies for the resend, gmail defaulted to html ]
Quoted 19 lines · Dan Williams
Documentation/dmatest.txt Comparison between buffers is stored to the dedicated structure. · line 104
Quoted 7 lines
Documentation/dmatest.txt +7
-0+Example to perform only MEMCPY and PQ mode tests (0x01 | 0x04 = 0x05): + + % modprobe dmatest + % echo dma0chan0 > /sys/kernel/debug/dmatest/channel + % echo 5 > /sys/kernel/debug/dmatest/cap_mask + % echo 1 > /sys/kernel/debug/dmatest/iterations + % echo 1 > /sys/kernel/debug/dmatest/runHmmm, I should have paid more attention when the debugfs support was initially proposed for dmatest. As it is I see duplication and configuration parameters getting out of sync with their module parameter equivalents versus just having all configuration go through module parameters.
module_param_call()can be used for the more complex options. Debugfs at this point looks like overkill for what amounts to some simple configuration variables and a result line.--
Dan
Would you like to have some changes regarding the configuration process for the module parameters of the dmatest?
Any other comments with respect to the patch?
Quoted 21 lines · Jubin Mehta
Quoted 20 lines · Dan Williams
[ apologies for the resend, gmail defaulted to html ]
Quoted 17 lines · Dan Williams
Documentation/dmatest.txt Comparison between buffers is stored to the dedicated structure. · line 104
Quoted 7 lines
Documentation/dmatest.txt +7
-0+Example to perform only MEMCPY and PQ mode tests (0x01 | 0x04 = 0x05): + + % modprobe dmatest + % echo dma0chan0 > /sys/kernel/debug/dmatest/channel + % echo 5 > /sys/kernel/debug/dmatest/cap_mask + % echo 1 > /sys/kernel/debug/dmatest/iterations + % echo 1 > /sys/kernel/debug/dmatest/runHmmm, I should have paid more attention when the debugfs support was initially proposed for dmatest. As it is I see duplication and configuration parameters getting out of sync with their module parameter equivalents versus just having all configuration go through module parameters.
module_param_call()can be used for the more complex options. Debugfs at this point looks like overkill for what amounts to some simple configuration variables and a result line.
Quoted 5 lines
Quoted 3 lines
Quoted 2 lines
--
DanWould you like to have some changes regarding the configuration process for the module parameters of the dmatest?
Yes, as a first step I would like to see a clean up of the the configuration parameters to be available via /sys/module/dmatest/parameters rather than /sys/kernel/debug/dmatest
As for "run" and "results" I see Andy's point that those are a bit awkward as parameters. However, we do have trace points as a more general mechanism for dumping events and data to userspace. If we had /sys/module/dmatest/parameters/run with a tracepoint for the result line does that get us everything we need for automation? I can see more tracepoints beng added to get some perf metrics out of the tests.
Thoughts?
Quoted 1 line
Any other comments with respect to the patch?
How about a comma separated list of named capabilities (copy, xor, pq, xor_val, sg... etc) rather than a mask? If we are already not using the dma_transaction_type values might as well use something human readable.
--
Dan
Quoted 8 lines · Dan Williams
Quoted 2 lines · Jubin Mehta
Would you like to have some changes regarding the configuration process for the module parameters of the dmatest?
Yes, as a first step I would like to see a clean up of the the configuration parameters to be available via
/sys/module/dmatest/parametersrather than/sys/kernel/debug/dmatest
Do you mean to enable write access to them?
Quoted 6 lines
As for "run" and "results" I see Andy's point that those are a bit awkward as parameters. However, we do have trace points as a more general mechanism for dumping events and data to userspace. If we had
/sys/module/dmatest/parameters/runwith a tracepoint for the result line does that get us everything we need for automation? I can see more tracepoints beng added to get some perf metrics out of the tests.
I'm not familiar neither with perf, nor with tracepoints. Could you elaborate and show here the scheme how it should work? How we will get results? In what form?
--
With Best Regards,
Andy Shevchenko
Quoted 11 lines · Andy Shevchenko
Quoted 8 lines · Dan Williams
Quoted 2 lines · Jubin Mehta
Would you like to have some changes regarding the configuration process for the module parameters of the dmatest?
Yes, as a first step I would like to see a clean up of the the configuration parameters to be available via
/sys/module/dmatest/parametersrather than/sys/kernel/debug/dmatestDo you mean to enable write access to them?
Yes.
Quoted 8 lines
Quoted 7 lines
As for "run" and "results" I see Andy's point that those are a bit awkward as parameters. However, we do have trace points as a more general mechanism for dumping events and data to userspace. If we had
/sys/module/dmatest/parameters/runwith a tracepoint for the result line does that get us everything we need for automation? I can see more tracepoints beng added to get some perf metrics out of the tests.
Quoted 4 lines
I'm not familiar neither with perf, nor with tracepoints. Could you elaborate and show here the scheme how it should work? How we will get results? In what form?
It would be very similar to what it does now except using generic functionality. At a high level you would have a tracepoint that emits something like:
dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0)
...and that message shows up in the ftrace buffer when it fires.
These articles are a good starting point.
https://lwn.net/Articles/379903/
https://lwn.net/Articles/383362/