RE: [PATCH v3 1/2] latencystats: fix receive sample MP issues

["Varghese, Vipin" <Vipin.Varghese@amd.com>]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Stephen

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Thursday, June 26, 2025 8:31 PM
> To: Varghese, Vipin <Vipin.Varghese@amd.com>
> Cc: dev@dpdk.org; David Marchand <david.marchand@redhat.com>;
> stable@dpdk.org
> Subject: Re: [PATCH v3 1/2] latencystats: fix receive sample MP issues
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Wed, 25 Jun 2025 11:31:43 +0000
> "Varghese, Vipin" <Vipin.Varghese@amd.com> wrote:
>
> > Following are our understanding
> >
> > 1. increase in multi-queue latency is attributed by spinlock.
> > 2. the lower latency with patch for multi-queue is because the lowest of all queues
> are taken into account.
> >
> > Question: will there be per queue min, max, avg stats be enhanced in future?
> >
> > Tested-by: Thiyagarajan P <Thiyagarajan.P@amd.com>
> > Reviewed-by: Vipin Varghese <Vipin.Varghese@amd.com>
>
>
> It would make sense for the latencystats to be per-port/per-queue and avoid the
> locking, but it would be a significant API change. If you actually use this then would
> be good to make it better.

Thank you for the update, we were thinking about measuring latency stats with RTE_FLOW QUEUE redirect. RTE_FLOW+QUEUE redirect is been used extensively in Virtual Ran and Packet core.

Hence we were inclined using per queue latency stats and jitter. As per my current understanding this will vary from NIC to NIC depending on ASIC and FPGA logic (for fixed function).