similar to: [PATCH net-next v2 6/9] net: use core MTU range checking in virt drivers

On Thu, Oct 20, 2016 at 01:55:21PM -0400, Jarod Wilson wrote: > hyperv_net: > - set min/max_mtu, per Haiyang, after rndis_filter_device_add > > virtio_net: > - set min/max_mtu > - remove virtnet_change_mtu > vmxnet3: > - set min/max_mtu > > xen-netback: > - min_mtu = 0, max_mtu = 65517 > > xen-netfront: > - min_mtu = 0, max_mtu = 65535 > >

hyperv_net: - set min/max_mtu virtio_net: - set min/max_mtu - remove virtnet_change_mtu vmxnet3: - set min/max_mtu CC: netdev at vger.kernel.org CC: virtualization at lists.linux-foundation.org CC: "K. Y. Srinivasan" <kys at microsoft.com> CC: Haiyang Zhang <haiyangz at microsoft.com> CC: "Michael S. Tsirkin" <mst at redhat.com> CC: Shrikrishna Khare

hyperv_net: - set min/max_mtu virtio_net: - set min/max_mtu - remove virtnet_change_mtu vmxnet3: - set min/max_mtu CC: netdev at vger.kernel.org CC: virtualization at lists.linux-foundation.org CC: "K. Y. Srinivasan" <kys at microsoft.com> CC: Haiyang Zhang <haiyangz at microsoft.com> CC: "Michael S. Tsirkin" <mst at redhat.com> CC: Shrikrishna Khare

On Thu, Oct 20, 2016 at 11:23:54PM +0300, Michael S. Tsirkin wrote: > On Thu, Oct 20, 2016 at 01:55:21PM -0400, Jarod Wilson wrote: ... > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > index fad84f3..720809f 100644 > > --- a/drivers/net/virtio_net.c > > +++ b/drivers/net/virtio_net.c > > @@ -1419,17 +1419,6 @@ static const struct ethtool_ops

On Thu, Oct 20, 2016 at 11:23:54PM +0300, Michael S. Tsirkin wrote: > On Thu, Oct 20, 2016 at 01:55:21PM -0400, Jarod Wilson wrote: ... > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > index fad84f3..720809f 100644 > > --- a/drivers/net/virtio_net.c > > +++ b/drivers/net/virtio_net.c > > @@ -1419,17 +1419,6 @@ static const struct ethtool_ops

From: Aaron Conole <aconole at bytheb.org> The virtio committee recently ratified a change, VIRTIO-152, which defines the mtu field to be 'max' MTU, not simply desired MTU. This commit brings the virtio-net device in compliance with VIRTIO-152. Additionally, drop the max_mtu branch - it cannot be taken since the u16 returned by virtio_cread16 will never exceed the initial value of

From: Aaron Conole <aconole at bytheb.org> The virtio committee recently ratified a change, VIRTIO-152, which defines the mtu field to be 'max' MTU, not simply desired MTU. This commit brings the virtio-net device in compliance with VIRTIO-152. Additionally, drop the max_mtu branch - it cannot be taken since the u16 returned by virtio_cread16 will never exceed the initial value of

On Wed, Oct 19, 2016 at 04:59:46PM +0300, Michael S. Tsirkin wrote: > On Tue, Oct 18, 2016 at 10:33:32PM -0400, Jarod Wilson wrote: > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > index fad84f3..4885a42 100644 > > --- a/drivers/net/virtio_net.c > > +++ b/drivers/net/virtio_net.c > > @@ -1419,17 +1419,6 @@ static const struct ethtool_ops

On Wed, Oct 19, 2016 at 04:59:46PM +0300, Michael S. Tsirkin wrote: > On Tue, Oct 18, 2016 at 10:33:32PM -0400, Jarod Wilson wrote: > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > index fad84f3..4885a42 100644 > > --- a/drivers/net/virtio_net.c > > +++ b/drivers/net/virtio_net.c > > @@ -1419,17 +1419,6 @@ static const struct ethtool_ops

> -----Original Message----- > From: Jarod Wilson [mailto:jarod at redhat.com] > Sent: Tuesday, October 18, 2016 10:34 PM > To: linux-kernel at vger.kernel.org > Cc: Jarod Wilson <jarod at redhat.com>; netdev at vger.kernel.org; > virtualization at lists.linux-foundation.org; KY Srinivasan > <kys at microsoft.com>; Haiyang Zhang <haiyangz at microsoft.com>;

The virtio committee recently ratified a change, VIRTIO-152, which defines the mtu field to be 'max' MTU, not simply desired MTU. This commit brings the virtio-net device in compliance with VIRTIO-152. Additionally, drop the max_mtu branch - it cannot be taken since the u16 returned by virtio_cread16 will never exceed the initial value of max_mtu. Signed-off-by: Aaron Conole <aconole

The virtio committee recently ratified a change, VIRTIO-152, which defines the mtu field to be 'max' MTU, not simply desired MTU. This commit brings the virtio-net device in compliance with VIRTIO-152. Additionally, drop the max_mtu branch - it cannot be taken since the u16 returned by virtio_cread16 will never exceed the initial value of max_mtu. Signed-off-by: Aaron Conole <aconole

On Thu, Oct 20, 2016 at 10:37:20PM -0400, Jarod Wilson wrote: > On Thu, Oct 20, 2016 at 11:23:54PM +0300, Michael S. Tsirkin wrote: > > On Thu, Oct 20, 2016 at 01:55:21PM -0400, Jarod Wilson wrote: > ... > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > > index fad84f3..720809f 100644 > > > --- a/drivers/net/virtio_net.c > >

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_STANDBY that can be used

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

Some drivers can't support all features in all configurations. At the moment we blindly set FEATURES_OK and later FAILED. Support this better by adding a callback drivers can use to do some early checks. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio.c | 6 ++++++ include/linux/virtio.h | 1 + 2 files changed, 7 insertions(+) diff --git

Some drivers can't support all features in all configurations. At the moment we blindly set FEATURES_OK and later FAILED. Support this better by adding a callback drivers can use to do some early checks. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio.c | 6 ++++++ include/linux/virtio.h | 1 + 2 files changed, 7 insertions(+) diff --git

On Tue, Oct 18, 2016 at 10:33:32PM -0400, Jarod Wilson wrote: > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index fad84f3..4885a42 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -1419,17 +1419,6 @@ static const struct ethtool_ops virtnet_ethtool_ops = { > .set_settings = virtnet_set_settings, > }; > > -#define

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