On 10/10/2022 7:39 AM, Ankur Dwivedi wrote: >> Yes the functions you mentioned in previous comment are called in while loop >> in worker core. So I think they are fastpath. >> rte_eth_stats_get() is called in fastpath. Similar to rte_eth_macaddr_get(), >> I >> think functions like >> rte_eth_pro miscuous_get(), rte_eth_allmulticast_get() can also be called in >> fastpath. >> I am not sure which other functions can be fastpath. Is there a >> guideline/theme >> which can be used to determine this? > [Ankur] I will make the trace call in following functions as fast path trace, > considering they are used in while loop in worker core or as rx/tx callback > in examples applications. > rte_eth_tx_buffer_drop_callback > rte_eth_tx_buffer_count_callback > rte_eth_tx_done_cleanup > rte_eth_macaddr_get > rte_eth_timesync_read_rx_timestamp > rte_eth_timesync_read_tx_timestamp > rte_eth_timesync_adjust_time > rte_eth_timesync_read_time > rte_eth_timesync_write_time > rte_eth_stats_get > rte_flow_get_restore_info > rte_eth_read_clock > > Please let me know your comments on the patch series.
Hi Ankur, I agree that tracing should not cause performance degradation, but not all APIs in your list are for datapath, or for each packet (even called in datapath in sample app). I would use fast path trace for following ones, but keep rest regular trace for rest: fastpath rte_eth_tx_buffer_drop_callback rte_eth_tx_buffer_count_callback rte_eth_tx_done_cleanup btw, I am planning to review series today/tomorrow, so please hold a possible new version for a while.
