[PATCH net-next] virtio_net: Add ethtool stats

The main purpose of this patch is adding a way of checking per-queue stats. It's useful to debug performance problems on multiqueue environment. $ ethtool -S ens10 NIC statistics: rx_packets: 4172939 tx_packets: 5855538 rx_bytes: 6317757408 tx_bytes: 8865151846

[PATCH v4 4/4] virtio_remoteproc: don't kfree device on register failure

rproc_virtio_dev_release will be called iff virtio_device.dev's refer count became to 0. Here we should check if we call device_register or not, if called, put vdev.dev, and then rproc->dev's cleanup will be done in rproc_virtio_dev_release, otherwise we do cleanup directly. Signed-off-by:

[PATCH v4 3/4] virtio_vop: don't kfree device on register failure

As mentioned at drivers/base/core.c: /* * NOTE: _Never_ directly free @dev after calling this function, even * if it returned an error! Always use put_device() to give up the * reference initialized in this function instead. */ so we don't free vdev until vdev->vdev.dev.release be called.

[PATCH v4 1/4] virtio: split device_register into device_initialize and device_add

In order to make caller do a simple cleanup, we split device_register into device_initialize and device_add. device_initialize always sucess, the caller can always use put_device when fail to register virtio_device no matter fail at ida_simple_get or at device_add. Signed-off-by: weiping zhang

[PATCH v4 2/4] virtio_pci: don't kfree device on register failure

As mentioned at drivers/base/core.c: /* * NOTE: _Never_ directly free @dev after calling this function, even * if it returned an error! Always use put_device() to give up the * reference initialized in this function instead. */ so we don't free vp_dev until vp_dev->vdev.dev.release be called.

[PATCH v4 0/4] use put_device to cleanup resource

Hi, The main change is split device_register into 2 sperate calls: device_initalize() and device_add, and then the caller can use put_device safety when fail to register_virtio_device. v3->v4: * split device_register into device_initialize and devicea_add that the caller can always use

