[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e32e34b7-df22-4ff8-a2e4-04e2caaf489f@gmail.com>
Date: Sun, 31 Mar 2024 21:52:06 +0300
From: Tariq Toukan <ttoukan.linux@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, Simon Horman <horms@...nel.org>
Cc: Tariq Toukan <tariqt@...dia.com>, "David S. Miller"
<davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
Saeed Mahameed <saeedm@...dia.com>, Gal Pressman <gal@...dia.com>,
Leon Romanovsky <leonro@...dia.com>, Carolina Jubran <cjubran@...dia.com>,
Aya Levin <ayal@...dia.com>
Subject: Re: [PATCH net-next 5/8] net/mlx5e: Expose the VF/SF RX drop counter
on the representor
On 28/03/2024 18:21, Jakub Kicinski wrote:
> On Thu, 28 Mar 2024 11:18:31 +0000 Simon Horman wrote:
>>> The "rx_vport_out_of_buffer" equals the sum of all
>>> Q counters out_of_buffer values allocated on the VF/SF.
>>
>> Hi Carolina and Tariq,
>>
>> I am wondering if any consideration was given to making this
>> a generic counter. Buffer exhaustion sounds like something that
>> other NICs may report too.
>
> I think it's basically rx_missed_errors from rtnl_link_stats64.
> mlx5 doesn't currently report it at all, AFAICT.
>
We expose it in ethtool stats.
Note that the "local" RX buffer exhaustion counter exists for a long time.
Here we introduce in the representor kind of a "remote" version of the
counter, to help providers monitor RX drops that occur in the customers'
side.
It follows the local counter hence currently it is not generic.
Powered by blists - more mailing lists