In the documentation for rte_eth_dev_socket_id() 
(https://doc.dpdk.org/api/rte__ethdev_8h.html#ad032e25f712e6ffeb0c19eab1ec1fd2e),
 the return code is described as:

> The NUMA socket id to which the Ethernet device is connected or a default of 
> zero if the socket could not be determined. -1 is returned is [sic] the 
> port_id value is out of range.

The behavior of this function on some systems doesn't match the docs. On my 
linux system, for example, rte_eth_dev_socket_id returns -1 even if I pass a 
valid port_id.

The actual behavior of this function appears to be to return the integer value 
found in /sys/bus/pci/devices/<BDF>/numa_node, or 0 if that file cannot be 
read/parsed. On my system, which is not a NUMA system, the path to 
/sys/bus/.../numa_node exists but contains -1, hence why rte_eth_dev_socket_id 
returns -1.

I think that either the documentation or the code should be updated to save 
users time and confusion. I've found several other postings by users about this 
incorrect documentation in various places online by searching for 
"rte_eth_dev_socket_id".

To kick off a discussion, let me suggest returning -EINVAL (as is done in 
rte_eventdev.c's rte_event_dev_socket_id()) if the port id is unknown to DPDK, 
and updating the documentation to explain that -EINVAL is returned in the case 
of an out of range port_id, otherwise the value of 
/sys/bus/pci/devices/<BDF>/numa_node will be used, which may be -1 if reported 
by the system, or 0 if it cannot be found/parsed, or 0-N if it can be parsed.

This still leaves ambiguity about whether 0 means NUMA node 0 or "could not be 
parsed", but it's better than the current situation in my opinion.

Thoughts?

~Cody

Reply via email to