similar to: [RFC -next 0/2] virtio-net: Advised MTU feature

On Thu, 2016-03-10 at 09:28 -0500, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes the

On Thu, 2016-03-10 at 09:28 -0500, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes the

The following series adds the ability for a hypervisor to set an MTU on the guest during feature negotiation phase. This is useful for VM orchestration when, for instance, tunneling is involved and the MTU of the various systems should be homogenous. The first patch adds the feature bit as described in the proposed VFIO spec addition found at

The following series adds the ability for a hypervisor to set an MTU on the guest during feature negotiation phase. This is useful for VM orchestration when, for instance, tunneling is involved and the MTU of the various systems should be homogenous. The first patch adds the feature bit as described in the proposed VFIO spec addition found at

Hello. On 03/10/2016 05:28 PM, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes the device

Hello. On 03/10/2016 05:28 PM, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes the device

On Tue, Mar 15, 2016 at 05:04:13PM -0400, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes

On Tue, Mar 15, 2016 at 05:04:13PM -0400, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes

Hello. On 3/16/2016 12:04 AM, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes the device

Hello. On 3/16/2016 12:04 AM, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes the device

The following series adds the ability for a hypervisor to set an MTU on the guest during feature negotiation phase. This is useful for VM orchestration when, for instance, tunneling is involved and the MTU of the various systems should be homogenous. The first patch adds the feature bit as described in the proposed VIRTIO spec addition found at

The following series adds the ability for a hypervisor to set an MTU on the guest during feature negotiation phase. This is useful for VM orchestration when, for instance, tunneling is involved and the MTU of the various systems should be homogenous. The first patch adds the feature bit as described in the proposed VIRTIO spec addition found at

This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it exists, read the advised MTU and use it. No proper error handling is provided for the case where a user changes the negotiated MTU. A future commit will add proper error handling. Instead, a warning is emitted if the guest changes the device MTU after previously being given advice. Signed-off-by: Aaron Conole <aconole

The following series adds the ability for a hypervisor to set an MTU on the guest during feature negotiation phase. This is useful for VM orchestration when, for instance, tunneling is involved and the MTU of the various systems should be homogenous. The first patch adds the feature bit as described in the proposed VFIO spec addition found at

The following series adds the ability for a hypervisor to set an MTU on the guest during feature negotiation phase. This is useful for VM orchestration when, for instance, tunneling is involved and the MTU of the various systems should be homogenous. The first patch adds the feature bit as described in the proposed VFIO spec addition found at

On Thu, Jun 02, 2016 at 11:43:31AM -0400, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes

On Thu, Jun 02, 2016 at 11:43:31AM -0400, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes

On Tue, 15 Mar 2016 17:04:12 -0400 Aaron Conole <aconole at redhat.com> wrote: > --- a/include/uapi/linux/virtio_net.h > +++ b/include/uapi/linux/virtio_net.h > @@ -55,6 +55,7 @@ > #define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow > * Steering */ > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */ > +#define VIRTIO_NET_F_MTU 25 /* Device

On Tue, 15 Mar 2016 17:04:12 -0400 Aaron Conole <aconole at redhat.com> wrote: > --- a/include/uapi/linux/virtio_net.h > +++ b/include/uapi/linux/virtio_net.h > @@ -55,6 +55,7 @@ > #define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow > * Steering */ > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */ > +#define VIRTIO_NET_F_MTU 25 /* Device

This commit adds the feature bit and associated mtu device entry for the virtio network device. When a virtio device comes up, it checks the feature bit for the VIRTIO_NET_F_MTU feature. If such feature bit is enabled, the driver will read the advised MTU and use it as the initial value. Signed-off-by: Aaron Conole <aconole at redhat.com> --- v2->v3: * Added a check for the MTU, and a