[dpdk-dev] How *rte_zmalloc_socket* ensure that the memory is zero'd ?

[dpdk-dev] How *rte_zmalloc_socket* ensure that the memory is zero'd ?

[He Peng]

Hi,

In file dpdk/lib/librte_eal/common/rte_malloc.c:

/*
* Allocate memory on default heap.
*/
void *
rte_malloc(const char *type, size_t size, unsigned align)
{
  return rte_malloc_socket(type, size, align, SOCKET_ID_ANY);
}

/*
* Allocate zero'd memory on specified heap.
*/
void *
rte_zmalloc_socket(const char *type, size_t size, unsigned align, int socket)
{
  return rte_malloc_socket(type, size, align, socket);
}

Looks like the *rte_malloc* and *rte_zmalloc_socket* is the same, then, how the latter function ensure the memory allocated by is zeroed?

Re: [dpdk-dev] How *rte_zmalloc_socket* ensure that the memory is zero'd ?

[Stephen Hemminger]

On Wed, 17 Jul 2019 02:26:57 GMT
He Peng <xnhp0320@icloud.com> wrote:

> Hi,
> 
> In file dpdk/lib/librte_eal/common/rte_malloc.c:
> 
> /*
> * Allocate memory on default heap.
> */
> void *
> rte_malloc(const char *type, size_t size, unsigned align)
> {
>   return rte_malloc_socket(type, size, align, SOCKET_ID_ANY);
> }
> 
> /*
> * Allocate zero'd memory on specified heap.
> */
> void *
> rte_zmalloc_socket(const char *type, size_t size, unsigned align, int socket)
> {
>   return rte_malloc_socket(type, size, align, socket);
> }
> 
> Looks like the *rte_malloc* and *rte_zmalloc_socket* is the same, then, how the latter function ensure the memory allocated by is zeroed?

This is done because touching the memory on free is faster than cache cold memory during allocation.

If you look at recent DPDK the behavior changes slightly if MALLOC_DEBUG is enabled.
If DEBUG is enabled freed memory is clobbered with a 0x6b so that any buggy program
is likely to crash when using freed memory. 

Re: [dpdk-dev] How *rte_zmalloc_socket* ensure that the memory is zero'd ?

[He Peng]

2019年7月16日 下午10:19，He Peng <xnhp0320@icloud.com> 写道：


Hi，



2019年7月16日 下午9:51，Stephen Hemminger <stephen@networkplumber.org> 写道：


On Wed, 17 Jul 2019 02:26:57 GMT
He Peng <xnhp0320@icloud.com> wrote:


Hi,


In file dpdk/lib/librte_eal/common/rte_malloc.c:


/*
* Allocate memory on default heap.
*/
void *
rte_malloc(const char *type, size_t size, unsigned align)
{
  return rte_malloc_socket(type, size, align, SOCKET_ID_ANY);
}


/*
* Allocate zero'd memory on specified heap.
*/
void *
rte_zmalloc_socket(const char *type, size_t size, unsigned align, int socket)
{
  return rte_malloc_socket(type, size, align, socket);
}


Looks like the *rte_malloc* and *rte_zmalloc_socket* is the same, then, how the latter function ensure the memory allocated by is zeroed?

This is done because touching the memory on free is faster than cache cold memory during allocation.

If you look at recent DPDK the behavior changes slightly if MALLOC_DEBUG is enabled.
If DEBUG is enabled freed memory is clobbered with a 0x6b so that any buggy program
is likely to crash when using freed memory.
 

But is it possible that one memory free resulting in two memory elements combined, however 
the code might forget to memset the metadata?




Sorry, check the code, it is done in the *join_elem*.
 

Re: [dpdk-dev] How *rte_zmalloc_socket* ensure that the memory is zero'd ?

[He Peng]

Hi，



2019年7月16日 下午9:51，Stephen Hemminger <stephen@networkplumber.org> 写道：


On Wed, 17 Jul 2019 02:26:57 GMT
He Peng <xnhp0320@icloud.com> wrote:


Hi,


In file dpdk/lib/librte_eal/common/rte_malloc.c:


/*
* Allocate memory on default heap.
*/
void *
rte_malloc(const char *type, size_t size, unsigned align)
{
  return rte_malloc_socket(type, size, align, SOCKET_ID_ANY);
}


/*
* Allocate zero'd memory on specified heap.
*/
void *
rte_zmalloc_socket(const char *type, size_t size, unsigned align, int socket)
{
  return rte_malloc_socket(type, size, align, socket);
}


Looks like the *rte_malloc* and *rte_zmalloc_socket* is the same, then, how the latter function ensure the memory allocated by is zeroed?

This is done because touching the memory on free is faster than cache cold memory during allocation.

If you look at recent DPDK the behavior changes slightly if MALLOC_DEBUG is enabled.
If DEBUG is enabled freed memory is clobbered with a 0x6b so that any buggy program
is likely to crash when using freed memory.
 

But is it possible that one memory free resulting in two memory elements combined, however 
the code might forget to memset the metadata?