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

["Arinzon, David" <darinzon@amazon.com>]

> > > > 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?