DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Vipin P R <vipinp@vmware.com>
Cc: <dev@dpdk.org>, <stable@dpdk.org>
Subject: Re: [PATCH] Memory Allocation: Adding a new UT for fb_array
Date: Tue, 16 May 2023 14:39:49 +0100	[thread overview]
Message-ID: <73232584-b595-93dd-01d2-778a2b8ea31d@intel.com> (raw)
In-Reply-To: <1673615567-20873-2-git-send-email-vipinp@vmware.com>

Hi Vipin!

Thanks for all of the work on this bug, it is highly appreciated. Below 
are suggestions for improvements for this patch.

On 1/13/2023 1:12 PM, Vipin P R wrote:
> add test case coverage to cover the ms_idx jump

This message could be expanded to be more informative. Suggested rewording:

test/fbarray: add test case for incorrect lookahead behavior

> 
> Cc: stable@dpdk.org
> 
> Signed-off-by: Vipin P R <vipinp@vmware.com>
> Acked-by: Kumara Parameshwaran <kparameshwar@vmware.com>
> ---
> Depends-on: 0001-Memory-Allocation-Fixes-ms_idx-jump-lookahead-during.patch
> Depends-on: 0002-Memory-Allocation-Fixes-ms_idx-jump-lookbehind-durin.patch

This makes no difference for commit, but for future reference: 
depends-on should reference link to actual patches, not a patch file name.

> ---
>   app/test/test_fbarray.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 49 insertions(+)
> 
> diff --git a/app/test/test_fbarray.c b/app/test/test_fbarray.c
> index a691bf4..275449c 100644
> --- a/app/test/test_fbarray.c
> +++ b/app/test/test_fbarray.c
> @@ -11,6 +11,7 @@
>   #include <rte_debug.h>
>   #include <rte_errno.h>
>   #include <rte_fbarray.h>
> +#include <rte_memory.h>

This is presumably added to get access to `struct rte_memseg`, but this 
is not needed, because the bug is in the mask behavior, which does not 
depend on specific data size.

>   
>   #include "test.h"
>   
> @@ -402,6 +403,53 @@ static int check_used_one(void)
>   	return 0;
>   }
>   
> +/* the following test case verifies that the jump in ms_idx for an fb-array is correct. */
> +static int test_jump(void)
> +{
> +    struct rte_fbarray test_array;
> +    int input[] = {1, 1070, 1, 2, 1, 2, 4, 12, 2, 2, 1, 2, 1};

I've managed to reduce this bug down to a more minimal example:

{ 63, 1, 2 }

> +    int ms_idx, prev_ms_idx, delta;
> +    int len;
> +    ms_idx = prev_ms_idx = 0;
> +
> +    int ret = rte_fbarray_init(&test_array, "test", 32768, sizeof(struct rte_memseg));
> +    if (ret == 0) {
> +        RTE_LOG(DEBUG, EAL, "FB array init success\n");

If the code did an early exit, an additional indentation level could've 
been avoided, like so:

	TEST_ASSERT(rte_fbarray_init(&test_array, "test", 256, 8) == 0,
			"Failed to initialize fbarray\n");

Also, missing corresponding `rte_fbarray_destroy` call.

> +        int k = 0;

Seems like the only place where this is used is in find_next_n_free, and 
it never changes, so I don't think this variable is needed at all.

> +        for(int i=0; i < sizeof(input)/sizeof(int); i++) {

RTE_DIM? Also, array indices are `unsigned int` rather than `int`, 
compiler gives a warning.

> +            if (i == 0) {
> +                len = input[i];
> +            } else {
> +                len = input[i] + 1;
> +            }

All of this could be rewritten as follows:

	int len, hole;

	/* if this is not the first iteration, create a hole */
	hole = i != 0;
	len = input[i] + hole;

> +            prev_ms_idx = ms_idx;
> +            ms_idx = rte_fbarray_find_next_n_free(&test_array, k, len);

Like I said above, `k` is unneeded, we can just replace it with 0.

> +
> +            if (i != 0) {
> +                ms_idx++;
> +            }

Given suggestion above, could use `if (hole)` instead, would be more 
readable.

> +
> +            for (int j=0; j < input[i]; j++) {

Array indices are unsigned, and also could replace with

	for (unsigned int j = hole; j < len; j++)

IMO would be more readable.

> +                RTE_LOG(DEBUG, EAL, "ms_idx:%d\n", ms_idx);

I don't think this log is needed.

> +                rte_fbarray_set_used(&test_array, ms_idx);
> +                ms_idx++;
> +            }
> +
> +            if (prev_ms_idx) {
> +                /* The value of ms_idx should be monotonically increasing
> +                 * given the above input sequence in test_array.
> +                 * */
> +                delta = ms_idx - prev_ms_idx;
> +                if (!(delta > 0)) {

Given above suggestions, this can be replaced with `if (delta != len)`. 
Also, given the `TEST_ASSERT(0)` below, I think this could just be 
replaced with an assert and a message, e.g.

	TEST_ASSERT(delta == len, "Incorrect fbarray index\n");

-- 
Thanks,
Anatoly


  parent reply	other threads:[~2023-05-16 13:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13 13:12 [PATCH] *** Memory Allocation: Adding a new UT for fb_array *** Vipin P R
2023-01-13 13:12 ` [PATCH] Memory Allocation: Adding a new UT for fb_array Vipin P R
2023-01-16 17:54   ` Stephen Hemminger
2023-05-16 13:39   ` Burakov, Anatoly [this message]
2023-05-16 14:25     ` Burakov, Anatoly

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=73232584-b595-93dd-01d2-778a2b8ea31d@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=stable@dpdk.org \
    --cc=vipinp@vmware.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 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).