[v2,7/8] app/bbdev: add parameter to take input in network order
Checks
Commit Message
From: Nipun Gupta <nipun.gupta@nxp.com>
Test bbdev application is reading the input and output from the
test vector files in the same endianness which is of the system.
This patch adds an option to provide data in the network order
i.e. big endian format
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
app/test-bbdev/test_bbdev_vector.c | 18 ++++++++++++++++--
app/test-bbdev/test_bbdev_vector.h | 2 ++
2 files changed, 18 insertions(+), 2 deletions(-)
Comments
On Sat, Apr 10, 2021 at 7:04 PM Hemant Agrawal <hemant.agrawal@nxp.com> wrote:
>
> From: Nipun Gupta <nipun.gupta@nxp.com>
>
> Test bbdev application is reading the input and output from the
> test vector files in the same endianness which is of the system.
> This patch adds an option to provide data in the network order
> i.e. big endian format
I did not look at the bbdev API, but something feels odd here.
Why should the test know about endianness?
On 4/12/2021 12:52 PM, David Marchand wrote:
> On Sat, Apr 10, 2021 at 7:04 PM Hemant Agrawal <hemant.agrawal@nxp.com> wrote:
>> From: Nipun Gupta <nipun.gupta@nxp.com>
>>
>> Test bbdev application is reading the input and output from the
>> test vector files in the same endianness which is of the system.
>> This patch adds an option to provide data in the network order
>> i.e. big endian format
> I did not look at the bbdev API, but something feels odd here.
> Why should the test know about endianness?
>
This is baseband data, which need to be processed by the offload device.
It is important for know the endianness of this data else the offload
device will not be able to process it correctly.
The existing files only have data in little-endian format. In the real
world, the network data can come in big-endian format, so the drivers
(running on Little-endian machine) shall be able to pass the big-endian
data for processing to offload device.
@@ -53,7 +53,8 @@ starts_with(const char *str, const char *pre)
/* tokenization test values separated by a comma */
static int
-parse_values(char *tokens, uint32_t **data, uint32_t *data_length)
+parse_values(char *tokens, uint32_t **data, uint32_t *data_length,
+ int network_order)
{
uint32_t n_tokens = 0;
uint32_t data_size = 32;
@@ -94,6 +95,14 @@ parse_values(char *tokens, uint32_t **data, uint32_t *data_length)
}
*data_length = *data_length + (strlen(tok) - strlen("0x"))/2;
+ if (network_order) {
+ if ((strlen(tok) - strlen("0x"))/2 == 4)
+ values[n_tokens] =
+ rte_cpu_to_be_32(values[n_tokens]);
+ else if ((strlen(tok) - strlen("0x"))/2 == 2)
+ values[n_tokens] =
+ rte_cpu_to_be_16(values[n_tokens]);
+ }
tok = strtok(NULL, VALUE_DELIMITER);
if (tok == NULL)
@@ -416,7 +425,8 @@ parse_data_entry(const char *key_token, char *token,
/* Clear new op data struct */
memset(op_data + *nb_ops, 0, sizeof(struct op_data_buf));
- ret = parse_values(token, &data, &data_length);
+ ret = parse_values(token, &data, &data_length,
+ vector->network_order);
if (!ret) {
op_data[*nb_ops].addr = data;
op_data[*nb_ops].length = data_length;
@@ -728,6 +738,10 @@ parse_ldpc_encoder_params(const char *key_token, char *token,
ret = parse_expected_status(token, &status, vector->op_type);
if (!ret)
vector->expected_status = status;
+ } else if (!strcmp(key_token, "network_order")) {
+ vector->mask |= TEST_BBDEV_VF_NETWORK_ORDER;
+ vector->network_order = (uint8_t) strtoul(token, &err, 0);
+ ret = ((err == NULL) || (*err != '\0')) ? -1 : 0;
} else {
printf("Not valid ldpc enc key: '%s'\n", key_token);
return -1;
@@ -35,6 +35,7 @@ enum {
TEST_BBDEV_VF_CODE_BLOCK_MODE = (1ULL << 23),
TEST_BBDEV_VF_OP_FLAGS = (1ULL << 24),
TEST_BBDEV_VF_EXPECTED_STATUS = (1ULL << 25),
+ TEST_BBDEV_VF_NETWORK_ORDER = (1ULL << 26),
};
enum op_data_type {
@@ -60,6 +61,7 @@ struct test_bbdev_vector {
enum rte_bbdev_op_type op_type;
int expected_status;
int mask;
+ int network_order;
union {
struct rte_bbdev_op_turbo_dec turbo_dec;
struct rte_bbdev_op_turbo_enc turbo_enc;