[RFC] ethdev: simplify representor info get API

[Dariusz Sosnowski]

On Mon, Aug 31, 2026 at 09:46:54AM -0700, Stephen Hemminger wrote:
> On Mon, 31 Aug 2026 18:29:05 +0200
> Dariusz Sosnowski <dsosnowski at nvidia.com> wrote:
> 
> > * Background on rte_eth_representor_info_get()
> > 
> > rte_eth_representor_info_get() experimental function was added
> > to ethdev public API in 21.05 DPDK release [1].
> 
> You know the API shouldn't have stayed experimental so long.
> There is no good reason for API to stay experimental across multiple LTS releases!
> 
> The code would be much simpler if you use sentinel values rather than
> carrying around all the XX_valid flag values.
> 
> With int fields and -1 (or a named RTE_ETH_REPRESENTOR_UNSPEC),
>  the whole comparator collapses to something like:
> 
> 
> static bool field_match(int a, int b)
> {
> 	return a == -1 || b == -1 || a == b;
> }
> 
> return field_match(info.controller, other->controller) &&
>        field_match(info.pf, other->pf) &&
>        info.type == other->type &&
>        (info.type != RTE_ETH_REPRESENTOR_VF || field_match(info.vf, other->vf)) &&

Ack, I can apply that in the next version of the patches.

My only worry would be that mlx5 DPDK driver gets these values
(controller numbers, VF/SF numbers) from phys_port_name
exported through sysfs.
phys_port_name is based on devlink port attributes [1] with
the following types:

- controller number - u32
- port number - u32
    - Used for physical port representors in mlx5 DPDK driver.
      These are of type RTE_ETH_REPRESENTOR_PF.
- VF number - u16
- SF number - u32

Using int fields would not cover values
which can be returned by kernel.

What do you think about going with int64_t for these fields?

[1]: https://github.com/torvalds/linux/blob/v7.2/include/uapi/linux/devlink.h#L412
Relevant attributes are:
- DEVLINK_ATTR_PORT_CONTROLLER_NUMBER
- DEVLINK_ATTR_PORT_NUMBER
- DEVLINK_ATTR_PORT_PCI_PF_NUMBER
- DEVLINK_ATTR_PORT_PCI_VF_NUMBER
- DEVLINK_ATTR_PORT_PCI_SF_NUMBER