similar to: [PATCH -next] virtio_net: Update the feature bit to comply with spec

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

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

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> --- v1->v2: * Fixed omitted hunk from

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> --- v1->v2: * Fixed omitted hunk from

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 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

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 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

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 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

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 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