On Tue, 30 Nov 2021 10:56:26 -0700 David Ahern wrote:

On 11/30/21 10:07 AM, Jakub Kicinski wrote:

quoted

On Tue, 30 Nov 2021 17:17:24 +0100 Toke Høiland-Jørgensen wrote:  

quoted

Well, I don't like throwing data away, so in that sense I do like
per-queue stats, but it's not a very strong preference (i.e., I can live
with either)...  

We don't even have a clear definition of a queue in Linux.
  

The summary above says "Jakub: no per-channel", and then you have this
comment about a clear definition of a queue. What is your preference
here, Jakub? I think I have gotten lost in all of the coments.

I'm against per-channel and against per-queue stats. I'm not saying "do
one instead of the other". Hope that makes it clear.

My request was just to not lump Rx and Tx together under a 'channel'
definition as a new API. Proposals like zctap and 'queues as a first
class citizen' are examples of intentions / desires to move towards Rx
and Tx queues beyond what exists today.

Right, and when we have the objects to control those we'll hang the
stats off them. Right now half of the NICs will destroy queue stats
on random reconfiguration requests, others will mix the stats between
queue instantiations.. mlx5 does it's shadow queue thing. It's a mess.
uAPI which is not portable and not usable in production is pure burden.