netdev - RE: [PATCH v1 net-next 2/2] net: ena: Extend customer metrics reporting support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0b222f4ddde14f9093d037db1a68d76a@amazon.com>
Date: Sat, 17 Aug 2024 04:42:43 +0000
From: "Arinzon, David" <darinzon@...zon.com>
To: Jakub Kicinski <kuba@...nel.org>, Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
	"Michael S. Tsirkin" <mst@...hat.com>
CC: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, "Michael S. Tsirkin"
	<mst@...hat.com>, David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>, Eric Dumazet
	<edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, "Woodhouse, David"
	<dwmw@...zon.co.uk>, "Machulsky, Zorik" <zorik@...zon.com>, "Matushevsky,
 Alexander" <matua@...zon.com>, "Bshara, Saeed" <saeedb@...zon.com>, "Wilson,
 Matt" <msw@...zon.com>, "Liguori, Anthony" <aliguori@...zon.com>, "Bshara,
 Nafea" <nafea@...zon.com>, "Belgazal, Netanel" <netanel@...zon.com>, "Saidi,
 Ali" <alisaidi@...zon.com>, "Herrenschmidt, Benjamin" <benh@...zon.com>,
	"Kiyanovski, Arthur" <akiyano@...zon.com>, "Dagan, Noam" <ndagan@...zon.com>,
	"Agroskin, Shay" <shayagr@...zon.com>, "Itzko, Shahar" <itzko@...zon.com>,
	"Abboud, Osama" <osamaabb@...zon.com>, "Ostrovsky, Evgeny"
	<evostrov@...zon.com>, "Tabachnik, Ofir" <ofirt@...zon.com>, "Beider, Ron"
	<rbeider@...zon.com>, "Chauskin, Igor" <igorch@...zon.com>, "Bernstein, Amit"
	<amitbern@...zon.com>, Parav Pandit <parav@...dia.com>, Cornelia Huck
	<cohuck@...hat.com>
Subject: RE: [PATCH v1 net-next 2/2] net: ena: Extend customer metrics reporting
 support

> > > Xuan, Michael, the virtio spec calls out drops due to b/w limit
> > > being exceeded, but AWS people say their NICs also count packets
> > > buffered but not dropped towards a similar metric.
> > >
> > > I presume the virtio spec is supposed to cover the same use cases.
> > > Have the stats been approved? Is it reasonable to extend the
> > > definition of the "exceeded" stats in the virtio spec to cover what AWS
> specifies?
> > > Looks like PR is still open:
> > > https://github.com/oasis-tcs/virtio-spec/issues/180
> >
> > How do we move forward with this patchset?
> > Regarding the counter itself, even though we don't support this at the
> > moment, I would recommend to keep the queued and dropped as split
> (for
> > example, add tx/rx-hw-queued-ratelimits, or something similar, if that
> > makes sense).
> 
> Could you share some background for your recommendation?
> As you say, the advice contradicts your own code :S Let's iron this out for
> virtio's benefit.
> 

The links I've shared before are of public AWS documentation, therefore, this is what AWS currently supports.
When looking at the definition of what queued and what dropped means, having such a separation
will benefit customers better as it will provide them more detailed information about the limits
that they're about to exceed or are already exceeding. A queued packet will be received with a
delay, while a dropped packet wouldn't arrive to the destination.
In both cases, customers need to look into their applications and network loads and see what should
be changed, but when I'm looking at a case where packets are dropped, it is more dire (in some use-cases)
that when packets are being delayed, which is possibly more transparent to some network loads that are
not looking for cases like low latency.

Even though the ENA driver can't support it at the moment, given that the stats interface is
aiming for other drivers to implement (based on their level of support), the level of granularity and separation
will be more generic and more beneficial to customers. In my opinion, the suggestion to virtio is more
posing a limitation based on what AWS currently supports than creating something
generic that other drivers will hopefully implement based on their NICs.

> You can resend the first patch separately in the meantime.

I prefer them to be picked up together.