Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Cc: Jason Wang <jasowang@redhat.com>,
	Virtio-Dev <virtio-dev@lists.oasis-open.org>
Subject: [virtio-dev] Re: [PATCH v9] virtio-net: support device stats
Date: Mon, 28 Feb 2022 06:55:27 -0500	[thread overview]
Message-ID: <20220228064259-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <1646047299.629008-1-xuanzhuo@linux.alibaba.com>

On Mon, Feb 28, 2022 at 07:21:39PM +0800, Xuan Zhuo wrote:
> > struct stats{
> > /* the counters that doesn't need any features */
> > /* the counters that needs CSUM */
> > /* the counters that needs GSO */
> > /* the counters that needs reset */
> > }
> >
> > Or even split them into different commands. The reason is that the
> > current design requires the knowledge of a feature even if it doesn't
> > support it.
> 
> 
> I think this is a good idea.

The issue is this: some stats are only useful if they are correlated.
For example, # of rx interrupts is not useful unless you also know the #
of packets. Similar for GSO things. Is it necessary to correlate TX and
RX events? It might be if driver polls TX ring on an RX interrupt. In
all these cases we need a single command to return multiple stats for
atomicity. From that POV having a single struct is great, however if we
do it like this then it is not clear how are we going to extend it. Do
we just add fields at the end? Then the clean separation between RX and
TX fields is lost. Is it always enough to query a single pair of VQs?
E.g. when querying RSS, might we want to correlate between multiple
queues to see that traffic is balanced?

So maybe a good design will get an array of structures describing things
to query and return an array of structures describing the result.

-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2022-02-28 11:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15  7:47 [virtio-dev] [PATCH v9] virtio-net: support device stats Xuan Zhuo
2022-02-24 11:09 ` Xuan Zhuo
2022-02-28  9:07 ` [virtio-dev] " Jason Wang
2022-02-28 11:21   ` Xuan Zhuo
2022-02-28 11:55     ` Michael S. Tsirkin [this message]
2022-02-28 12:10       ` Xuan Zhuo
2022-02-28 11:40 ` Michael S. Tsirkin
2022-02-28 12:17   ` Xuan Zhuo
2022-02-28 13:56     ` Michael S. Tsirkin

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=20220228064259-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=xuanzhuo@linux.alibaba.com \
    /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