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 https://lists.oasis-open.org/archives/virtio-dev/201603/msg00001.html The second patch adds a user of the bit, and a warning when the guest changes the MTU from the hypervisor advised MTU. Future patches may add more thorough error handling. v2: * Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni * Additional test before printing a warning Aaron Conole (2): virtio: Start feature MTU support virtio_net: Read the advised MTU drivers/net/virtio_net.c | 12 ++++++++++++ include/uapi/linux/virtio_net.h | 3 +++ 2 files changed, 15 insertions(+) -- 2.5.0
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 +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 supports Default MTU Negotiation */
#ifndef VIRTIO_NET_NO_LEGACY
#define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
@@ -73,6 +74,8 @@ struct virtio_net_config {
* Legal values are between 1 and 0x8000
*/
__u16 max_virtqueue_pairs;
+ /* Default maximum transmit unit advice */
+ __u16 mtu;
} __attribute__((packed));
/*
--
2.5.0
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 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
index 767ab11..429fe01 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -146,6 +146,7 @@ struct virtnet_info {
virtio_net_ctrl_ack ctrl_status;
u8 ctrl_promisc;
u8 ctrl_allmulti;
+ bool negotiated_mtu;
};
struct padded_vnet_hdr {
@@ -1390,8 +1391,11 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
{
+ struct virtnet_info *vi = netdev_priv(dev);
if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
return -EINVAL;
+ if ((vi->negotiated_mtu) && (dev->mtu != new_mtu))
+ pr_warn("changing mtu while the advised mtu bit exists.");
dev->mtu = new_mtu;
return 0;
}
@@ -1836,6 +1840,13 @@ static int virtnet_probe(struct virtio_device *vdev)
if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
vi->has_cvq = true;
+ if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
+ vi->negotiated_mtu = true;
+ dev->mtu = virtio_cread16(vdev,
+ offsetof(struct virtio_net_config,
+ mtu));
+ }
+
if (vi->any_header_sg)
dev->needed_headroom = vi->hdr_len;
@@ -2019,6 +2030,7 @@ static unsigned int features[] = {
VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ,
VIRTIO_NET_F_CTRL_MAC_ADDR,
VIRTIO_F_ANY_LAYOUT,
+ VIRTIO_NET_F_MTU,
};
static struct virtio_driver virtio_net_driver = {
--
2.5.0
On 03/15/2016 02:04 PM, Aaron Conole wrote:> 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 > https://lists.oasis-open.org/archives/virtio-dev/201603/msg00001.html > > The second patch adds a user of the bit, and a warning when the guest changes > the MTU from the hypervisor advised MTU. Future patches may add more thorough > error handling.How do you see this interacting with VMs getting MTU settings via DHCP? rick jones> > v2: > * Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni > * Additional test before printing a warning > > Aaron Conole (2): > virtio: Start feature MTU support > virtio_net: Read the advised MTU > > drivers/net/virtio_net.c | 12 ++++++++++++ > include/uapi/linux/virtio_net.h | 3 +++ > 2 files changed, 15 insertions(+) >
> > 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 specYou mean VIRTIO spec?> addition found at > https://lists.oasis-open.org/archives/virtio-dev/201603/msg00001.html > > The second patch adds a user of the bit, and a warning when the guest changes > the MTU from the hypervisor advised MTU. Future patches may add more thorough > error handling. > > v2: > * Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni > * Additional test before printing a warning > > Aaron Conole (2): > virtio: Start feature MTU support > virtio_net: Read the advised MTU > > drivers/net/virtio_net.c | 12 ++++++++++++ > include/uapi/linux/virtio_net.h | 3 +++ > 2 files changed, 15 insertions(+) > > -- > 2.5.0 > >
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 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 > index 767ab11..429fe01 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c[...]> @@ -1390,8 +1391,11 @@ static const struct ethtool_ops virtnet_ethtool_ops = { > > static int virtnet_change_mtu(struct net_device *dev, int new_mtu) > { > + struct virtnet_info *vi = netdev_priv(dev); > if (new_mtu < MIN_MTU || new_mtu > MAX_MTU) > return -EINVAL; > + if ((vi->negotiated_mtu) && (dev->mtu != new_mtu))Inner parens not needed, please be consistent with the code above. [...] MBR, Sergei
Michael S. Tsirkin
2016-Mar-16 14:24 UTC
[RFC v2 -next 2/2] virtio_net: Read the advised MTU
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 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/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index 767ab11..429fe01 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -146,6 +146,7 @@ struct virtnet_info { > virtio_net_ctrl_ack ctrl_status; > u8 ctrl_promisc; > u8 ctrl_allmulti; > + bool negotiated_mtu; > }; > > struct padded_vnet_hdr { > @@ -1390,8 +1391,11 @@ static const struct ethtool_ops virtnet_ethtool_ops = { > > static int virtnet_change_mtu(struct net_device *dev, int new_mtu) > { > + struct virtnet_info *vi = netdev_priv(dev); > if (new_mtu < MIN_MTU || new_mtu > MAX_MTU) > return -EINVAL; > + if ((vi->negotiated_mtu) && (dev->mtu != new_mtu)) > + pr_warn("changing mtu while the advised mtu bit exists.");I don't really see why are we warning here. Just drop this chunk, as well as the flag in struct virtnet_info.> dev->mtu = new_mtu; > return 0; > } > @@ -1836,6 +1840,13 @@ static int virtnet_probe(struct virtio_device *vdev) > if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ)) > vi->has_cvq = true; > > + if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) { > + vi->negotiated_mtu = true; > + dev->mtu = virtio_cread16(vdev, > + offsetof(struct virtio_net_config, > + mtu)); > + } > + > if (vi->any_header_sg) > dev->needed_headroom = vi->hdr_len; > > @@ -2019,6 +2030,7 @@ static unsigned int features[] = { > VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, > VIRTIO_NET_F_CTRL_MAC_ADDR, > VIRTIO_F_ANY_LAYOUT, > + VIRTIO_NET_F_MTU, > }; > > static struct virtio_driver virtio_net_driver = { > -- > 2.5.0
Stephen Hemminger
2016-Mar-16 18:23 UTC
[RFC v2 -next 1/2] virtio: Start feature MTU support
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 supports Default MTU Negotiation */ > > #ifndef VIRTIO_NET_NO_LEGACY > #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */ > @@ -73,6 +74,8 @@ struct virtio_net_config { > * Legal values are between 1 and 0x8000 > */ > __u16 max_virtqueue_pairs; > + /* Default maximum transmit unit advice */ > + __u16 mtu; > } __attribute__((packed)); > > /*You can't change user visible headers without breaking ABI. This structure might be used by other user code. Also how can this work if host is using old size of structure.
Rick Jones <rick.jones2 at hpe.com> writes:> On 03/15/2016 02:04 PM, Aaron Conole wrote: >> 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 >> https://lists.oasis-open.org/archives/virtio-dev/201603/msg00001.html >> >> The second patch adds a user of the bit, and a warning when the guest changes >> the MTU from the hypervisor advised MTU. Future patches may add more thorough >> error handling. > > How do you see this interacting with VMs getting MTU settings via DHCP?This is intended for networks where the VMs are not given MTU via DHCP. I don't think it should negatively interfere with such a network. Does that make sense? -Aaron> rick jones > >> >> v2: >> * Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni >> * Additional test before printing a warning >> >> Aaron Conole (2): >> virtio: Start feature MTU support >> virtio_net: Read the advised MTU >> >> drivers/net/virtio_net.c | 12 ++++++++++++ >> include/uapi/linux/virtio_net.h | 3 +++ >> 2 files changed, 15 insertions(+) >>
Pankaj Gupta <pagupta at redhat.com> writes:>> >> 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 > > You mean VIRTIO spec?Yes, sorry.>> addition found at >> https://lists.oasis-open.org/archives/virtio-dev/201603/msg00001.html >> >> The second patch adds a user of the bit, and a warning when the guest changes >> the MTU from the hypervisor advised MTU. Future patches may add more thorough >> error handling. >> >> v2: >> * Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni >> * Additional test before printing a warning >> >> Aaron Conole (2): >> virtio: Start feature MTU support >> virtio_net: Read the advised MTU >> >> drivers/net/virtio_net.c | 12 ++++++++++++ >> include/uapi/linux/virtio_net.h | 3 +++ >> 2 files changed, 15 insertions(+) >> >> -- >> 2.5.0 >> >>
Maybe Matching Threads
- [RFC v2 -next 1/2] virtio: Start feature MTU support
- [PATCH v3] virtio-net: Add initial MTU advice feature
- [PATCH v3] virtio-net: Add initial MTU advice feature
- [PATCH v2 -next] virtio-net: Add initial MTU advice feature
- [PATCH v2 -next] virtio-net: Add initial MTU advice feature