Re: [PATCH v3 1/4] ethdev: add trace points

[Ferruh Yigit <ferruh.yigit@amd.com>]

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.