Re: [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available

On Tue, 19 Dec 2017 14:37:50 -0800 "Samudrala, Sridhar" wrote: > On 12/19/2017 11:46 AM, Stephen Hemminger wrote: > > On Tue, 19 Dec 2017 11:42:33 -0800 > > "Samudrala, Sridhar" wrote: > > > >> On 12/19/2017 10:41 AM, Stephen Hemminger

Re: [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available

On Tue, 19 Dec 2017 11:42:33 -0800 "Samudrala, Sridhar" wrote: > On 12/19/2017 10:41 AM, Stephen Hemminger wrote: > > On Tue, 19 Dec 2017 13:21:17 -0500 (EST) > > David Miller wrote: > > > >> From: Stephen Hemminger

Re: [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available

On Tue, 19 Dec 2017 13:21:17 -0500 (EST) David Miller wrote: > From: Stephen Hemminger > Date: Tue, 19 Dec 2017 09:55:48 -0800 > > > could be 10ms, just enough to let udev do its renaming > > Please, move to some kind of notification or event

Re: [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available

From: Stephen Hemminger Date: Tue, 19 Dec 2017 09:55:48 -0800 > could be 10ms, just enough to let udev do its renaming Please, move to some kind of notification or event based handling of this problem. No delay is safe, what if userspace gets swapped out or whatever

Re: [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available

From: "Samudrala, Sridhar" Date: Tue, 19 Dec 2017 09:41:39 -0800 > This is based on netvsc implementation and here is the commit that > added this delay.  Not sure if this needs to be 100ms. > > commit 6123c66854c174e4982f98195100c1d990f9e5e6 > Author: stephen

Re: [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available

On Tue, 19 Dec 2017 20:07:01 +0200 "Michael S. Tsirkin" wrote: > On Tue, Dec 19, 2017 at 09:55:48AM -0800, Stephen Hemminger wrote: > > On Tue, 19 Dec 2017 09:41:39 -0800 > > "Samudrala, Sridhar" wrote: > > > > > On 12/19/2017 7:47 AM, Michael S.

Re: [PATCH v20 0/7] Virtio-balloon Enhancement

On Tue, Dec 19, 2017 at 11:05:11PM +0900, Tetsuo Handa wrote: > Wei Wang wrote: > > ChangeLog: > > v19->v20: > > 1) patch 1: xbitmap > > - add __rcu to "void **slot"; > > - remove the exceptional path. > > 2) patch 3: xbitmap > > - DeveloperNotes: add an item to comment that the

Re: [RFC PATCH] virtio_net: Extend virtio to use VF datapath when available

On Tue, Dec 19, 2017 at 09:55:48AM -0800, Stephen Hemminger wrote: > On Tue, 19 Dec 2017 09:41:39 -0800 > "Samudrala, Sridhar" wrote: > > > On 12/19/2017 7:47 AM, Michael S. Tsirkin wrote: > > > I'll need to look at this more, in particular the feature > > > bit is

Re: [PATCH v20 0/7] Virtio-balloon Enhancement

On Tue, Dec 19, 2017 at 11:05:11PM +0900, Tetsuo Handa wrote: > Removing exceptional path made this patch easier to read. > But what I meant is > > Can you eliminate exception path and fold all xbitmap patches into one, and > post only one xbitmap patch without virtio-balloon changes? > > .

[PATCH v20 7/7] virtio-balloon: don't report free pages when page poisoning is enabled

The guest free pages should not be discarded by the live migration thread when page poisoning is enabled with PAGE_POISONING_NO_SANITY=n, because skipping the transfer of such poisoned free pages will trigger false positive when new pages are allocated and checked on the destination. This patch

[PATCH v20 6/7] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the support of reporting hints of guest free pages to host via virtio-balloon. Host requests the guest to report free pages by sending a new cmd id to the guest via the free_page_report_cmd_id configuration register. When the

[PATCH v20 5/7] mm: support reporting free page blocks

This patch adds support to walk through the free page blocks in the system and report them via a callback function. Some page blocks may leave the free list after zone->lock is released, so it is the caller's responsibility to either detect or prevent the use of such pages. One use example of

[PATCH v20 3/7] xbitmap: add more operations

This patch adds support to find next 1 or 0 bit in a xbmitmap range and clear a range of bits. More possible optimizations to add in the future: 1) xb_set_bit_range: set a range of bits. 2) when searching a bit, if the bit is not found in the slot, move on to the next slot directly. 3) add tags

[PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

Add a new feature, VIRTIO_BALLOON_F_SG, which enables the transfer of balloon (i.e. inflated/deflated) pages using scatter-gather lists to the host. The implementation of the previous virtio-balloon is not very efficient, because the balloon pages are transferred to the host by one array each

[PATCH v20 1/7] xbitmap: Introduce xbitmap

From: Matthew Wilcox The eXtensible Bitmap is a sparse bitmap representation which is efficient for set bits which tend to cluster. It supports up to 'unsigned long' worth of bits, and this commit adds the bare bones -- xb_set_bit(), xb_clear_bit() and xb_test_bit().

[PATCH v20 0/7] Virtio-balloon Enhancement

This patch series enhances the existing virtio-balloon with the following new features: 1) fast ballooning: transfer ballooned pages between the guest and host in chunks using sgs, instead of one array each time; and 2) free page block reporting: a new virtqueue to report guest free pages to the

[PATCH v20 2/7] xbitmap: potential improvement

This patch made some changes to the original xbitmap implementation from the linux-dax tree: - xb_set_bit: delete the new inserted radix_tree_node when failing to get the per cpu ida bitmap, this avoids the kind of memory leak of the unused radix tree node left in the tree. - xb_preload:

Re: [PATCH v3 5/5] virtio: add comments for virtio_register_device

On Sun, 17 Dec 2017 21:48:05 +0800 weiping zhang wrote: > As mentioned at drivers/base/core.c: > /* > * NOTE: _Never_ directly free @dev after calling this function, even > * if it returned an error! Always use put_device() to give up the > * reference initialized in this

Re: Possible unsafe usage of skb->cb in virtio-net

On 2017年11月02日 21:01, Michael S. Tsirkin wrote: On Thu, Nov 02, 2017 at 11:40:36AM +, Ilya Lesokhin wrote: Hi, I've noticed that the virtio-net uses skb->cb. I don't know all the detail by my understanding is it caused problem with the mlx5 driver and was fixed here: