> It will tell you if in a given offset on the rxq you have a packet ready. I > think it will fit your needs, see below. So we just loose in precision here. We're looking at ML techniques that will play better with a numerical value and benefit from more entropy than arbitrarily poking of some thresholds. If one had to remain, I'd say rx_descriptor_* should be removed as it can be deduced from queue_count. Moreover, in the MLX5 case, calling the function 3 times to get "half busy", "partially busy" or "idle" will lead to scanning the queue 3 times...
> But for the latency it is better to work w/ NIC host coherent clock + > timestamps (like you implemented on a different patch). We're looking at both as you noticed. But timestamping is much more costly. Hence latency is more for monitoring, reporting to the operator, while queue statistics are used for scheduling. It's harder to understand a latency value as a higher latency may only mean that a bunch of packets were more complex to handle. But we want to look at the relation between the two. I think this patch should go in (with maybe a solution for vectorized?). And when the removal of queue_count will be discussed I'll follow. But I'm sure other people will jump in the discussion at that time. Thanks for your time anyway, Tom
