On Tue, 30 Nov 2021 10:56:26 -0700 David Ahern wrote: > On 11/30/21 10:07 AM, Jakub Kicinski wrote: > > On Tue, 30 Nov 2021 17:17:24 +0100 Toke Høiland-Jørgensen wrote: > >> 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.
