All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: Rick Jones <rick.jones2@hp.com>,
	mst@redhat.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	David Miller <davem@davemloft.net>
Subject: Re: [V2 RFC net-next PATCH 2/2] virtio_net: export more statistics through ethtool
Date: Fri, 08 Jun 2012 11:33:34 +0800	[thread overview]
Message-ID: <4FD1728E.20802@redhat.com> (raw)
In-Reply-To: <1339102567.2770.25.camel@bwh-desktop.uk.solarflarecom.com>

On 06/08/2012 04:56 AM, Ben Hutchings wrote:
> On Thu, 2012-06-07 at 13:39 -0700, Rick Jones wrote:
>> On 06/07/2012 01:24 PM, Ben Hutchings wrote:
>>> On Thu, 2012-06-07 at 13:05 -0700, David Miller wrote:
>>>> From: Ben Hutchings<bhutchings@solarflare.com>
>>>> Date: Thu, 7 Jun 2012 18:15:06 +0100
>>>>
>>>>> I would really like to see some sort of convention for presenting
>>>>> per-queue statistics through ethtool.  At the moment we have a complete
>>>>> mess of different formats:
>>>> Indeed.  Probably ${QUEUE_TYPE}-${INDEX}-${STATISTIC} is best.
>>>> With an agreed upon list of queue types such as "rx", "tx", "rxtx"
>>>> etc.
>>> I think we should leave the type names open-ended, as there are other
>>> useful groupings like per-virtual-port.  In that case the separator
>>> should be chosen to allow arbitrary type names without ambiguity.
>> So you mean like something along the lines of the presence of say '.'
>> indicating indent a level:
>>
>> rx_bytes:  1234
>>       myqueue1.rx_bytes: 234
>>       myqueue2.rx_bytes: 345
>>       ...
> Most drivers seem to want this sort of ordering/grouping:
>
> group0.foo
> group0.bar
> ...
> group1.foo
> group1.bar
> ...
>
> but if we have a standard way of indicating groups of statistics then
> the user can choose whether they want to reorder by type name.
>
> Ben.
>

Yes, it looks to me that the per-queue satistics were better:

- Simple and less synchronization.
- Good for future virtio-net multiqueue merging.

WARNING: multiple messages have this Message-ID (diff)
From: Jason Wang <jasowang@redhat.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: Rick Jones <rick.jones2@hp.com>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, rusty@rustcorp.com.au,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, mst@redhat.com
Subject: Re: [V2 RFC net-next PATCH 2/2] virtio_net: export more statistics through ethtool
Date: Fri, 08 Jun 2012 11:33:34 +0800	[thread overview]
Message-ID: <4FD1728E.20802@redhat.com> (raw)
In-Reply-To: <1339102567.2770.25.camel@bwh-desktop.uk.solarflarecom.com>

On 06/08/2012 04:56 AM, Ben Hutchings wrote:
> On Thu, 2012-06-07 at 13:39 -0700, Rick Jones wrote:
>> On 06/07/2012 01:24 PM, Ben Hutchings wrote:
>>> On Thu, 2012-06-07 at 13:05 -0700, David Miller wrote:
>>>> From: Ben Hutchings<bhutchings@solarflare.com>
>>>> Date: Thu, 7 Jun 2012 18:15:06 +0100
>>>>
>>>>> I would really like to see some sort of convention for presenting
>>>>> per-queue statistics through ethtool.  At the moment we have a complete
>>>>> mess of different formats:
>>>> Indeed.  Probably ${QUEUE_TYPE}-${INDEX}-${STATISTIC} is best.
>>>> With an agreed upon list of queue types such as "rx", "tx", "rxtx"
>>>> etc.
>>> I think we should leave the type names open-ended, as there are other
>>> useful groupings like per-virtual-port.  In that case the separator
>>> should be chosen to allow arbitrary type names without ambiguity.
>> So you mean like something along the lines of the presence of say '.'
>> indicating indent a level:
>>
>> rx_bytes:  1234
>>       myqueue1.rx_bytes: 234
>>       myqueue2.rx_bytes: 345
>>       ...
> Most drivers seem to want this sort of ordering/grouping:
>
> group0.foo
> group0.bar
> ...
> group1.foo
> group1.bar
> ...
>
> but if we have a standard way of indicating groups of statistics then
> the user can choose whether they want to reorder by type name.
>
> Ben.
>

Yes, it looks to me that the per-queue satistics were better:

- Simple and less synchronization.
- Good for future virtio-net multiqueue merging.

  parent reply	other threads:[~2012-06-08  3:33 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-06  7:52 [V2 RFC net-next PATCH 1/2] virtio_net: convert the statistics into array Jason Wang
2012-06-06  7:52 ` [V2 RFC net-next PATCH 2/2] virtio_net: export more statistics through ethtool Jason Wang
2012-06-06  8:27   ` Michael S. Tsirkin
2012-06-06  8:27     ` Michael S. Tsirkin
2012-06-06  9:37     ` Jason Wang
2012-06-06  9:37       ` Jason Wang
2012-06-06  9:32   ` Michael S. Tsirkin
2012-06-06  9:32     ` Michael S. Tsirkin
2012-06-07 17:15   ` Ben Hutchings
2012-06-07 17:15     ` Ben Hutchings
2012-06-07 20:05     ` David Miller
2012-06-07 20:05       ` David Miller
2012-06-07 20:24       ` Ben Hutchings
2012-06-07 20:24         ` Ben Hutchings
2012-06-07 20:39         ` Rick Jones
2012-06-07 20:39           ` Rick Jones
2012-06-07 20:56           ` Ben Hutchings
2012-06-07 20:56             ` Ben Hutchings
2012-06-07 20:58             ` Ben Hutchings
2012-06-07 20:58               ` Ben Hutchings
2012-06-08  3:33             ` Jason Wang [this message]
2012-06-08  3:33               ` Jason Wang
2012-06-07 22:19   ` Michael S. Tsirkin
2012-06-07 22:19     ` Michael S. Tsirkin
2012-06-08  3:35     ` Jason Wang
2012-06-08  3:35       ` Jason Wang
2012-06-08  7:02       ` Michael S. Tsirkin
2012-06-08  7:02         ` Michael S. Tsirkin
2012-06-08  7:04       ` Michael S. Tsirkin
2012-06-08  7:04         ` Michael S. Tsirkin
2012-06-06  8:22 ` [V2 RFC net-next PATCH 1/2] virtio_net: convert the statistics into array Eric Dumazet
2012-06-06  8:22   ` Eric Dumazet

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=4FD1728E.20802@redhat.com \
    --to=jasowang@redhat.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    --cc=virtualization@lists.linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.