RE: [PATCH v4 0/4] Introduce Topology NUMA grouping for lcores

["Varghese, Vipin" <Vipin.Varghese@amd.com>]

[Public]

Hi Morten,

snipped


>
>
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Thursday, 13 February 2025 09.34
> >
> > 13/02/2025 04:09, Varghese, Vipin:
> > > [AMD Official Use Only - AMD Internal Distribution Only]
> > >
> > > Adding Thomas and Ajit to the loop.
> > >
> > > Hi Ajit, we have been using the patch series for identifying the
> > topology and getting l3 cache id for populating the steering tag for
> > Device Specific Model & MSI-x driven af-xdp for the experimental STAG
> > firmware on Thor.
>
> Excellent. A real life example use case helps the review process a lot!

Steering tag is one of the examples or uses, as shared in the current patch series  we make use of these for other examples too.
Eventdev, pkt-distributor and graph nodes are also in works to exploit L2|L3 cache local coherency too.

>
> > >
> > > Hence current use of topology library helps in 1. workload placement
> > > in same Cache or IO domain 2. populating id for MSIx or Device
> > > specific model for steering tags.
> > >
> > > Thomas and Ajith can we get some help to get this mainline too?
> >
> > Yes, sorry the review discussions did not start.
> > It has been forgotten.
>
> I think the topology/domain API in the EAL should be co-designed with the steering
> tag API in the ethdev library, so the design can be reviewed/discussed in its entirety.

As shared in the discussion, we have been exploring simplified approach for steering tags, namely

1. pci-dev args (crude way)
2. flow api for RX (experimental way)

Based on the platform (in case of AMD EPYC, these are translated to `L3 id + 1`)

We do agree rte_ethdev library can use topology API. Current topology API are designed to be made independent from steering tags, as other examples do make use of the same.

>
> To help the review discussion, please consider describing the following:
> Which APIs are for slow path, and which are for fast path?
> Which APIs are "must have", i.e. core to making it work at all, and which APIs are
> "nice to have", i.e. support APIs to ease use of the new features?

Yes, will try to do the same in updated version. For Slow and Fast path API I might need some help, as I was under the impression current behavior is same rte_lcore (invoked at setup and before remote launch). But will check again.

>
> I haven't looked at the hwloc library's API; but I guess these new EAL functions are
> closely related. Is it a thin wrapper around the hwloc library, or is it very different?
This is very thin wrapper on top of hwloc library only. But with DPDK RTE_MAX_LCORE & RTE_NUMA boundary check and population.