[dpdk-dev] [PATCH] test: fbk hash - fix errors with large nb entries

[dpdk-dev] [PATCH] test: fbk hash - fix errors with large nb entries

[Bruce Richardson]

The four-byte-key (fbk) autotest was allocating the keys to be used for
the test on the stack. When the number of entries in the table was
increased significantly, for example, to test larger hashes by increase the
value of ENTRIES, this array of keys was greater than that
allowed on the stack, and so caused problems, i.e. crashes and core dumps.

The solution is to have the keys dynamically allocated on the heap using
malloc. Now if ENTRIES is increased and we run out of memory we get an
error message instead of a crash.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/test/test_hash_perf.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/app/test/test_hash_perf.c b/app/test/test_hash_perf.c
index 7bb7016..be34957 100644
--- a/app/test/test_hash_perf.c
+++ b/app/test/test_hash_perf.c
@@ -397,6 +397,7 @@ struct tbl_perf_test_params tbl_perf_params[] =
 	if (cond) {							\
 		printf("ERROR line %d: " str "\n", __LINE__, ##__VA_ARGS__); \
 		if (handle) rte_fbk_hash_free(handle);			\
+		if (keys) rte_free(keys);				\
 		return -1;						\
 	}								\
 } while(0)
@@ -697,8 +698,8 @@ fbk_hash_perf_test(void)
 		.entries_per_bucket = 4,
 		.socket_id = rte_socket_id(),
 	};
-	struct rte_fbk_hash_table *handle;
-	uint32_t keys[ENTRIES] = {0};
+	struct rte_fbk_hash_table *handle = NULL;
+	uint32_t *keys = NULL;
 	unsigned indexes[TEST_SIZE];
 	uint64_t lookup_time = 0;
 	unsigned added = 0;
@@ -708,6 +709,10 @@ fbk_hash_perf_test(void)
 	handle = rte_fbk_hash_create(&params);
 	RETURN_IF_ERROR_FBK(handle == NULL, "fbk hash creation failed");
 
+	keys = rte_zmalloc(NULL, ENTRIES * sizeof(*keys), 0);
+	RETURN_IF_ERROR_FBK(keys == NULL,
+		"fbk hash: memory allocation for key store failed");
+
 	/* Generate random keys and values. */
 	for (i = 0; i < ENTRIES; i++) {
 		uint32_t key = (uint32_t)rte_rand();
-- 
1.9.3

Re: [dpdk-dev] [PATCH] test: fbk hash - fix errors with large nb entries

[De Lara Guarch, Pablo]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Friday, October 17, 2014 2:18 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] test: fbk hash - fix errors with large nb entries
> 
> The four-byte-key (fbk) autotest was allocating the keys to be used for
> the test on the stack. When the number of entries in the table was
> increased significantly, for example, to test larger hashes by increase the
> value of ENTRIES, this array of keys was greater than that
> allowed on the stack, and so caused problems, i.e. crashes and core dumps.
> 
> The solution is to have the keys dynamically allocated on the heap using
> malloc. Now if ENTRIES is increased and we run out of memory we get an
> error message instead of a crash.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>

Re: [dpdk-dev] [PATCH] test: fbk hash - fix errors with large nb entries

[Bruce Richardson]

On Fri, Oct 17, 2014 at 12:34:05PM +0100, y@ecsmtp.ir.intel.com wrote:
> From: Bruce Richardson <bruce.richardson@intel.com>
>

Oops, apologies for the screwed-up origin address! Pressed "y" for "yes, I 
do want my emails to come from 'bruce.richardson@intel.com'" rather than 
just hitting enter when prompted!

/Bruce 

Re: [dpdk-dev] [PATCH] test: fbk hash - fix errors with large nb entries

[Bruce Richardson]

On Fri, Oct 17, 2014 at 12:38:05PM +0100, Bruce Richardson wrote:
> On Fri, Oct 17, 2014 at 12:34:05PM +0100, y@ecsmtp.ir.intel.com wrote:
> > From: Bruce Richardson <bruce.richardson@intel.com>
> >
> 
> Oops, apologies for the screwed-up origin address! Pressed "y" for "yes, I 
> do want my emails to come from 'bruce.richardson@intel.com'" rather than 
> just hitting enter when prompted!
> 
> /Bruce 

And in case anyone else is interested, or always gets prompted for the 
source email address when sending patches - configuring the "sendemail.from" 
value in your git configuration should make this go away.

	git config --global sendemail.from "name <email>"

See: http://git-scm.com/docs/git-send-email

/Bruce