netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Michael Dalton <mwdalton@google.com>
Cc: netdev@vger.kernel.org,
	lf-virt <virtualization@lists.linux-foundation.org>,
	Eric Dumazet <edumazet@google.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next v2 4/4] virtio-net: initial debugfs support, export mergeable rx buffer size
Date: Sun, 12 Jan 2014 19:09:39 +0200	[thread overview]
Message-ID: <20140112170939.GA17202@redhat.com> (raw)
In-Reply-To: <CANJ5vP+Qxa5j_Cp1FBK-qdO+U+dy2kiY5N2bmWdMKbCoY9EwDQ@mail.gmail.com>

On Fri, Jan 10, 2014 at 09:19:37PM -0800, Michael Dalton wrote:
> Hi Jason, Michael
> 
> Sorry for the delay in response. Jason, I agree this patch ended up
> being larger than expected. The major implementation parts are:
> (1) Setup directory structure (driver/per-netdev/rx-queue directories)
> (2) Network device renames (optional, so debugfs dir has the right name)
> (3) Support resizing the # of RX queues (optional - we could just export
>     max_queue_pairs files and not delete files if an RX queue is disabled)
> (4) Reference counting - used in case someone opens a debugfs
>     file and then removes the virtio-net device.
> (5) The actual mergeable rx buffer file implementation itself. For now
>     I have added a seqcount for memory safety, but if a read-only race
>     condition is acceptable we could elide the seqcount. FWIW, the
>     seqcount write in receive_mergeable() should, on modern x86,
>     translate to two non-atomic adds and two compiler barriers, so
>     overhead is not expected to be meaningful.
> 
> We can move to sysfs and this would simplify or eliminate much of the
> above, including most of (1) - (4). I believe our choices for what to
> do for the next patchset include:
> (a) Use debugfs as is currently done, removing any optional features
> listed above that are deemed unnecessary.
> 
> (b) Add a per-netdev sysfs attribute group to net_device->sysfs_groups.
> Each attribute would display the mergeable packet buffer size for a given
> RX queue, and there would be max_queue_pairs attributes in total. This
> is already supported by net/core/net-sysfs.c:netdev_register_kobject(),
> but means that we would have a static set of per-RX queue files for
> all RX queues supported by the netdev, rather than dynamically displaying
> only the files corresponding to enabled RX queues (e.g., when # of RX
> queues is changed by  ethtool -L <device>).  For an example of this
> approach, see drivers/net/bonding/bond_sysfs.c.
> 
> (c) Modify struct netdev_rx_queue to add virtio-net EWMA fields directly,
> and modify net-sysfs.c to manage the new fields. Unlike (b), this approach
> supports the RX queue resizing in (3) but means putting virtio-net info
> in netdev_rx_queue, which currently has only device-independent fields.

Can't we add struct attribute * to netdevice, and pass that in when
creating the kobj?

> My preference would be (b): try using sysfs and adding a device-specific
> attribute group to the virtio-net netdevice (stored in the existing
> 'sysfs_groups' field and supported by net-sysfs).  This would avoid
> adding virtio-net specific information to net-sysfs. What would you
> prefer (or is there a better way than the approaches above)? Thanks!
> 
> Best,
> 
> Mike

  parent reply	other threads:[~2014-01-12 17:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-07  5:25 [PATCH net-next v2 1/4] net: allow > 0 order atomic page alloc in skb_page_frag_refill Michael Dalton
2014-01-07  5:25 ` [PATCH net-next v2 2/4] virtio-net: use per-receive queue page frag alloc for mergeable bufs Michael Dalton
2014-01-07  5:25 ` [PATCH net-next v2 3/4] virtio-net: auto-tune mergeable rx buffer size for improved performance Michael Dalton
2014-01-08  6:23   ` Jason Wang
2014-01-08 18:28     ` Michael Dalton
2014-01-08 18:44       ` Eric Dumazet
2014-01-08 19:16       ` Michael S. Tsirkin
2014-01-08 19:56         ` Michael Dalton
2014-01-08 20:30   ` Michael S. Tsirkin
2014-01-09  1:42   ` Michael S. Tsirkin
2014-01-09  3:16     ` Michael Dalton
2014-01-09  3:41       ` Michael Dalton
2014-01-09  6:48         ` Michael S. Tsirkin
2014-01-09  8:28           ` Michael Dalton
2014-01-09  9:02             ` Michael Dalton
2014-01-09 13:25             ` Michael S. Tsirkin
2014-01-09 19:33               ` Michael Dalton
2014-01-09  6:42       ` Michael S. Tsirkin
2014-01-07  5:25 ` [PATCH net-next v2 4/4] virtio-net: initial debugfs support, export mergeable rx buffer size Michael Dalton
2014-01-08  6:34   ` Jason Wang
2014-01-08 19:21     ` Michael S. Tsirkin
2014-01-11  5:19       ` Michael Dalton
2014-01-11  5:36         ` Michael Dalton
2014-01-12 17:09         ` Michael S. Tsirkin [this message]
2014-01-12 23:32           ` Michael Dalton
2014-01-13  7:36             ` Jason Wang
2014-01-13  9:40             ` Michael S. Tsirkin
2014-01-13 15:38               ` Ben Hutchings
2014-01-13 19:07                 ` Michael Dalton
2014-01-13 19:19                   ` Michael Dalton
2014-01-14 21:45                     ` Michael Dalton
2014-01-14 21:53                       ` Michael S. Tsirkin
2014-01-08 18:24   ` Michael S. Tsirkin
2014-01-08 18:08 ` [PATCH net-next v2 1/4] net: allow > 0 order atomic page alloc in skb_page_frag_refill Michael S. Tsirkin
2014-01-08 18:26   ` Eric Dumazet
2014-01-08 19:18     ` Michael S. Tsirkin
2014-01-08 19:46       ` Eric Dumazet
2014-01-08 21:54         ` Debabrata Banerjee
2014-01-08 22:01           ` 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=20140112170939.GA17202@redhat.com \
    --to=mst@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=mwdalton@google.com \
    --cc=netdev@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).