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: <460b64a1f3e8405fb553fbc04cef2db3@amazon.com>
Date: Wed, 21 Aug 2024 18:03:27 +0000
From: "Arinzon, David" <darinzon@...zon.com>
To: "Arinzon, David" <darinzon@...zon.com>, 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.
> 

I see that there's no feedback from Xuan or Michael.

Jakub, what are your thoughts about my suggestion?