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
next prev parent reply other threads:[~2014-01-12 17:09 UTC|newest]
Thread overview: 42+ 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-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-13 15:38 ` Ben Hutchings
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
2014-01-08 18:08 ` 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=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 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.