snipped > > Thanks for your comments. > I know you kindly provided many valuable comments though I reply the > following first because I think it is important that my idea/proposal is > acceptable or not first. > > > Sharing an alternate approach, if RX-TX callbacks are enabled in DPDK (which > is by default). One can register a callback handler to update counters with > the > following information as `port-queue pair, lcoreid, total rx burst request, > total > empty rx burst, 1-8 pks, 9-16 pkts, 16-32 pkts`. Callback handlers can be > selectively enabled or disabled too. > > > > Can you please help me understand how `rte_apistats` would be different or > pros of having it as library (that needs to be added to linking and running in > case of using DPDK applications)? > You are correct. > Application can do that by using callback of rx_burst/tx_burst. > But needs to modify/add the code for RX/TX process logic.
No the RX or TX application logic is not modified as the call back registration is done once right after port_init. > > Point of my patchset is couting is done by library so that APP only needs to > "retrieve/read" those data if needed (especially for existing applications). As mentioned in the other patchset the library function is enabled through and not conditionally built. Any application which is built with this patch set will be forced to invoke the calls. > > I think it makes some developers happy becaseu it is relatively easy to > measure > "how cpu core is bysy" easily. Not sure what do you mean, as there 2 factors which conflicts 1. there are existing uses cases and examples like power, metric, telemetry all uses RX/TX callbacks which does the same. 2. The current logic only helps in RX/TX cores and not other cores. So in case of pipeline model there are only a couple of RX or TX threads. > (I admit relatively rough measurement though. I think it is trade-off) > > What do you think? If I consider RX calls there are 3 main metrics 1. How many times RX is invoked. 2. How many times RX returns with `0` packets 3. How many times RX returns with `> 0` packets. With these values in the current logic you are trying to deduct actual CPU RX usage by `useful work = number of times `> 0` / total RX calls` As a end user I will always be happy to see telemetry data as `from time t1 to t2, 1. how many times per second on average RX calls were made. 2. how many times per second on average The calls returned packets in range of 1-4, 5-8, 9-16, 17 and more ` Current logic is not trying to address this problem. With my current understanding I am not convinced that one needs yet another library when the same can be done either with `RX/TX callback` > snipped
