All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pattan, Reshma" <reshma.pattan@intel.com>
To: "Hunt, David" <david.hunt@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [PATCH] app/test: fix reorder test failure
Date: Thu, 3 May 2018 15:53:16 +0000	[thread overview]
Message-ID: <3AEA2BF9852C6F48A459DA490692831F2A2EAC12@irsmsx110.ger.corp.intel.com> (raw)
In-Reply-To: <fe153064-2940-c059-9888-43bc609e6a57@intel.com>

Hi,

> -----Original Message-----
> From: Hunt, David
> Sent: Thursday, May 3, 2018 4:50 PM
> To: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org
> Cc: stable@dpdk.org
> Subject: Re: [PATCH] app/test: fix reorder test failure
> 
> Hi Reshma,
> 
> On 3/5/2018 4:42 PM, Reshma Pattan wrote:
> > Inside test_reorder_insert()
> > rte_mempool_get_bulk() and rte_mempool_put_bulk() are used to allocate
> > and free the mbufs and then rte_reorder_free() is called which again
> > freeing the mbufs using rte_pktmbuf_free().
> >
> > The mixed use of rte_mempool_put_bulk() and rte_pktmbuf_free() causing
> > duplicate mbufs to be created when rte_mempool_get_bulk() is called
> > next in test_reorder_drain().
> >
> > Since reorder library is taking care of freeing the mbufs using
> > rte_pktmbuf_free() change UT to allocate mbufs using
> > rte_pktmbuf_alloc().
> >
> > Do not mix and match the bulk get/put APIs with alloc/free APIs which
> > can cause undefined behavior.
> >
> > Fixes: d0c9b58d71 ("app/test: new reorder unit test")
> > Cc: stable@dpdk.org
> > Cc: david.hunt@intel.com
> > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > ---
> >   test/test/test_reorder.c | 18 ++++++++----------
> >   1 file changed, 8 insertions(+), 10 deletions(-)
> >
> > diff --git a/test/test/test_reorder.c b/test/test/test_reorder.c index
> > 65e4f38b2..b79b00961 100644
> > --- a/test/test/test_reorder.c
> > +++ b/test/test/test_reorder.c
> > @@ -146,11 +146,11 @@ test_reorder_insert(void)
> >   	b = rte_reorder_create("test_insert", rte_socket_id(), size);
> >   	TEST_ASSERT_NOT_NULL(b, "Failed to create reorder buffer");
> >
> > -	ret = rte_mempool_get_bulk(p, (void *)bufs, num_bufs);
> > -	TEST_ASSERT_SUCCESS(ret, "Error getting mbuf from pool");
> > -
> > -	for (i = 0; i < num_bufs; i++)
> > +	for (i = 0; i < num_bufs; i++) {
> > +		bufs[i] = rte_pktmbuf_alloc(p);
> > +		TEST_ASSERT_NOT_NULL(bufs[i], "Packet allocation
> failed\n");
> >   		bufs[i]->seqn = i;
> > +	}
> >
> >   	/* This should fill up order buffer:
> >   	 * reorder_seq = 0
> > @@ -202,7 +202,6 @@ test_reorder_insert(void)
> >
> >   	ret = 0;
> >   exit:
> > -	rte_mempool_put_bulk(p, (void *)bufs, num_bufs);
> >   	rte_reorder_free(b);
> >   	return ret;
> >   }
> > @@ -227,9 +226,6 @@ test_reorder_drain(void)
> >   	b = rte_reorder_create("test_drain", rte_socket_id(), size);
> >   	TEST_ASSERT_NOT_NULL(b, "Failed to create reorder buffer");
> >
> > -	ret = rte_mempool_get_bulk(p, (void *)bufs, num_bufs);
> > -	TEST_ASSERT_SUCCESS(ret, "Error getting mbuf from pool");
> > -
> >   	/* Check no drained packets if reorder is empty */
> >   	cnt = rte_reorder_drain(b, robufs, 1);
> >   	if (cnt != 0) {
> > @@ -239,8 +235,11 @@ test_reorder_drain(void)
> >   		goto exit;
> >   	}
> >
> > -	for (i = 0; i < num_bufs; i++)
> > +	for (i = 0; i < num_bufs; i++) {
> > +		bufs[i] = rte_pktmbuf_alloc(p);
> > +		TEST_ASSERT_NOT_NULL(bufs[i], "Packet allocation
> failed\n");
> >   		bufs[i]->seqn = i;
> > +	}
> >
> >   	/* Insert packet with seqn 1:
> >   	 * reorder_seq = 0
> > @@ -298,7 +297,6 @@ test_reorder_drain(void)
> >   	}
> >   	ret = 0;
> >   exit:
> > -	rte_mempool_put_bulk(p, (void *)bufs, num_bufs);
> >   	rte_reorder_free(b);
> >   	return ret;
> >   }
> 
> I have one question. While the rte_reorder_free() takes care of freeing up any
> mbufs that were inserted into the reorder buffer, should there be
> rte_pktmbuf_free() calls for any remaining unused mbufs left in the bufs[]
> array?
> 


Hmm, test teardown has rte_mempool_free() will that not be sufficient to free the pool and hence the mbufs?


> Regards,
> Dave.
> 


  reply	other threads:[~2018-05-03 15:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03 15:42 [PATCH] app/test: fix reorder test failure Reshma Pattan
2018-05-03 15:49 ` Hunt, David
2018-05-03 15:53   ` Pattan, Reshma [this message]
2018-05-03 15:58     ` Hunt, David
2018-05-03 16:03 ` Hunt, David
2018-05-03 16:30 ` [PATCH v2] " Reshma Pattan
2018-05-03 16:36   ` [PATCH v3] " Reshma Pattan
2018-05-03 17:02     ` Hunt, David
2018-05-04 10:47     ` [PATCH v4] " Reshma Pattan
2018-05-13 21:17       ` Thomas Monjalon
2018-05-03 16:35 ` [PATCH v3] " Reshma Pattan

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=3AEA2BF9852C6F48A459DA490692831F2A2EAC12@irsmsx110.ger.corp.intel.com \
    --to=reshma.pattan@intel.com \
    --cc=david.hunt@intel.com \
    --cc=dev@dpdk.org \
    --cc=stable@dpdk.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 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.