On Sat, Apr 05, 2025 at 08:36:23AM -0700, Stephen Hemminger wrote:
> The process private data allocation was indented incorrectly
> in the source code, and had unnecessary cast. It is better
> that the data be allocated on same numa node as the device
> structure.
>
> Signed-off-by: Stephen Hemminger <step...@networkplumber.org>
> ---
> drivers/net/pcap/pcap_ethdev.c | 13 ++++---------
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
> index 728ef85d53..aefa74c7be 100644
> --- a/drivers/net/pcap/pcap_ethdev.c
> +++ b/drivers/net/pcap/pcap_ethdev.c
> @@ -1208,10 +1208,8 @@ pmd_init_internals(struct rte_vdev_device *vdev,
> PMD_LOG(INFO, "Creating pcap-backed ethdev on numa socket %d",
> numa_node);
>
> - pp = (struct pmd_process_private *)
> - rte_zmalloc(NULL, sizeof(struct pmd_process_private),
> - RTE_CACHE_LINE_SIZE);
> -
> + pp = rte_zmalloc_socket(NULL, sizeof(struct pmd_process_private),
> + RTE_CACHE_LINE_SIZE, numa_node);
> if (pp == NULL) {
> PMD_LOG(ERR,
> "Failed to allocate memory for process private");
My concern there is that by forcing the numa node parameter, you are going
to make it impossible to run with memory on the "wrong" numa node.
Admittedly, this is less of a problem with virtual devices like pcap, than
physical ones, but I still wonder if, on error, you should fallback to a
regular "rte_malloc" call to allow the allocation to succeed so long as
there is some hugepage memory available somewhere.
/Bruce
