| Message ID | 1708531057-67392-1-git-send-email-jdamato@fastly.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Expose netdev name in netdev netlink APIs | expand |
On Wed, 21 Feb 2024 07:57:28 -0800 Joe Damato wrote: > Greetings: > > The netdev netlink APIs currently provide the ifindex of a device > associated with the NIC queue or NAPI when the netlink API is used. In > order for user applications to map this back to a human readable device > name, user applications must issue a subsequent ioctl (SIOCGIFNAME) in > order to map an ifindex back to a device name. To be clear, if_indextoname() is doing it, right? I wanted to be sure the concern is really number of syscalls, not the difficulty in getting the name. > This patch set adds ifname to the API so that when queue or NAPI > information is retrieved, the human readable string is included. The netdev > netlink YAML spec has been updated to include this field, as well. > > This saves the subsequent call to ioctl and makes the netlink information > more user friendly. Applications might use this information in conjunction > with SO_INCOMING_NAPI_ID to map NAPI IDs to specific NICs with application > specific configuration (e.g. NUMA zone and CPU layout information). For context, the reason why I left the names out is that they can change at any moment, but primarily because there are also altnames now: 2: eth0: [...] altname enp2s0np0 Most of the APIs try to accept altnames as well as the "main" name. If we propagate the name we'll step back into the rtnetlink naming mess :(
On Wed, Feb 21, 2024 at 11:09:52AM -0800, Jakub Kicinski wrote: > On Wed, 21 Feb 2024 07:57:28 -0800 Joe Damato wrote: > > Greetings: > > > > The netdev netlink APIs currently provide the ifindex of a device > > associated with the NIC queue or NAPI when the netlink API is used. In > > order for user applications to map this back to a human readable device > > name, user applications must issue a subsequent ioctl (SIOCGIFNAME) in > > order to map an ifindex back to a device name. > > To be clear, if_indextoname() is doing it, right? I wanted to be sure > the concern is really number of syscalls, not the difficulty in getting > the name. It seemed a bit odd to me to require the user to hit different APIs -- one to get the ifindex and then another to get the name. I didn't realize you had intentionally left the name out, though. > > This patch set adds ifname to the API so that when queue or NAPI > > information is retrieved, the human readable string is included. The netdev > > netlink YAML spec has been updated to include this field, as well. > > > > This saves the subsequent call to ioctl and makes the netlink information > > more user friendly. Applications might use this information in conjunction > > with SO_INCOMING_NAPI_ID to map NAPI IDs to specific NICs with application > > specific configuration (e.g. NUMA zone and CPU layout information). > > For context, the reason why I left the names out is that they can change > at any moment, but primarily because there are also altnames now: > > 2: eth0: > [...] > altname enp2s0np0 > > Most of the APIs try to accept altnames as well as the "main" name. > If we propagate the name we'll step back into the rtnetlink naming > mess :( OK, I see. I didn't realize this was a thing. I suppose what you are saying is that we wouldn't want to expose names at all and stick with ifindexes only, is that right?
On Wed, 21 Feb 2024 11:21:23 -0800 Joe Damato wrote: > > For context, the reason why I left the names out is that they can change > > at any moment, but primarily because there are also altnames now: > > > > 2: eth0: > > [...] > > altname enp2s0np0 > > > > Most of the APIs try to accept altnames as well as the "main" name. > > If we propagate the name we'll step back into the rtnetlink naming > > mess :( > > OK, I see. I didn't realize this was a thing. I suppose what you are saying > is that we wouldn't want to expose names at all and stick with ifindexes > only, is that right? If you think it's a major usability improvement I can be convinced, but yes, leaving the names out initially was indeed intentional.
On Wed, Feb 21, 2024 at 11:26:44AM -0800, Jakub Kicinski wrote: > On Wed, 21 Feb 2024 11:21:23 -0800 Joe Damato wrote: > > > For context, the reason why I left the names out is that they can change > > > at any moment, but primarily because there are also altnames now: > > > > > > 2: eth0: > > > [...] > > > altname enp2s0np0 > > > > > > Most of the APIs try to accept altnames as well as the "main" name. > > > If we propagate the name we'll step back into the rtnetlink naming > > > mess :( > > > > OK, I see. I didn't realize this was a thing. I suppose what you are saying > > is that we wouldn't want to expose names at all and stick with ifindexes > > only, is that right? > > If you think it's a major usability improvement I can be convinced, > but yes, leaving the names out initially was indeed intentional. Well... it is useful to me, but I think I'm only one user and the side effects of adding this might have painful results in the future so after your comment I think it might be best left out. Sorry for the noise.
Greetings: The netdev netlink APIs currently provide the ifindex of a device associated with the NIC queue or NAPI when the netlink API is used. In order for user applications to map this back to a human readable device name, user applications must issue a subsequent ioctl (SIOCGIFNAME) in order to map an ifindex back to a device name. This patch set adds ifname to the API so that when queue or NAPI information is retrieved, the human readable string is included. The netdev netlink YAML spec has been updated to include this field, as well. This saves the subsequent call to ioctl and makes the netlink information more user friendly. Applications might use this information in conjunction with SO_INCOMING_NAPI_ID to map NAPI IDs to specific NICs with application specific configuration (e.g. NUMA zone and CPU layout information). An example using the netlink cli tool before this change: $ ./cli.py --spec netdev.yaml --dump queue-get --json='{"ifindex": 7}' [{'id': 0, 'ifindex': 7, 'type': 'rx'}, {'id': 1, 'ifindex': 7, 'type': 'rx'}, {'id': 2, 'ifindex': 7, 'type': 'rx'}, ... $ ./cli.py --spec netdev.yaml --dump napi-get --json='{"ifindex": 7}' [{'id': 448, 'ifindex': 7}, {'id': 447, 'ifindex': 7}, {'id': 446, 'ifindex': 7}, ... An example after this change: $ ./cli.py --spec netdev.yaml --dump queue-get --json='{"ifindex": 7}' [{'id': 0, 'ifindex': 7, 'ifname': 'eth1', 'type': 'rx'}, {'id': 1, 'ifindex': 7, 'ifname': 'eth1', 'type': 'rx'}, {'id': 2, 'ifindex': 7, 'ifname': 'eth1', 'type': 'rx'}, ... $ ./cli.py --spec netdev.yaml --dump napi-get --json='{"ifindex": 7}' [{'id': 448, 'ifindex': 7, 'ifname': 'eth1'}, {'id': 447, 'ifindex': 7, 'ifname': 'eth1'}, {'id': 446, 'ifindex': 7, 'ifname': 'eth1'}, ... Thanks, Joe Joe Damato (2): netdev-genl: Add ifname for queue and NAPI APIs netdev-genl: spec: Add ifname to netdev nl YAML spec Documentation/netlink/specs/netdev.yaml | 10 ++++++++++ include/uapi/linux/netdev.h | 2 ++ net/core/netdev-genl.c | 22 +++++++++++++++++----- tools/include/uapi/linux/netdev.h | 2 ++ 4 files changed, 31 insertions(+), 5 deletions(-)