From: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
Jason Wang <jasowang@redhat.com>, Parav Pandit <parav@nvidia.com>
Subject: [virtio-dev] Re: [virtio-comment] Re: About custom device counter
Date: Tue, 20 Jun 2023 10:45:51 +0800 [thread overview]
Message-ID: <1687229151.8558426-2-xuanzhuo@linux.alibaba.com> (raw)
In-Reply-To: <20230619101745-mutt-send-email-mst@kernel.org>
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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2023-06-20 2:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 6:12 [virtio-dev] About custom device counter Xuan Zhuo
2023-06-12 6:25 ` [virtio-dev] " Michael S. Tsirkin
2023-06-12 11:27 ` [virtio-dev] Re: [virtio-comment] " Xuan Zhuo
2023-06-13 9:02 ` Michael S. Tsirkin
2023-06-15 6:23 ` Xuan Zhuo
2023-06-16 0:57 ` Jason Wang
2023-06-16 1:36 ` Xuan Zhuo
2023-06-16 14:42 ` Michael S. Tsirkin
2023-06-16 14:13 ` Michael S. Tsirkin
2023-06-19 1:44 ` Xuan Zhuo
2023-06-19 12:33 ` [virtio-dev] " Parav Pandit
2023-06-19 14:20 ` [virtio-dev] " Michael S. Tsirkin
2023-06-19 20:43 ` [virtio-dev] " Parav Pandit
2023-06-20 2:45 ` Xuan Zhuo [this message]
2023-06-19 14:25 ` [virtio-dev] " Michael S. Tsirkin
2023-06-20 2:55 ` Xuan Zhuo
2023-06-13 1:57 ` [virtio-dev] " Parav Pandit
2023-06-15 6:35 ` [virtio-dev] " Xuan Zhuo
2023-06-19 20:40 ` [virtio-dev] " Parav Pandit
2023-06-20 2:39 ` [virtio-dev] " Xuan Zhuo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1687229151.8558426-2-xuanzhuo@linux.alibaba.com \
--to=xuanzhuo@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox