Re: [virtio-dev] Re: [PATCH v22 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

On 01/19/2018 08:39 PM, Michael S. Tsirkin wrote: On Fri, Jan 19, 2018 at 11:44:21AM +0800, Wei Wang wrote: On 01/18/2018 12:44 AM, Michael S. Tsirkin wrote: On Wed, Jan 17, 2018 at 01:10:11PM +0800, Wei Wang wrote: + vb->start_cmd_id = cmd_id; +

Re: [PATCH v2 net-next] virtio_net: Add ethtool stats

From: Toshiaki Makita Date: Wed, 17 Jan 2018 15:38:25 +0900 > 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: >

Re: [PATCH net-next 0/2] Enable virtio to act as a master for a passthru device

Apologies I didn't notice that the discussion was mistakenly taken offline. Post it back. -Siwei On Sat, Jan 13, 2018 at 7:25 AM, Siwei Liu wrote: > On Thu, Jan 11, 2018 at 12:32 PM, Samudrala, Sridhar > wrote: >> On 1/8/2018 9:22 AM, Siwei Liu

Re: [RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available

First off, as mentioned in another thread, the model of stacking up virt-bond functionality over virtio seems a wrong direction to me. Essentially the migration process would need to carry over all guest side configurations previously done on the VF/PT and get them moved to the new device being it

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On 1/22/2018 7:36 PM, Alexander Duyck wrote: On Mon, Jan 22, 2018 at 6:04 PM, Michael S. Tsirkin wrote: On Mon, Jan 22, 2018 at 05:34:37PM -0800, Samudrala, Sridhar wrote: On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote: On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala,

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On Mon, 22 Jan 2018 15:27:40 -0800 "Samudrala, Sridhar" wrote: > On 1/22/2018 1:31 PM, Michael S. Tsirkin wrote: > > On Wed, Jan 17, 2018 at 01:49:58PM -0800, Alexander Duyck wrote: > >> On Wed, Jan 17, 2018 at 11:57 AM, Michael S. Tsirkin > >>

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: > > > You could probably > > > even handle the Tx queue selection via a simple eBPF program and map > > > since the input for whatever is used to select Tx should be pretty > > > simple, destination MAC, source NUMA node, etc, and

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On Tue, 23 Jan 2018 02:05:48 +0200, Michael S. Tsirkin wrote: > > As we are using virtio_net to control and manage the VF data path, it is not > > clear to me > > what is the advantage of creating a new device rather than extending > > virtio_net to manage > > the VF datapath via transparent bond

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On Mon, Jan 22, 2018 at 04:16:23PM -0800, Jakub Kicinski wrote: > On Tue, 23 Jan 2018 02:05:48 +0200, Michael S. Tsirkin wrote: > > > As we are using virtio_net to control and manage the VF data path, it is > > > not > > > clear to me > > > what is the advantage of creating a new device rather

Re: [RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available

On 1/22/2018 12:27 PM, Siwei Liu wrote: First off, as mentioned in another thread, the model of stacking up virt-bond functionality over virtio seems a wrong direction to me. Essentially the migration process would need to carry over all guest side configurations previously done on the VF/PT and

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On 1/22/2018 1:31 PM, Michael S. Tsirkin wrote: On Wed, Jan 17, 2018 at 01:49:58PM -0800, Alexander Duyck wrote: On Wed, Jan 17, 2018 at 11:57 AM, Michael S. Tsirkin wrote: On Wed, Jan 17, 2018 at 11:25:41AM -0800, Samudrala, Sridhar wrote: On 1/17/2018 11:02 AM, Michael S.

Re: [RFC PATCH net-next v2 2/2] virtio_net: Extend virtio to use VF datapath when available

On Mon, Jan 22, 2018 at 12:27:14PM -0800, Siwei Liu wrote: > First off, as mentioned in another thread, the model of stacking up > virt-bond functionality over virtio seems a wrong direction to me. > Essentially the migration process would need to carry over all guest > side configurations

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On Wed, Jan 17, 2018 at 01:49:58PM -0800, Alexander Duyck wrote: > On Wed, Jan 17, 2018 at 11:57 AM, Michael S. Tsirkin wrote: > > On Wed, Jan 17, 2018 at 11:25:41AM -0800, Samudrala, Sridhar wrote: > >> > >> > >> On 1/17/2018 11:02 AM, Michael S. Tsirkin wrote: > >> > On Wed,

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On Mon, Jan 22, 2018 at 05:13:01PM -0800, Jakub Kicinski wrote: > On Tue, 23 Jan 2018 02:47:57 +0200, Michael S. Tsirkin wrote: > > On Mon, Jan 22, 2018 at 04:16:23PM -0800, Jakub Kicinski wrote: > > > On Tue, 23 Jan 2018 02:05:48 +0200, Michael S. Tsirkin wrote: > > > > > As we are using

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote: On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: You could probably even handle the Tx queue selection via a simple eBPF program and map since the input for whatever is used to select Tx should be pretty simple, destination MAC,

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On Tue, 23 Jan 2018 02:47:57 +0200, Michael S. Tsirkin wrote: > On Mon, Jan 22, 2018 at 04:16:23PM -0800, Jakub Kicinski wrote: > > On Tue, 23 Jan 2018 02:05:48 +0200, Michael S. Tsirkin wrote: > > > > As we are using virtio_net to control and manage the VF data path, it > > > > is not > > > >

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On 1/22/2018 4:02 PM, Stephen Hemminger wrote: In the case of SwitchDev it should be possible for the port representors and the switch to provide data on which interfaces are bonded on the host side and which aren't. With that data it would be pretty easy to just put together a list of

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On Mon, Jan 22, 2018 at 05:34:37PM -0800, Samudrala, Sridhar wrote: > On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote: > > On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: > > > > > You could probably > > > > > even handle the Tx queue selection via a simple eBPF program and map

Re: [virtio-dev] [RFC PATCH net-next v2 1/2] virtio_net: Introduce VIRTIO_NET_F_BACKUP feature bit

On Mon, Jan 22, 2018 at 6:04 PM, Michael S. Tsirkin wrote: > On Mon, Jan 22, 2018 at 05:34:37PM -0800, Samudrala, Sridhar wrote: >> On 1/22/2018 4:05 PM, Michael S. Tsirkin wrote: >> > On Mon, Jan 22, 2018 at 03:27:40PM -0800, Samudrala, Sridhar wrote: >> > > > > You could

Ping Re: [PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all

Vincent Legoll writes: > No need to get into the submenu to disable all VIRTIO-related > config entries. > > This makes it easier to disable all VIRTIO config options > without entering the submenu. It will also enable one > to see that en/dis-abled state from the