search for: vby

Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be used by hypervisor to indicate that virtio_net interface should act as a backup for another device with the same MAC address. Ppatch 2 is in response to the community request for a 3 netdev solution. However, it creates some issues we'll get into in a moment. It extends virtio_net to use alternate datapath when available

Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be used by hypervisor to indicate that virtio_net interface should act as a backup for another device with the same MAC address. Ppatch 2 is in response to the community request for a 3 netdev solution. However, it creates some issues we'll get into in a moment. It extends virtio_net to use alternate datapath when available

Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudrala at intel.com wrote: >This patch enables virtio_net to switch over to a VF datapath when a VF >netdev is present with the same MAC address. It allows live migration >of a VM with a direct attached VF without the need to setup a bond/team >between a VF and virtio net device in the guest. > >The hypervisor needs to enable only

Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudrala at intel.com wrote: >This patch enables virtio_net to switch over to a VF datapath when a VF >netdev is present with the same MAC address. It allows live migration >of a VM with a direct attached VF without the need to setup a bond/team >between a VF and virtio net device in the guest. > >The hypervisor needs to enable only

This patch enables virtio_net to switch over to a VF datapath when a VF netdev is present with the same MAC address. It allows live migration of a VM with a direct attached VF without the need to setup a bond/team between a VF and virtio net device in the guest. The hypervisor needs to enable only one datapath at any time so that packets don't get looped back to the VM over the other

This patch enables virtio_net to switch over to a VF datapath when a VF netdev is present with the same MAC address. It allows live migration of a VM with a direct attached VF without the need to setup a bond/team between a VF and virtio net device in the guest. The hypervisor needs to enable only one datapath at any time so that packets don't get looped back to the VM over the other

On 4/6/2018 5:48 AM, Jiri Pirko wrote: > Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudrala at intel.com wrote: <snip> > >> + >> +static void virtnet_bypass_set_rx_mode(struct net_device *dev) >> +{ >> + struct virtnet_bypass_info *vbi = netdev_priv(dev); >> + struct net_device *child_netdev; >> + >> + rcu_read_lock(); >> +

Hi all! I saw TODO comment in nv50_vbo.c and decided to look at similar file, nvc0_vbo.c. I copied those two lines into nv50 with slight name change (nvc0->nv50) and apparently it doesn't fix any OpenGL app I have, but does not broke them further (I have compute pacthes currently applied, so some breakage expected). diff --git a/src/gallium/drivers/nouveau/nv50/nv50_vbo.c

On Fri, 16 Feb 2018 10:11:21 -0800, Sridhar Samudrala wrote: > This patch enables virtio_net to switch over to a VF datapath when a VF > netdev is present with the same MAC address. It allows live migration > of a VM with a direct attached VF without the need to setup a bond/team > between a VF and virtio net device in the guest. > > The hypervisor needs to enable only one

The main motivation for this patch is to enable cloud service providers to provide an accelerated datapath to virtio-net enabled VMs in a transparent manner with no/minimal guest userspace changes. This also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices. Patch 1 introduces a new feature bit VIRTIO_NET_F_BACKUP that can be used

Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudrala at intel.com wrote: >On 4/6/2018 5:48 AM, Jiri Pirko wrote: >> Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudrala at intel.com wrote: [...] >> > +static int virtnet_bypass_join_child(struct net_device *bypass_netdev, >> > + struct net_device *child_netdev) >> > +{ >> > + struct

Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudrala at intel.com wrote: >On 4/6/2018 5:48 AM, Jiri Pirko wrote: >> Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudrala at intel.com wrote: [...] >> > +static int virtnet_bypass_join_child(struct net_device *bypass_netdev, >> > + struct net_device *child_netdev) >> > +{ >> > + struct

Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala at intel.com wrote: >On 4/9/2018 1:07 AM, Jiri Pirko wrote: >> Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudrala at intel.com wrote: >> > On 4/6/2018 5:48 AM, Jiri Pirko wrote: >> > > Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudrala at intel.com wrote: >> [...] >> >> > > >

Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala at intel.com wrote: >On 4/9/2018 1:07 AM, Jiri Pirko wrote: >> Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudrala at intel.com wrote: >> > On 4/6/2018 5:48 AM, Jiri Pirko wrote: >> > > Thu, Apr 05, 2018 at 11:08:22PM CEST, sridhar.samudrala at intel.com wrote: >> [...] >> >> > > >

Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala at intel.com wrote: >On 4/10/2018 3:55 AM, Jiri Pirko wrote: >> Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala at intel.com wrote: >> > On 4/9/2018 1:07 AM, Jiri Pirko wrote: >> > > Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudrala at intel.com wrote: >> > > > On 4/6/2018 5:48 AM,

Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala at intel.com wrote: >On 4/10/2018 3:55 AM, Jiri Pirko wrote: >> Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala at intel.com wrote: >> > On 4/9/2018 1:07 AM, Jiri Pirko wrote: >> > > Sat, Apr 07, 2018 at 12:59:14AM CEST, sridhar.samudrala at intel.com wrote: >> > > > On 4/6/2018 5:48 AM,

Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala at intel.com wrote: >On 4/10/2018 8:22 AM, Jiri Pirko wrote: >> Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala at intel.com wrote: >> > On 4/10/2018 3:55 AM, Jiri Pirko wrote: >> > > Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala at intel.com wrote: >> > > > On 4/9/2018 1:07 AM,

Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala at intel.com wrote: >On 4/10/2018 8:22 AM, Jiri Pirko wrote: >> Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala at intel.com wrote: >> > On 4/10/2018 3:55 AM, Jiri Pirko wrote: >> > > Mon, Apr 09, 2018 at 08:47:06PM CEST, sridhar.samudrala at intel.com wrote: >> > > > On 4/9/2018 1:07 AM,

Tue, Apr 10, 2018 at 05:59:02PM CEST, sridhar.samudrala at intel.com wrote: >On 4/10/2018 8:43 AM, Jiri Pirko wrote: >> Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala at intel.com wrote: >> > On 4/10/2018 8:22 AM, Jiri Pirko wrote: >> > > Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala at intel.com wrote: >> > > > On 4/10/2018 3:55 AM,

Tue, Apr 10, 2018 at 05:59:02PM CEST, sridhar.samudrala at intel.com wrote: >On 4/10/2018 8:43 AM, Jiri Pirko wrote: >> Tue, Apr 10, 2018 at 05:27:48PM CEST, sridhar.samudrala at intel.com wrote: >> > On 4/10/2018 8:22 AM, Jiri Pirko wrote: >> > > Tue, Apr 10, 2018 at 05:13:40PM CEST, sridhar.samudrala at intel.com wrote: >> > > > On 4/10/2018 3:55 AM,