[Public] Hi Morten,
snipped > > > > From: Thomas Monjalon [mailto:tho...@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.
