search for: bytheb

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

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

...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 at bytheb.org> > --- > v2: > * Whitespace cleanup in the last hunk > * Code style change around the pr_warn > * Additional test for mtu change before printing warning > > drivers/net/virtio_net.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/driver...

...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 at bytheb.org> > --- > v2: > * Whitespace cleanup in the last hunk > * Code style change around the pr_warn > * Additional test for mtu change before printing warning > > drivers/net/virtio_net.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/driver...

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

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

...d proper error handling. Instead, a > warning is emitted if the guest changes the device MTU after previously > being given advice. I don't see this as an error. Device might at best give a hint, user/network admin always knows best. > > Signed-off-by: Aaron Conole <aconole at bytheb.org> > --- > v2: > * Whitespace cleanup in the last hunk > * Code style change around the pr_warn > * Additional test for mtu change before printing warning > > drivers/net/virtio_net.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/driver...

...d proper error handling. Instead, a > warning is emitted if the guest changes the device MTU after previously > being given advice. I don't see this as an error. Device might at best give a hint, user/network admin always knows best. > > Signed-off-by: Aaron Conole <aconole at bytheb.org> > --- > v2: > * Whitespace cleanup in the last hunk > * Code style change around the pr_warn > * Additional test for mtu change before printing warning > > drivers/net/virtio_net.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/driver...

...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 at bytheb.org> --- v2: * Whitespace cleanup in the last hunk * Code style change around the pr_warn * Additional test for mtu change before printing warning drivers/net/virtio_net.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c inde...

This commit adds the feature bit and associated mtu device entry for the virtio network device. Future commits will make use of these bits to support negotiated MTU. Signed-off-by: Aaron Conole <aconole at bytheb.org> --- v2: * No change include/uapi/linux/virtio_net.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h index ec32293..41a6a01 100644 --- a/include/uapi/linux/virtio_net.h +++ b/include/uapi/linux/virtio_net.h @@ -55,6 +...

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