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

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

[Aaron Conole]

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

[RFC v2 -next 1/2] virtio: Start feature MTU support

[Aaron Conole]

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

[RFC v2 -next 2/2] virtio_net: Read the advised MTU

[Aaron Conole]

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

Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature

[Rick Jones]

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(+)
>

Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature

[Pankaj Gupta]

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

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

Re: [RFC v2 -next 2/2] virtio_net: Read the advised MTU

[Sergei Shtylyov]

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

Re: [RFC v2 -next 2/2] virtio_net: Read the advised MTU

[Michael S. Tsirkin]

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

Re: [RFC v2 -next 1/2] virtio: Start feature MTU support

[Stephen Hemminger]

On Tue, 15 Mar 2016 17:04:12 -0400
Aaron Conole <aconole@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.

Re: [RFC v2 -next 1/2] virtio: Start feature MTU support

[Michael S. Tsirkin]

On Wed, Mar 16, 2016 at 11:23:14AM -0700, Stephen Hemminger wrote:
> On Tue, 15 Mar 2016 17:04:12 -0400
> Aaron Conole <aconole@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.

Then this userspace is broken.

If someone uses virtio code one has to follow virtio spec.

And Virtio spec makes it very clear that
1. config space size can change at any time
2. fields can only be accessed if the correct feature bit
   has been both advertized in host bitmap and acknowledged
   in guest bitmap

> Also how can this
> work if host is using old size of structure.

It works because access is guarded by feature bit check.

-- 
MST

Re: [RFC v2 -next 1/2] virtio: Start feature MTU support

[Aaron Conole]

Stephen Hemminger <stephen@networkplumber.org> writes:

> On Tue, 15 Mar 2016 17:04:12 -0400
> Aaron Conole <aconole@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.

How else can this field be added and remain compliant with the spec? The
spec requires that mtu be passed in the virtio_net_config field.

As for old sizeof, I think the absence of the VIRTIO_NET_F_MTU bit being
asserted is confirmation that mtu is not valid (at least, it is implied
in the spec).

Thanks so much for the review, Stephen!

-Aaron

Re: [RFC v2 -next 2/2] virtio_net: Read the advised MTU

[Aaron Conole]

Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> writes:

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

Okay, I will do that.

Thanks so much for the review (again), Sergei!

-Aaron

> [...]
>
> MBR, Sergei

Re: [RFC v2 -next 2/2] virtio_net: Read the advised MTU

[Aaron Conole]

"Michael S. Tsirkin" <mst@redhat.com> writes:

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

Okay. I was warning because the user is changing this after telling to
use something different - but if you don't think it's an error, I will
drop it.

Thanks so much for the review, Michael!

-Aaron

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

Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature

[Aaron Conole]

Rick Jones <rick.jones2@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(+)
>>

Re: [RFC v2 -next 0/2] virtio-net: Advised MTU feature

[Aaron Conole]

Pankaj Gupta <pagupta@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
>> 
>> 

Re: [RFC v2 -next 1/2] virtio: Start feature MTU support

[Stephen Hemminger]

On Thu, 17 Mar 2016 17:10:55 -0400
Aaron Conole <aconole@redhat.com> wrote:

> Stephen Hemminger <stephen@networkplumber.org> writes:
> 
> > On Tue, 15 Mar 2016 17:04:12 -0400
> > Aaron Conole <aconole@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.
> 
> How else can this field be added and remain compliant with the spec? The
> spec requires that mtu be passed in the virtio_net_config field.
> 
> As for old sizeof, I think the absence of the VIRTIO_NET_F_MTU bit being
> asserted is confirmation that mtu is not valid (at least, it is implied
> in the spec).

Michael is right as long as the code checks for MTU flag before
referencing the mtu field, everything is fine.  Actually, the structure
is never used directly only by fetching fields with offsetof