[dpdk-dev] rte_eth_dev_socket_id() doesn't match documentation

["Harris, Cody" <codh@amazon.com>]

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