Re: [virtio-comment] Re: About custom device counter

[Xuan Zhuo <xuanzhuo@linux.alibaba.com>]

On Mon, 19 Jun 2023 10:20:56 -0400, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Jun 19, 2023 at 12:33:33PM +0000, Parav Pandit wrote:
> >
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Friday, June 16, 2023 10:13 AM
> > > > Such as "limit", in a cloud scenario, multiple users purchase
> > > > different VMs, and these VMs share the capabilities of the same host.
> > > > In order to ensure that each VM will not affect others, the network
> > > > card(virtio-net) capability of each VM is limited. When these users purchase
> > > VMs, this limit has already been determined.
> > > > So if the network card traffic of a vm exceeds the upper limit, packet
> > > > loss will occur. It is necessary for us to count these packet losses.
> > > > And the device should expose to the user.
> > >
> > > OK so here, driver is expected to rate limit yes?
> > >
> > Some implementations of txq are lossy and some are not creating backpressure/flow control to driver so driver can rate limit it naturally.
> > So a tx packet drop counter is needed to cover the lossy implementations which is abstract enough regardless of reason on why device dropped it.
>
>
> Yes but Xuan Zhuo here is saying that he wants a register that is
> like link speed, not a counter.
>

A counter.

This is a capability, but it only exists between the device and the user. The
capability is set when the user buys a network card, so it has nothing to do
with the driver. As a result, some packets were lost, and we hope that these
counter can be passed to users. Because this capability has nothing to do
with the virtio spec, we always want it to be a vendor custom counter.

Of course, some parameters can be abstracted, and we are very happy to do so.
But I am worried that this will lead to inaccurate expressions of meaning.

Anyway we can try something out, I'll sort out some of the counters we'd like to
have. There are also some that I think we want to customize. We discuss further
based on these counters.


Thanks.


>
> > A more granular counter becomes vendor specific that we can possibly avoid or place under different command.
>
>
> --
> MST
>