On 7/26/2024 9:01 PM, Wathsala Wathawana Vithanage wrote: >> rte_eth_X_get_capability() >> > > rte_eth_dev_stashing_hints_discover is somewhat similar. > >> Instead of adding RTE_ETH_DEV_CAPA_ macro and contaminating >> 'rte_eth_dev_info' with this edge use case, what do you think follow above >> design and have dedicated get capability API? > > I think it's better to have a dedicated API, given that we already have a fine > grained capabilities discovery function. I will add this feedback to V3 of the > RFC. > >> >> And I can see set() has two different APIs, 'rte_eth_dev_stashing_hints_rx' & >> 'rte_eth_dev_stashing_hints_tx', is there a reason to have two separate APIs >> instead of having one which gets RX & TX as argument, as done in internal >> device ops? > > Some types/hints may only apply to a single queue direction, so I thought it > would be better to separate them out into separate Rx and Tx APIs for ease > of comprehension/use for the developer. > In fact, underneath, it uses one API for both Rx and Tx. >
Hi Wathsala, Do you still pursue this RFC, should we expect a new version for this release? Did you have any change to measure the impact of the changes in this patch? Btw, do you think the LLC aware lcore selection patch [1] can be relevant or can it help for the cases this patch addresses? [1] https://patches.dpdk.org/project/dpdk/list/?series=32851
