[Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Maxime Coquelin]

This series implements Virtio spec update from Aaron Conole which
defines a way for the host to expose its max MTU to the guest.

Changes since RFC v1:
---------------------
 - Rebased on top of v2.8.0-rc0 (2.7.90)
 - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
 - Add host_mtu property to be able to disable the feature from QEMU

Maxime Coquelin (3):
  vhost-user: Add new protocol feature MTU
  vhost-net: Add new MTU feature support
  virtio-net: Add MTU feature support

 hw/net/vhost_net.c             | 11 +++++++++++
 hw/net/virtio-net.c            | 14 ++++++++++++++
 hw/virtio/vhost-user.c         | 11 +++++++++++
 include/hw/virtio/vhost.h      |  1 +
 include/hw/virtio/virtio-net.h |  1 +
 include/net/vhost_net.h        |  2 ++
 6 files changed, 40 insertions(+)

-- 
2.7.4

[Qemu-devel] [RFC v2 1/3] vhost-user: Add new protocol feature MTU

[Maxime Coquelin]

This patch adds VHOST_USER_PROTOCOL_F_MTU protocol feature.

If supported, QEMU sends VHOST_USER_GET_MTU request to the client,
and expects a u64 reply containing the MTU advised for the guest.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Aaron Conole <aconole@redhat.com>
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
 hw/virtio/vhost-user.c    | 11 +++++++++++
 include/hw/virtio/vhost.h |  1 +
 2 files changed, 12 insertions(+)

diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 7ee92b3..eaf007d 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -32,6 +32,7 @@ enum VhostUserProtocolFeature {
     VHOST_USER_PROTOCOL_F_LOG_SHMFD = 1,
     VHOST_USER_PROTOCOL_F_RARP = 2,
     VHOST_USER_PROTOCOL_F_REPLY_ACK = 3,
+    VHOST_USER_PROTOCOL_F_MTU = 4,
 
     VHOST_USER_PROTOCOL_F_MAX
 };
@@ -59,6 +60,7 @@ typedef enum VhostUserRequest {
     VHOST_USER_GET_QUEUE_NUM = 17,
     VHOST_USER_SET_VRING_ENABLE = 18,
     VHOST_USER_SEND_RARP = 19,
+    VHOST_USER_GET_MTU = 20,
     VHOST_USER_MAX
 } VhostUserRequest;
 
@@ -186,6 +188,7 @@ static bool vhost_user_one_time_request(VhostUserRequest request)
     case VHOST_USER_RESET_OWNER:
     case VHOST_USER_SET_MEM_TABLE:
     case VHOST_USER_GET_QUEUE_NUM:
+    case VHOST_USER_GET_MTU:
         return true;
     default:
         return false;
@@ -602,6 +605,14 @@ static int vhost_user_init(struct vhost_dev *dev, void *opaque)
                 return err;
             }
         }
+
+        /* query the MTU we support if backend supports MTU feature */
+        if (dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_MTU)) {
+            err = vhost_user_get_u64(dev, VHOST_USER_GET_MTU, &dev->mtu);
+            if (err < 0) {
+                return err;
+            }
+        }
     }
 
     if (dev->migration_blocker == NULL &&
diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
index 1fe5aad..c674a05 100644
--- a/include/hw/virtio/vhost.h
+++ b/include/hw/virtio/vhost.h
@@ -51,6 +51,7 @@ struct vhost_dev {
     uint64_t backend_features;
     uint64_t protocol_features;
     uint64_t max_queues;
+    uint64_t mtu;
     bool started;
     bool log_enabled;
     uint64_t log_size;
-- 
2.7.4

[Qemu-devel] [RFC v2 2/3] vhost-net: Add new MTU feature support

[Maxime Coquelin]

If VHOST_USER_F_MTU feature is negociated, vhost-net makes the
advised MTU available to virtio-net through a vhost_net_get_mtu()
call.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Aaron Conole <aconole@redhat.com>
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
 hw/net/vhost_net.c      | 11 +++++++++++
 include/net/vhost_net.h |  2 ++
 2 files changed, 13 insertions(+)

diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
index f2d49ad..21057d6 100644
--- a/hw/net/vhost_net.c
+++ b/hw/net/vhost_net.c
@@ -74,6 +74,7 @@ static const int user_feature_bits[] = {
     VIRTIO_NET_F_HOST_ECN,
     VIRTIO_NET_F_HOST_UFO,
     VIRTIO_NET_F_MRG_RXBUF,
+    VIRTIO_NET_F_MTU,
 
     /* This bit implies RARP isn't sent by QEMU out of band */
     VIRTIO_NET_F_GUEST_ANNOUNCE,
@@ -435,6 +436,11 @@ int vhost_set_vring_enable(NetClientState *nc, int enable)
     return 0;
 }
 
+uint64_t vhost_net_get_mtu(struct vhost_net *net)
+{
+    return net->dev.mtu;
+}
+
 #else
 uint64_t vhost_net_get_max_queues(VHostNetState *net)
 {
@@ -501,4 +507,9 @@ int vhost_set_vring_enable(NetClientState *nc, int enable)
 {
     return 0;
 }
+
+uint64_t vhost_net_get_mtu(struct vhost_net *net)
+{
+    return 0;
+}
 #endif
diff --git a/include/net/vhost_net.h b/include/net/vhost_net.h
index 5a08eff..37de17b 100644
--- a/include/net/vhost_net.h
+++ b/include/net/vhost_net.h
@@ -35,4 +35,6 @@ int vhost_set_vring_enable(NetClientState * nc, int enable);
 
 uint64_t vhost_net_get_acked_features(VHostNetState *net);
 
+uint64_t vhost_net_get_mtu(struct vhost_net *net);
+
 #endif
-- 
2.7.4

[Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support

[Maxime Coquelin]

If negotiated, virtio-net gets the advised MTU from vhost-net,
and provides it to the guest through a new virtio_net_config
entry.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Aaron Conole <aconole@redhat.com
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
 hw/net/virtio-net.c            | 14 ++++++++++++++
 include/hw/virtio/virtio-net.h |  1 +
 2 files changed, 15 insertions(+)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 5009533..36843fe 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -55,6 +55,8 @@ static VirtIOFeature feature_sizes[] = {
      .end = endof(struct virtio_net_config, status)},
     {.flags = 1 << VIRTIO_NET_F_MQ,
      .end = endof(struct virtio_net_config, max_virtqueue_pairs)},
+    {.flags = 1 << VIRTIO_NET_F_MTU,
+     .end = endof(struct virtio_net_config, mtu)},
     {}
 };
 
@@ -81,6 +83,7 @@ static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config)
 
     virtio_stw_p(vdev, &netcfg.status, n->status);
     virtio_stw_p(vdev, &netcfg.max_virtqueue_pairs, n->max_queues);
+    virtio_stw_p(vdev, &netcfg.mtu, n->mtu);
     memcpy(netcfg.mac, n->mac, ETH_ALEN);
     memcpy(config, &netcfg, n->config_size);
 }
@@ -636,6 +639,14 @@ static void virtio_net_set_features(VirtIODevice *vdev, uint64_t features)
     } else {
         memset(n->vlans, 0xff, MAX_VLAN >> 3);
     }
+
+    if (virtio_has_feature(features, VIRTIO_NET_F_MTU)) {
+        NetClientState *nc = qemu_get_queue(n->nic);
+
+        if (get_vhost_net(nc->peer)) {
+            n->mtu = vhost_net_get_mtu(get_vhost_net(nc->peer));
+        }
+    }
 }
 
 static int virtio_net_handle_rx_mode(VirtIONet *n, uint8_t cmd,
@@ -1695,6 +1706,7 @@ static void virtio_net_set_config_size(VirtIONet *n, uint64_t host_features)
 {
     int i, config_size = 0;
     virtio_add_feature(&host_features, VIRTIO_NET_F_MAC);
+    virtio_add_feature(&host_features, VIRTIO_NET_F_MTU);
     for (i = 0; feature_sizes[i].flags != 0; i++) {
         if (host_features & feature_sizes[i].flags) {
             config_size = MAX(feature_sizes[i].end, config_size);
@@ -1922,6 +1934,8 @@ static Property virtio_net_properties[] = {
     DEFINE_PROP_STRING("tx", VirtIONet, net_conf.tx),
     DEFINE_PROP_UINT16("rx_queue_size", VirtIONet, net_conf.rx_queue_size,
                        VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE),
+    DEFINE_PROP_BIT("host_mtu", VirtIONet, host_features,
+                    VIRTIO_NET_F_MTU, true),
     DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h
index 0ced975..b6394c8 100644
--- a/include/hw/virtio/virtio-net.h
+++ b/include/hw/virtio/virtio-net.h
@@ -96,6 +96,7 @@ typedef struct VirtIONet {
     QEMUTimer *announce_timer;
     int announce_counter;
     bool needs_vnet_hdr_swap;
+    uint16_t mtu;
 } VirtIONet;
 
 void virtio_net_set_netclient_name(VirtIONet *n, const char *name,
-- 
2.7.4

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Michael S. Tsirkin]

On Thu, Nov 17, 2016 at 10:58:04PM +0100, Maxime Coquelin wrote:
> This series implements Virtio spec update from Aaron Conole which
> defines a way for the host to expose its max MTU to the guest.
> 
> Changes since RFC v1:
> ---------------------
>  - Rebased on top of v2.8.0-rc0 (2.7.90)
>  - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
>  - Add host_mtu property to be able to disable the feature from QEMU

John, I believe you wanted to test these patches.

> Maxime Coquelin (3):
>   vhost-user: Add new protocol feature MTU
>   vhost-net: Add new MTU feature support
>   virtio-net: Add MTU feature support
> 
>  hw/net/vhost_net.c             | 11 +++++++++++
>  hw/net/virtio-net.c            | 14 ++++++++++++++
>  hw/virtio/vhost-user.c         | 11 +++++++++++
>  include/hw/virtio/vhost.h      |  1 +
>  include/hw/virtio/virtio-net.h |  1 +
>  include/net/vhost_net.h        |  2 ++
>  6 files changed, 40 insertions(+)
> 
> -- 
> 2.7.4

Re: [Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support

[Michael S. Tsirkin]

On Thu, Nov 17, 2016 at 10:58:07PM +0100, Maxime Coquelin wrote:
> If negotiated, virtio-net gets the advised MTU from vhost-net,
> and provides it to the guest through a new virtio_net_config
> entry.
> 
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Aaron Conole <aconole@redhat.com
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---
>  hw/net/virtio-net.c            | 14 ++++++++++++++
>  include/hw/virtio/virtio-net.h |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 5009533..36843fe 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -55,6 +55,8 @@ static VirtIOFeature feature_sizes[] = {
>       .end = endof(struct virtio_net_config, status)},
>      {.flags = 1 << VIRTIO_NET_F_MQ,
>       .end = endof(struct virtio_net_config, max_virtqueue_pairs)},
> +    {.flags = 1 << VIRTIO_NET_F_MTU,
> +     .end = endof(struct virtio_net_config, mtu)},
>      {}
>  };
>  
> @@ -81,6 +83,7 @@ static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config)
>  
>      virtio_stw_p(vdev, &netcfg.status, n->status);
>      virtio_stw_p(vdev, &netcfg.max_virtqueue_pairs, n->max_queues);
> +    virtio_stw_p(vdev, &netcfg.mtu, n->mtu);
>      memcpy(netcfg.mac, n->mac, ETH_ALEN);
>      memcpy(config, &netcfg, n->config_size);
>  }
> @@ -636,6 +639,14 @@ static void virtio_net_set_features(VirtIODevice *vdev, uint64_t features)
>      } else {
>          memset(n->vlans, 0xff, MAX_VLAN >> 3);
>      }
> +
> +    if (virtio_has_feature(features, VIRTIO_NET_F_MTU)) {
> +        NetClientState *nc = qemu_get_queue(n->nic);
> +
> +        if (get_vhost_net(nc->peer)) {
> +            n->mtu = vhost_net_get_mtu(get_vhost_net(nc->peer));


This means migration breaks silently if you move from a bigger to
smaller mtu. We don't necessarily have to make it work,
but it should be detected and reported.

> +        }
> +    }
>  }
>  
>  static int virtio_net_handle_rx_mode(VirtIONet *n, uint8_t cmd,

What about non-vhost traffic? You need to ensure guest does
not get bigger packets.


> @@ -1695,6 +1706,7 @@ static void virtio_net_set_config_size(VirtIONet *n, uint64_t host_features)
>  {
>      int i, config_size = 0;
>      virtio_add_feature(&host_features, VIRTIO_NET_F_MAC);
> +    virtio_add_feature(&host_features, VIRTIO_NET_F_MTU);
>      for (i = 0; feature_sizes[i].flags != 0; i++) {
>          if (host_features & feature_sizes[i].flags) {
>              config_size = MAX(feature_sizes[i].end, config_size);
> @@ -1922,6 +1934,8 @@ static Property virtio_net_properties[] = {
>      DEFINE_PROP_STRING("tx", VirtIONet, net_conf.tx),
>      DEFINE_PROP_UINT16("rx_queue_size", VirtIONet, net_conf.rx_queue_size,
>                         VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE),
> +    DEFINE_PROP_BIT("host_mtu", VirtIONet, host_features,
> +                    VIRTIO_NET_F_MTU, true),
>      DEFINE_PROP_END_OF_LIST(),
>  };
>

Cross version migration support is missing here.

  
> diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h
> index 0ced975..b6394c8 100644
> --- a/include/hw/virtio/virtio-net.h
> +++ b/include/hw/virtio/virtio-net.h
> @@ -96,6 +96,7 @@ typedef struct VirtIONet {
>      QEMUTimer *announce_timer;
>      int announce_counter;
>      bool needs_vnet_hdr_swap;
> +    uint16_t mtu;
>  } VirtIONet;
>  
>  void virtio_net_set_netclient_name(VirtIONet *n, const char *name,
> -- 
> 2.7.4

Re: [Qemu-devel] [RFC v2 2/3] vhost-net: Add new MTU feature support

[Michael S. Tsirkin]

On Thu, Nov 17, 2016 at 10:58:06PM +0100, Maxime Coquelin wrote:
> If VHOST_USER_F_MTU feature is negociated, vhost-net makes the


negotiated

> advised MTU available to virtio-net through a vhost_net_get_mtu()
> call.
> 
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Aaron Conole <aconole@redhat.com>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---
>  hw/net/vhost_net.c      | 11 +++++++++++
>  include/net/vhost_net.h |  2 ++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
> index f2d49ad..21057d6 100644
> --- a/hw/net/vhost_net.c
> +++ b/hw/net/vhost_net.c
> @@ -74,6 +74,7 @@ static const int user_feature_bits[] = {
>      VIRTIO_NET_F_HOST_ECN,
>      VIRTIO_NET_F_HOST_UFO,
>      VIRTIO_NET_F_MRG_RXBUF,
> +    VIRTIO_NET_F_MTU,
>  
>      /* This bit implies RARP isn't sent by QEMU out of band */
>      VIRTIO_NET_F_GUEST_ANNOUNCE,
> @@ -435,6 +436,11 @@ int vhost_set_vring_enable(NetClientState *nc, int enable)
>      return 0;
>  }
>  
> +uint64_t vhost_net_get_mtu(struct vhost_net *net)
> +{
> +    return net->dev.mtu;
> +}
> +
>  #else
>  uint64_t vhost_net_get_max_queues(VHostNetState *net)
>  {
> @@ -501,4 +507,9 @@ int vhost_set_vring_enable(NetClientState *nc, int enable)
>  {
>      return 0;
>  }
> +
> +uint64_t vhost_net_get_mtu(struct vhost_net *net)
> +{
> +    return 0;
> +}
>  #endif
> diff --git a/include/net/vhost_net.h b/include/net/vhost_net.h
> index 5a08eff..37de17b 100644
> --- a/include/net/vhost_net.h
> +++ b/include/net/vhost_net.h
> @@ -35,4 +35,6 @@ int vhost_set_vring_enable(NetClientState * nc, int enable);
>  
>  uint64_t vhost_net_get_acked_features(VHostNetState *net);
>  
> +uint64_t vhost_net_get_mtu(struct vhost_net *net);
> +
>  #endif
> -- 
> 2.7.4

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[John Fastabend]

On 16-11-17 02:34 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 17, 2016 at 10:58:04PM +0100, Maxime Coquelin wrote:
>> This series implements Virtio spec update from Aaron Conole which
>> defines a way for the host to expose its max MTU to the guest.
>>
>> Changes since RFC v1:
>> ---------------------
>>  - Rebased on top of v2.8.0-rc0 (2.7.90)
>>  - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
>>  - Add host_mtu property to be able to disable the feature from QEMU
> 
> John, I believe you wanted to test these patches.

Great thanks. I have some time tomorrow to test these. I'll let folks
know how it goes.

> 
>> Maxime Coquelin (3):
>>   vhost-user: Add new protocol feature MTU
>>   vhost-net: Add new MTU feature support
>>   virtio-net: Add MTU feature support
>>
>>  hw/net/vhost_net.c             | 11 +++++++++++
>>  hw/net/virtio-net.c            | 14 ++++++++++++++
>>  hw/virtio/vhost-user.c         | 11 +++++++++++
>>  include/hw/virtio/vhost.h      |  1 +
>>  include/hw/virtio/virtio-net.h |  1 +
>>  include/net/vhost_net.h        |  2 ++
>>  6 files changed, 40 insertions(+)
>>
>> -- 
>> 2.7.4

Re: [Qemu-devel] [RFC v2 1/3] vhost-user: Add new protocol feature MTU

[Aaron Conole]

Maxime Coquelin <maxime.coquelin@redhat.com> writes:

> This patch adds VHOST_USER_PROTOCOL_F_MTU protocol feature.
>
> If supported, QEMU sends VHOST_USER_GET_MTU request to the client,
> and expects a u64 reply containing the MTU advised for the guest.
>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Aaron Conole <aconole@redhat.com>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---
>  hw/virtio/vhost-user.c    | 11 +++++++++++
>  include/hw/virtio/vhost.h |  1 +
>  2 files changed, 12 insertions(+)
>
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index 7ee92b3..eaf007d 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -32,6 +32,7 @@ enum VhostUserProtocolFeature {
>      VHOST_USER_PROTOCOL_F_LOG_SHMFD = 1,
>      VHOST_USER_PROTOCOL_F_RARP = 2,
>      VHOST_USER_PROTOCOL_F_REPLY_ACK = 3,
> +    VHOST_USER_PROTOCOL_F_MTU = 4,
>  
>      VHOST_USER_PROTOCOL_F_MAX
>  };
> @@ -59,6 +60,7 @@ typedef enum VhostUserRequest {
>      VHOST_USER_GET_QUEUE_NUM = 17,
>      VHOST_USER_SET_VRING_ENABLE = 18,
>      VHOST_USER_SEND_RARP = 19,
> +    VHOST_USER_GET_MTU = 20,
>      VHOST_USER_MAX
>  } VhostUserRequest;
>  
> @@ -186,6 +188,7 @@ static bool vhost_user_one_time_request(VhostUserRequest request)
>      case VHOST_USER_RESET_OWNER:
>      case VHOST_USER_SET_MEM_TABLE:
>      case VHOST_USER_GET_QUEUE_NUM:
> +    case VHOST_USER_GET_MTU:
>          return true;
>      default:
>          return false;
> @@ -602,6 +605,14 @@ static int vhost_user_init(struct vhost_dev *dev, void *opaque)
>                  return err;
>              }
>          }
> +
> +        /* query the MTU we support if backend supports MTU feature */
> +        if (dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_MTU)) {
> +            err = vhost_user_get_u64(dev, VHOST_USER_GET_MTU, &dev->mtu);
> +            if (err < 0) {
> +                return err;
> +            }
> +        }
>      }
>  
>      if (dev->migration_blocker == NULL &&
> diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
> index 1fe5aad..c674a05 100644
> --- a/include/hw/virtio/vhost.h
> +++ b/include/hw/virtio/vhost.h
> @@ -51,6 +51,7 @@ struct vhost_dev {
>      uint64_t backend_features;
>      uint64_t protocol_features;
>      uint64_t max_queues;
> +    uint64_t mtu;

Just a question why the MTU is stored as a u64?  would uint16_t make
more sense - then we can be sure we never have an excessively large mtu
value.

What do you think?

>      bool started;
>      bool log_enabled;
>      uint64_t log_size;

Re: [Qemu-devel] [RFC v2 2/3] vhost-net: Add new MTU feature support

[Aaron Conole]

Maxime Coquelin <maxime.coquelin@redhat.com> writes:

> If VHOST_USER_F_MTU feature is negociated, vhost-net makes the
> advised MTU available to virtio-net through a vhost_net_get_mtu()

s/advised/maximum/

> call.
>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Aaron Conole <aconole@redhat.com>
> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> ---
>  hw/net/vhost_net.c      | 11 +++++++++++
>  include/net/vhost_net.h |  2 ++
>  2 files changed, 13 insertions(+)
>
> diff --git a/hw/net/vhost_net.c b/hw/net/vhost_net.c
> index f2d49ad..21057d6 100644
> --- a/hw/net/vhost_net.c
> +++ b/hw/net/vhost_net.c
> @@ -74,6 +74,7 @@ static const int user_feature_bits[] = {
>      VIRTIO_NET_F_HOST_ECN,
>      VIRTIO_NET_F_HOST_UFO,
>      VIRTIO_NET_F_MRG_RXBUF,
> +    VIRTIO_NET_F_MTU,
>  
>      /* This bit implies RARP isn't sent by QEMU out of band */
>      VIRTIO_NET_F_GUEST_ANNOUNCE,
> @@ -435,6 +436,11 @@ int vhost_set_vring_enable(NetClientState *nc, int enable)
>      return 0;
>  }
>  
> +uint64_t vhost_net_get_mtu(struct vhost_net *net)
> +{
> +    return net->dev.mtu;
> +}
> +
>  #else
>  uint64_t vhost_net_get_max_queues(VHostNetState *net)
>  {
> @@ -501,4 +507,9 @@ int vhost_set_vring_enable(NetClientState *nc, int enable)
>  {
>      return 0;
>  }
> +
> +uint64_t vhost_net_get_mtu(struct vhost_net *net)
> +{
> +    return 0;
> +}
>  #endif
> diff --git a/include/net/vhost_net.h b/include/net/vhost_net.h
> index 5a08eff..37de17b 100644
> --- a/include/net/vhost_net.h
> +++ b/include/net/vhost_net.h
> @@ -35,4 +35,6 @@ int vhost_set_vring_enable(NetClientState * nc, int enable);
>  
>  uint64_t vhost_net_get_acked_features(VHostNetState *net);
>  
> +uint64_t vhost_net_get_mtu(struct vhost_net *net);
> +
>  #endif

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Aaron Conole]

Maxime Coquelin <maxime.coquelin@redhat.com> writes:

> This series implements Virtio spec update from Aaron Conole which
> defines a way for the host to expose its max MTU to the guest.
>
> Changes since RFC v1:
> ---------------------
>  - Rebased on top of v2.8.0-rc0 (2.7.90)
>  - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
>  - Add host_mtu property to be able to disable the feature from QEMU
>
> Maxime Coquelin (3):
>   vhost-user: Add new protocol feature MTU
>   vhost-net: Add new MTU feature support
>   virtio-net: Add MTU feature support
>
>  hw/net/vhost_net.c             | 11 +++++++++++
>  hw/net/virtio-net.c            | 14 ++++++++++++++
>  hw/virtio/vhost-user.c         | 11 +++++++++++
>  include/hw/virtio/vhost.h      |  1 +
>  include/hw/virtio/virtio-net.h |  1 +
>  include/net/vhost_net.h        |  2 ++
>  6 files changed, 40 insertions(+)

I ran this with a VM, but it seems the offered maximum MTU was of value
0 - is this expected with this version?  How can I change the offered
value?  Sorry, I'm not as familiar with QEMU/libvirt side of the world.

-Aaron

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Maxime Coquelin]

On 11/18/2016 07:15 PM, Aaron Conole wrote:
> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>
>> This series implements Virtio spec update from Aaron Conole which
>> defines a way for the host to expose its max MTU to the guest.
>>
>> Changes since RFC v1:
>> ---------------------
>>  - Rebased on top of v2.8.0-rc0 (2.7.90)
>>  - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
>>  - Add host_mtu property to be able to disable the feature from QEMU
>>
>> Maxime Coquelin (3):
>>   vhost-user: Add new protocol feature MTU
>>   vhost-net: Add new MTU feature support
>>   virtio-net: Add MTU feature support
>>
>>  hw/net/vhost_net.c             | 11 +++++++++++
>>  hw/net/virtio-net.c            | 14 ++++++++++++++
>>  hw/virtio/vhost-user.c         | 11 +++++++++++
>>  include/hw/virtio/vhost.h      |  1 +
>>  include/hw/virtio/virtio-net.h |  1 +
>>  include/net/vhost_net.h        |  2 ++
>>  6 files changed, 40 insertions(+)
>
> I ran this with a VM, but it seems the offered maximum MTU was of value
> 0 - is this expected with this version?  How can I change the offered
> value?  Sorry, I'm not as familiar with QEMU/libvirt side of the world.

They way I implemented it, the MTU value is to be provided by
vhost-user process (e.g. OVS/DPDK). I added a Vhost protocol
feature for this. The sequence is:
1. Qemu send VHOST_USER_GET_PROTOCOL_FEATURES request
2. DPDK replies with providing supported features
3. If DPDK supports VHOST_USER_PROTOCOL_F_MTU, Qemu send
    VHOST_USER_GET_MTU resuest
4. DPDK replies with MTU value

Does that make sense?

Another possibility would be that we could directly pass the MTU value
to Qemu. It may be easier to implement, and to handle migration.
Problem is that if we do this, this is not the vSwitch that decides the
MTU to set.

Regards,
Maxime

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Aaron Conole]

Maxime Coquelin <maxime.coquelin@redhat.com> writes:

> On 11/18/2016 07:15 PM, Aaron Conole wrote:
>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>>
>>> This series implements Virtio spec update from Aaron Conole which
>>> defines a way for the host to expose its max MTU to the guest.
>>>
>>> Changes since RFC v1:
>>> ---------------------
>>>  - Rebased on top of v2.8.0-rc0 (2.7.90)
>>>  - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
>>>  - Add host_mtu property to be able to disable the feature from QEMU
>>>
>>> Maxime Coquelin (3):
>>>   vhost-user: Add new protocol feature MTU
>>>   vhost-net: Add new MTU feature support
>>>   virtio-net: Add MTU feature support
>>>
>>>  hw/net/vhost_net.c             | 11 +++++++++++
>>>  hw/net/virtio-net.c            | 14 ++++++++++++++
>>>  hw/virtio/vhost-user.c         | 11 +++++++++++
>>>  include/hw/virtio/vhost.h      |  1 +
>>>  include/hw/virtio/virtio-net.h |  1 +
>>>  include/net/vhost_net.h        |  2 ++
>>>  6 files changed, 40 insertions(+)
>>
>> I ran this with a VM, but it seems the offered maximum MTU was of value
>> 0 - is this expected with this version?  How can I change the offered
>> value?  Sorry, I'm not as familiar with QEMU/libvirt side of the world.
>
> They way I implemented it, the MTU value is to be provided by
> vhost-user process (e.g. OVS/DPDK). I added a Vhost protocol
> feature for this. The sequence is:
> 1. Qemu send VHOST_USER_GET_PROTOCOL_FEATURES request
> 2. DPDK replies with providing supported features
> 3. If DPDK supports VHOST_USER_PROTOCOL_F_MTU, Qemu send
>    VHOST_USER_GET_MTU resuest
> 4. DPDK replies with MTU value
>
> Does that make sense?

In the case of a vhost-user backed port, yes (so for instance, if I use
ovs+dpdk vhost-user in client or server mode).  However, what about the
non-dpdk case, where I still use a virtio-net driver in kernel and want
to have it backed with, say, a tap device in the host attached to
virbr0 (or some other bridge).  It should still pull the mtu from that
device and offer it, I think.

> Another possibility would be that we could directly pass the MTU value
> to Qemu. It may be easier to implement, and to handle migration.
> Problem is that if we do this, this is not the vSwitch that decides the
> MTU to set.

Might be better to determined the mtu by looking at what actually
provides the back-end for the networking.

> Regards,
> Maxime

Re: [Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support

[Maxime Coquelin]

On 11/17/2016 11:38 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 17, 2016 at 10:58:07PM +0100, Maxime Coquelin wrote:
>> If negotiated, virtio-net gets the advised MTU from vhost-net,
>> and provides it to the guest through a new virtio_net_config
>> entry.
>>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Cc: Aaron Conole <aconole@redhat.com
>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>> ---
>>  hw/net/virtio-net.c            | 14 ++++++++++++++
>>  include/hw/virtio/virtio-net.h |  1 +
>>  2 files changed, 15 insertions(+)
>>
>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>> index 5009533..36843fe 100644
>> --- a/hw/net/virtio-net.c
>> +++ b/hw/net/virtio-net.c
>> @@ -55,6 +55,8 @@ static VirtIOFeature feature_sizes[] = {
>>       .end = endof(struct virtio_net_config, status)},
>>      {.flags = 1 << VIRTIO_NET_F_MQ,
>>       .end = endof(struct virtio_net_config, max_virtqueue_pairs)},
>> +    {.flags = 1 << VIRTIO_NET_F_MTU,
>> +     .end = endof(struct virtio_net_config, mtu)},
>>      {}
>>  };
>>
>> @@ -81,6 +83,7 @@ static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config)
>>
>>      virtio_stw_p(vdev, &netcfg.status, n->status);
>>      virtio_stw_p(vdev, &netcfg.max_virtqueue_pairs, n->max_queues);
>> +    virtio_stw_p(vdev, &netcfg.mtu, n->mtu);
>>      memcpy(netcfg.mac, n->mac, ETH_ALEN);
>>      memcpy(config, &netcfg, n->config_size);
>>  }
>> @@ -636,6 +639,14 @@ static void virtio_net_set_features(VirtIODevice *vdev, uint64_t features)
>>      } else {
>>          memset(n->vlans, 0xff, MAX_VLAN >> 3);
>>      }
>> +
>> +    if (virtio_has_feature(features, VIRTIO_NET_F_MTU)) {
>> +        NetClientState *nc = qemu_get_queue(n->nic);
>> +
>> +        if (get_vhost_net(nc->peer)) {
>> +            n->mtu = vhost_net_get_mtu(get_vhost_net(nc->peer));
>
>
> This means migration breaks silently if you move from a bigger to
> smaller mtu. We don't necessarily have to make it work,
> but it should be detected and reported.

Good point.
I planned to investigate migration case while looking deeper at
vhost-user versionning topic.

Moving from bigger to smaller MTU is indeed a problem, because the
backend may not support received buffer size.

Isn't also a problem when moving from smaller to bigger MTU, as it no
more respect the contract old host negotiated with the guest?

>
>> +        }
>> +    }
>>  }
>>
>>  static int virtio_net_handle_rx_mode(VirtIONet *n, uint8_t cmd,
>
> What about non-vhost traffic? You need to ensure guest does
> not get bigger packets.
Ok, do you confirm checking in virtio_net_receive() that buffer size is
smaller or equal than MTU is enough?

>
>
>> @@ -1695,6 +1706,7 @@ static void virtio_net_set_config_size(VirtIONet *n, uint64_t host_features)
>>  {
>>      int i, config_size = 0;
>>      virtio_add_feature(&host_features, VIRTIO_NET_F_MAC);
>> +    virtio_add_feature(&host_features, VIRTIO_NET_F_MTU);
>>      for (i = 0; feature_sizes[i].flags != 0; i++) {
>>          if (host_features & feature_sizes[i].flags) {
>>              config_size = MAX(feature_sizes[i].end, config_size);
>> @@ -1922,6 +1934,8 @@ static Property virtio_net_properties[] = {
>>      DEFINE_PROP_STRING("tx", VirtIONet, net_conf.tx),
>>      DEFINE_PROP_UINT16("rx_queue_size", VirtIONet, net_conf.rx_queue_size,
>>                         VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE),
>> +    DEFINE_PROP_BIT("host_mtu", VirtIONet, host_features,
>> +                    VIRTIO_NET_F_MTU, true),
>>      DEFINE_PROP_END_OF_LIST(),
>>  };
>>
>
> Cross version migration support is missing here.
Sorry, I'm not sure to understand what you expect here.
Could you please provide more details?

>
>> diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h
>> index 0ced975..b6394c8 100644
>> --- a/include/hw/virtio/virtio-net.h
>> +++ b/include/hw/virtio/virtio-net.h
>> @@ -96,6 +96,7 @@ typedef struct VirtIONet {
>>      QEMUTimer *announce_timer;
>>      int announce_counter;
>>      bool needs_vnet_hdr_swap;
>> +    uint16_t mtu;
>>  } VirtIONet;
>>
>>  void virtio_net_set_netclient_name(VirtIONet *n, const char *name,
>> --
>> 2.7.4

Thanks,
Maxime

Re: [Qemu-devel] [RFC v2 1/3] vhost-user: Add new protocol feature MTU

[Maxime Coquelin]

On 11/18/2016 03:26 PM, Aaron Conole wrote:
> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>
>> This patch adds VHOST_USER_PROTOCOL_F_MTU protocol feature.
>>
>> If supported, QEMU sends VHOST_USER_GET_MTU request to the client,
>> and expects a u64 reply containing the MTU advised for the guest.
>>
>> Cc: Michael S. Tsirkin <mst@redhat.com>
>> Cc: Aaron Conole <aconole@redhat.com>
>> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>> ---
>>  hw/virtio/vhost-user.c    | 11 +++++++++++
>>  include/hw/virtio/vhost.h |  1 +
>>  2 files changed, 12 insertions(+)
>>
>> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
>> index 7ee92b3..eaf007d 100644
>> --- a/hw/virtio/vhost-user.c
>> +++ b/hw/virtio/vhost-user.c
>> @@ -32,6 +32,7 @@ enum VhostUserProtocolFeature {
>>      VHOST_USER_PROTOCOL_F_LOG_SHMFD = 1,
>>      VHOST_USER_PROTOCOL_F_RARP = 2,
>>      VHOST_USER_PROTOCOL_F_REPLY_ACK = 3,
>> +    VHOST_USER_PROTOCOL_F_MTU = 4,
>>
>>      VHOST_USER_PROTOCOL_F_MAX
>>  };
>> @@ -59,6 +60,7 @@ typedef enum VhostUserRequest {
>>      VHOST_USER_GET_QUEUE_NUM = 17,
>>      VHOST_USER_SET_VRING_ENABLE = 18,
>>      VHOST_USER_SEND_RARP = 19,
>> +    VHOST_USER_GET_MTU = 20,
>>      VHOST_USER_MAX
>>  } VhostUserRequest;
>>
>> @@ -186,6 +188,7 @@ static bool vhost_user_one_time_request(VhostUserRequest request)
>>      case VHOST_USER_RESET_OWNER:
>>      case VHOST_USER_SET_MEM_TABLE:
>>      case VHOST_USER_GET_QUEUE_NUM:
>> +    case VHOST_USER_GET_MTU:
>>          return true;
>>      default:
>>          return false;
>> @@ -602,6 +605,14 @@ static int vhost_user_init(struct vhost_dev *dev, void *opaque)
>>                  return err;
>>              }
>>          }
>> +
>> +        /* query the MTU we support if backend supports MTU feature */
>> +        if (dev->protocol_features & (1ULL << VHOST_USER_PROTOCOL_F_MTU)) {
>> +            err = vhost_user_get_u64(dev, VHOST_USER_GET_MTU, &dev->mtu);
>> +            if (err < 0) {
>> +                return err;
>> +            }
>> +        }
>>      }
>>
>>      if (dev->migration_blocker == NULL &&
>> diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
>> index 1fe5aad..c674a05 100644
>> --- a/include/hw/virtio/vhost.h
>> +++ b/include/hw/virtio/vhost.h
>> @@ -51,6 +51,7 @@ struct vhost_dev {
>>      uint64_t backend_features;
>>      uint64_t protocol_features;
>>      uint64_t max_queues;
>> +    uint64_t mtu;
>
> Just a question why the MTU is stored as a u64?  would uint16_t make
> more sense - then we can be sure we never have an excessively large mtu
> value.
>
> What do you think?
This is because the vihst-user message payload is 64 bits.
Note that the max number of queues is also 64 bits.

However, a check could be added to ensure the value is coherent.

Maxime

Re: [Qemu-devel] [RFC v2 2/3] vhost-net: Add new MTU feature support

[Maxime Coquelin]

On 11/17/2016 11:39 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 17, 2016 at 10:58:06PM +0100, Maxime Coquelin wrote:
>> > If VHOST_USER_F_MTU feature is negociated, vhost-net makes the
>
> negotiated

Excuse my "frenglish"... It will be fixed in next revision.

Thanks,
Maxime

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Michael S. Tsirkin]

On Fri, Nov 18, 2016 at 02:21:54PM -0500, Aaron Conole wrote:
> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
> 
> > On 11/18/2016 07:15 PM, Aaron Conole wrote:
> >> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
> >>
> >>> This series implements Virtio spec update from Aaron Conole which
> >>> defines a way for the host to expose its max MTU to the guest.
> >>>
> >>> Changes since RFC v1:
> >>> ---------------------
> >>>  - Rebased on top of v2.8.0-rc0 (2.7.90)
> >>>  - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
> >>>  - Add host_mtu property to be able to disable the feature from QEMU
> >>>
> >>> Maxime Coquelin (3):
> >>>   vhost-user: Add new protocol feature MTU
> >>>   vhost-net: Add new MTU feature support
> >>>   virtio-net: Add MTU feature support
> >>>
> >>>  hw/net/vhost_net.c             | 11 +++++++++++
> >>>  hw/net/virtio-net.c            | 14 ++++++++++++++
> >>>  hw/virtio/vhost-user.c         | 11 +++++++++++
> >>>  include/hw/virtio/vhost.h      |  1 +
> >>>  include/hw/virtio/virtio-net.h |  1 +
> >>>  include/net/vhost_net.h        |  2 ++
> >>>  6 files changed, 40 insertions(+)
> >>
> >> I ran this with a VM, but it seems the offered maximum MTU was of value
> >> 0 - is this expected with this version?  How can I change the offered
> >> value?  Sorry, I'm not as familiar with QEMU/libvirt side of the world.
> >
> > They way I implemented it, the MTU value is to be provided by
> > vhost-user process (e.g. OVS/DPDK). I added a Vhost protocol
> > feature for this. The sequence is:
> > 1. Qemu send VHOST_USER_GET_PROTOCOL_FEATURES request
> > 2. DPDK replies with providing supported features
> > 3. If DPDK supports VHOST_USER_PROTOCOL_F_MTU, Qemu send
> >    VHOST_USER_GET_MTU resuest
> > 4. DPDK replies with MTU value
> >
> > Does that make sense?
> 
> In the case of a vhost-user backed port, yes (so for instance, if I use
> ovs+dpdk vhost-user in client or server mode).  However, what about the
> non-dpdk case, where I still use a virtio-net driver in kernel and want
> to have it backed with, say, a tap device in the host attached to
> virbr0 (or some other bridge).  It should still pull the mtu from that
> device and offer it, I think.
> 
> > Another possibility would be that we could directly pass the MTU value
> > to Qemu. It may be easier to implement, and to handle migration.
> > Problem is that if we do this, this is not the vSwitch that decides the
> > MTU to set.
> 
> Might be better to determined the mtu by looking at what actually
> provides the back-end for the networking.
> 
> > Regards,
> > Maxime

Right. So in case it's not vhost-user, I would say it has to
be specified from QEMU command line.
It's probably easier to do the same everywhere, and just send
the MTU from qemu to backend.


-- 
MST

Re: [Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support

[Michael S. Tsirkin]

On Mon, Nov 21, 2016 at 01:34:32PM +0100, Maxime Coquelin wrote:
> 
> 
> On 11/17/2016 11:38 PM, Michael S. Tsirkin wrote:
> > On Thu, Nov 17, 2016 at 10:58:07PM +0100, Maxime Coquelin wrote:
> > > If negotiated, virtio-net gets the advised MTU from vhost-net,
> > > and provides it to the guest through a new virtio_net_config
> > > entry.
> > > 
> > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > Cc: Aaron Conole <aconole@redhat.com
> > > Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
> > > ---
> > >  hw/net/virtio-net.c            | 14 ++++++++++++++
> > >  include/hw/virtio/virtio-net.h |  1 +
> > >  2 files changed, 15 insertions(+)
> > > 
> > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > > index 5009533..36843fe 100644
> > > --- a/hw/net/virtio-net.c
> > > +++ b/hw/net/virtio-net.c
> > > @@ -55,6 +55,8 @@ static VirtIOFeature feature_sizes[] = {
> > >       .end = endof(struct virtio_net_config, status)},
> > >      {.flags = 1 << VIRTIO_NET_F_MQ,
> > >       .end = endof(struct virtio_net_config, max_virtqueue_pairs)},
> > > +    {.flags = 1 << VIRTIO_NET_F_MTU,
> > > +     .end = endof(struct virtio_net_config, mtu)},
> > >      {}
> > >  };
> > > 
> > > @@ -81,6 +83,7 @@ static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config)
> > > 
> > >      virtio_stw_p(vdev, &netcfg.status, n->status);
> > >      virtio_stw_p(vdev, &netcfg.max_virtqueue_pairs, n->max_queues);
> > > +    virtio_stw_p(vdev, &netcfg.mtu, n->mtu);
> > >      memcpy(netcfg.mac, n->mac, ETH_ALEN);
> > >      memcpy(config, &netcfg, n->config_size);
> > >  }
> > > @@ -636,6 +639,14 @@ static void virtio_net_set_features(VirtIODevice *vdev, uint64_t features)
> > >      } else {
> > >          memset(n->vlans, 0xff, MAX_VLAN >> 3);
> > >      }
> > > +
> > > +    if (virtio_has_feature(features, VIRTIO_NET_F_MTU)) {
> > > +        NetClientState *nc = qemu_get_queue(n->nic);
> > > +
> > > +        if (get_vhost_net(nc->peer)) {
> > > +            n->mtu = vhost_net_get_mtu(get_vhost_net(nc->peer));
> > 
> > 
> > This means migration breaks silently if you move from a bigger to
> > smaller mtu. We don't necessarily have to make it work,
> > but it should be detected and reported.
> 
> Good point.
> I planned to investigate migration case while looking deeper at
> vhost-user versionning topic.
> 
> Moving from bigger to smaller MTU is indeed a problem, because the
> backend may not support received buffer size.
> 
> Isn't also a problem when moving from smaller to bigger MTU, as it no
> more respect the contract old host negotiated with the guest?

Depends on what assumptions backends makes, but generally yes.

> > 
> > > +        }
> > > +    }
> > >  }
> > > 
> > >  static int virtio_net_handle_rx_mode(VirtIONet *n, uint8_t cmd,
> > 
> > What about non-vhost traffic? You need to ensure guest does
> > not get bigger packets.
> Ok, do you confirm checking in virtio_net_receive() that buffer size is
> smaller or equal than MTU is enough?
> 
> > 
> > 
> > > @@ -1695,6 +1706,7 @@ static void virtio_net_set_config_size(VirtIONet *n, uint64_t host_features)
> > >  {
> > >      int i, config_size = 0;
> > >      virtio_add_feature(&host_features, VIRTIO_NET_F_MAC);
> > > +    virtio_add_feature(&host_features, VIRTIO_NET_F_MTU);
> > >      for (i = 0; feature_sizes[i].flags != 0; i++) {
> > >          if (host_features & feature_sizes[i].flags) {
> > >              config_size = MAX(feature_sizes[i].end, config_size);
> > > @@ -1922,6 +1934,8 @@ static Property virtio_net_properties[] = {
> > >      DEFINE_PROP_STRING("tx", VirtIONet, net_conf.tx),
> > >      DEFINE_PROP_UINT16("rx_queue_size", VirtIONet, net_conf.rx_queue_size,
> > >                         VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE),
> > > +    DEFINE_PROP_BIT("host_mtu", VirtIONet, host_features,
> > > +                    VIRTIO_NET_F_MTU, true),
> > >      DEFINE_PROP_END_OF_LIST(),
> > >  };
> > > 
> > 
> > Cross version migration support is missing here.
> Sorry, I'm not sure to understand what you expect here.
> Could you please provide more details?

feature bits must be consistent for a given machine type.
So you can't add them unconditionally for old machine
types, they must look the same as they looked when
we put that machine type out.

> > 
> > > diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h
> > > index 0ced975..b6394c8 100644
> > > --- a/include/hw/virtio/virtio-net.h
> > > +++ b/include/hw/virtio/virtio-net.h
> > > @@ -96,6 +96,7 @@ typedef struct VirtIONet {
> > >      QEMUTimer *announce_timer;
> > >      int announce_counter;
> > >      bool needs_vnet_hdr_swap;
> > > +    uint16_t mtu;
> > >  } VirtIONet;
> > > 
> > >  void virtio_net_set_netclient_name(VirtIONet *n, const char *name,
> > > --
> > > 2.7.4
> 
> Thanks,
> Maxime

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Jason Wang]

On 2016年11月22日 00:23, Michael S. Tsirkin wrote:
> On Fri, Nov 18, 2016 at 02:21:54PM -0500, Aaron Conole wrote:
>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>>
>>> On 11/18/2016 07:15 PM, Aaron Conole wrote:
>>>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>>>>
>>>>> This series implements Virtio spec update from Aaron Conole which
>>>>> defines a way for the host to expose its max MTU to the guest.
>>>>>
>>>>> Changes since RFC v1:
>>>>> ---------------------
>>>>>   - Rebased on top of v2.8.0-rc0 (2.7.90)
>>>>>   - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
>>>>>   - Add host_mtu property to be able to disable the feature from QEMU
>>>>>
>>>>> Maxime Coquelin (3):
>>>>>    vhost-user: Add new protocol feature MTU
>>>>>    vhost-net: Add new MTU feature support
>>>>>    virtio-net: Add MTU feature support
>>>>>
>>>>>   hw/net/vhost_net.c             | 11 +++++++++++
>>>>>   hw/net/virtio-net.c            | 14 ++++++++++++++
>>>>>   hw/virtio/vhost-user.c         | 11 +++++++++++
>>>>>   include/hw/virtio/vhost.h      |  1 +
>>>>>   include/hw/virtio/virtio-net.h |  1 +
>>>>>   include/net/vhost_net.h        |  2 ++
>>>>>   6 files changed, 40 insertions(+)
>>>> I ran this with a VM, but it seems the offered maximum MTU was of value
>>>> 0 - is this expected with this version?  How can I change the offered
>>>> value?  Sorry, I'm not as familiar with QEMU/libvirt side of the world.
>>> They way I implemented it, the MTU value is to be provided by
>>> vhost-user process (e.g. OVS/DPDK). I added a Vhost protocol
>>> feature for this. The sequence is:
>>> 1. Qemu send VHOST_USER_GET_PROTOCOL_FEATURES request
>>> 2. DPDK replies with providing supported features
>>> 3. If DPDK supports VHOST_USER_PROTOCOL_F_MTU, Qemu send
>>>     VHOST_USER_GET_MTU resuest
>>> 4. DPDK replies with MTU value
>>>
>>> Does that make sense?
>> In the case of a vhost-user backed port, yes (so for instance, if I use
>> ovs+dpdk vhost-user in client or server mode).  However, what about the
>> non-dpdk case, where I still use a virtio-net driver in kernel and want
>> to have it backed with, say, a tap device in the host attached to
>> virbr0 (or some other bridge).  It should still pull the mtu from that
>> device and offer it, I think.
>>
>>> Another possibility would be that we could directly pass the MTU value
>>> to Qemu. It may be easier to implement, and to handle migration.
>>> Problem is that if we do this, this is not the vSwitch that decides the
>>> MTU to set.
>> Might be better to determined the mtu by looking at what actually
>> provides the back-end for the networking.
>>
>>> Regards,
>>> Maxime
> Right. So in case it's not vhost-user, I would say it has to
> be specified from QEMU command line.
> It's probably easier to do the same everywhere, and just send
> the MTU from qemu to backend.

Or vice-versa? E.g qemu need to be notified if the MTU of tap or macvtap 
were changed?

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Maxime Coquelin]

On 11/22/2016 05:07 AM, Jason Wang wrote:
>
>
> On 2016年11月22日 00:23, Michael S. Tsirkin wrote:
>> On Fri, Nov 18, 2016 at 02:21:54PM -0500, Aaron Conole wrote:
>>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>>>
>>>> On 11/18/2016 07:15 PM, Aaron Conole wrote:
>>>>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>>>>>
>>>>>> This series implements Virtio spec update from Aaron Conole which
>>>>>> defines a way for the host to expose its max MTU to the guest.
>>>>>>
>>>>>> Changes since RFC v1:
>>>>>> ---------------------
>>>>>>   - Rebased on top of v2.8.0-rc0 (2.7.90)
>>>>>>   - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
>>>>>>   - Add host_mtu property to be able to disable the feature from QEMU
>>>>>>
>>>>>> Maxime Coquelin (3):
>>>>>>    vhost-user: Add new protocol feature MTU
>>>>>>    vhost-net: Add new MTU feature support
>>>>>>    virtio-net: Add MTU feature support
>>>>>>
>>>>>>   hw/net/vhost_net.c             | 11 +++++++++++
>>>>>>   hw/net/virtio-net.c            | 14 ++++++++++++++
>>>>>>   hw/virtio/vhost-user.c         | 11 +++++++++++
>>>>>>   include/hw/virtio/vhost.h      |  1 +
>>>>>>   include/hw/virtio/virtio-net.h |  1 +
>>>>>>   include/net/vhost_net.h        |  2 ++
>>>>>>   6 files changed, 40 insertions(+)
>>>>> I ran this with a VM, but it seems the offered maximum MTU was of
>>>>> value
>>>>> 0 - is this expected with this version?  How can I change the offered
>>>>> value?  Sorry, I'm not as familiar with QEMU/libvirt side of the
>>>>> world.
>>>> They way I implemented it, the MTU value is to be provided by
>>>> vhost-user process (e.g. OVS/DPDK). I added a Vhost protocol
>>>> feature for this. The sequence is:
>>>> 1. Qemu send VHOST_USER_GET_PROTOCOL_FEATURES request
>>>> 2. DPDK replies with providing supported features
>>>> 3. If DPDK supports VHOST_USER_PROTOCOL_F_MTU, Qemu send
>>>>     VHOST_USER_GET_MTU resuest
>>>> 4. DPDK replies with MTU value
>>>>
>>>> Does that make sense?
>>> In the case of a vhost-user backed port, yes (so for instance, if I use
>>> ovs+dpdk vhost-user in client or server mode).  However, what about the
>>> non-dpdk case, where I still use a virtio-net driver in kernel and want
>>> to have it backed with, say, a tap device in the host attached to
>>> virbr0 (or some other bridge).  It should still pull the mtu from that
>>> device and offer it, I think.
>>>
>>>> Another possibility would be that we could directly pass the MTU value
>>>> to Qemu. It may be easier to implement, and to handle migration.
>>>> Problem is that if we do this, this is not the vSwitch that decides the
>>>> MTU to set.
>>> Might be better to determined the mtu by looking at what actually
>>> provides the back-end for the networking.
>>>
>>>> Regards,
>>>> Maxime
>> Right. So in case it's not vhost-user, I would say it has to
>> be specified from QEMU command line.
>> It's probably easier to do the same everywhere, and just send
>> the MTU from qemu to backend.
>
> Or vice-versa? E.g qemu need to be notified if the MTU of tap or macvtap
> were changed?

The spec says the MTU must not be modified by the device once it has
been set.

I think it would require a device reset if MTU came to change.

Re: [Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support

[Maxime Coquelin]

On 11/21/2016 05:48 PM, Michael S. Tsirkin wrote:
>>>> > > > @@ -1695,6 +1706,7 @@ static void virtio_net_set_config_size(VirtIONet *n, uint64_t host_features)
>>>> > > >  {
>>>> > > >      int i, config_size = 0;
>>>> > > >      virtio_add_feature(&host_features, VIRTIO_NET_F_MAC);
>>>> > > > +    virtio_add_feature(&host_features, VIRTIO_NET_F_MTU);
>>>> > > >      for (i = 0; feature_sizes[i].flags != 0; i++) {
>>>> > > >          if (host_features & feature_sizes[i].flags) {
>>>> > > >              config_size = MAX(feature_sizes[i].end, config_size);
>>>> > > > @@ -1922,6 +1934,8 @@ static Property virtio_net_properties[] = {
>>>> > > >      DEFINE_PROP_STRING("tx", VirtIONet, net_conf.tx),
>>>> > > >      DEFINE_PROP_UINT16("rx_queue_size", VirtIONet, net_conf.rx_queue_size,
>>>> > > >                         VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE),
>>>> > > > +    DEFINE_PROP_BIT("host_mtu", VirtIONet, host_features,
>>>> > > > +                    VIRTIO_NET_F_MTU, true),
>>>> > > >      DEFINE_PROP_END_OF_LIST(),
>>>> > > >  };
>>>> > > >
>>> > >
>>> > > Cross version migration support is missing here.
>> > Sorry, I'm not sure to understand what you expect here.
>> > Could you please provide more details?
> feature bits must be consistent for a given machine type.
> So you can't add them unconditionally for old machine
> types, they must look the same as they looked when
> we put that machine type out.

Ok, thanks for clarifying.
IIUC, idea is to let it enabled by default, and add entries in
HW_COMPAT_2_x macros to disable it in all previous versions?

Thanks,
Maxime

Re: [Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support

[Michael S. Tsirkin]

On Tue, Nov 22, 2016 at 01:11:50PM +0100, Maxime Coquelin wrote:
> 
> 
> On 11/21/2016 05:48 PM, Michael S. Tsirkin wrote:
> > > > > > > > @@ -1695,6 +1706,7 @@ static void virtio_net_set_config_size(VirtIONet *n, uint64_t host_features)
> > > > > > > >  {
> > > > > > > >      int i, config_size = 0;
> > > > > > > >      virtio_add_feature(&host_features, VIRTIO_NET_F_MAC);
> > > > > > > > +    virtio_add_feature(&host_features, VIRTIO_NET_F_MTU);
> > > > > > > >      for (i = 0; feature_sizes[i].flags != 0; i++) {
> > > > > > > >          if (host_features & feature_sizes[i].flags) {
> > > > > > > >              config_size = MAX(feature_sizes[i].end, config_size);
> > > > > > > > @@ -1922,6 +1934,8 @@ static Property virtio_net_properties[] = {
> > > > > > > >      DEFINE_PROP_STRING("tx", VirtIONet, net_conf.tx),
> > > > > > > >      DEFINE_PROP_UINT16("rx_queue_size", VirtIONet, net_conf.rx_queue_size,
> > > > > > > >                         VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE),
> > > > > > > > +    DEFINE_PROP_BIT("host_mtu", VirtIONet, host_features,
> > > > > > > > +                    VIRTIO_NET_F_MTU, true),
> > > > > > > >      DEFINE_PROP_END_OF_LIST(),
> > > > > > > >  };
> > > > > > > >
> > > > > >
> > > > > > Cross version migration support is missing here.
> > > > Sorry, I'm not sure to understand what you expect here.
> > > > Could you please provide more details?
> > feature bits must be consistent for a given machine type.
> > So you can't add them unconditionally for old machine
> > types, they must look the same as they looked when
> > we put that machine type out.
> 
> Ok, thanks for clarifying.
> IIUC, idea is to let it enabled by default, and add entries in
> HW_COMPAT_2_x macros to disable it in all previous versions?
> 
> Thanks,
> Maxime

I suspect you should keep it disabled by default,
set it when user specifies the mtu.

-- 
MST

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Aaron Conole]

Maxime Coquelin <maxime.coquelin@redhat.com> writes:

> On 11/22/2016 05:07 AM, Jason Wang wrote:
>>
>>
>> On 2016年11月22日 00:23, Michael S. Tsirkin wrote:
>>> On Fri, Nov 18, 2016 at 02:21:54PM -0500, Aaron Conole wrote:
>>>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>>>>
>>>>> On 11/18/2016 07:15 PM, Aaron Conole wrote:
>>>>>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>>>>>>
>>>>>>> This series implements Virtio spec update from Aaron Conole which
>>>>>>> defines a way for the host to expose its max MTU to the guest.
>>>>>>>
>>>>>>> Changes since RFC v1:
>>>>>>> ---------------------
>>>>>>>   - Rebased on top of v2.8.0-rc0 (2.7.90)
>>>>>>>   - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
>>>>>>>   - Add host_mtu property to be able to disable the feature from QEMU
>>>>>>>
>>>>>>> Maxime Coquelin (3):
>>>>>>>    vhost-user: Add new protocol feature MTU
>>>>>>>    vhost-net: Add new MTU feature support
>>>>>>>    virtio-net: Add MTU feature support
>>>>>>>
>>>>>>>   hw/net/vhost_net.c             | 11 +++++++++++
>>>>>>>   hw/net/virtio-net.c            | 14 ++++++++++++++
>>>>>>>   hw/virtio/vhost-user.c         | 11 +++++++++++
>>>>>>>   include/hw/virtio/vhost.h      |  1 +
>>>>>>>   include/hw/virtio/virtio-net.h |  1 +
>>>>>>>   include/net/vhost_net.h        |  2 ++
>>>>>>>   6 files changed, 40 insertions(+)
>>>>>> I ran this with a VM, but it seems the offered maximum MTU was of
>>>>>> value
>>>>>> 0 - is this expected with this version?  How can I change the offered
>>>>>> value?  Sorry, I'm not as familiar with QEMU/libvirt side of the
>>>>>> world.
>>>>> They way I implemented it, the MTU value is to be provided by
>>>>> vhost-user process (e.g. OVS/DPDK). I added a Vhost protocol
>>>>> feature for this. The sequence is:
>>>>> 1. Qemu send VHOST_USER_GET_PROTOCOL_FEATURES request
>>>>> 2. DPDK replies with providing supported features
>>>>> 3. If DPDK supports VHOST_USER_PROTOCOL_F_MTU, Qemu send
>>>>>     VHOST_USER_GET_MTU resuest
>>>>> 4. DPDK replies with MTU value
>>>>>
>>>>> Does that make sense?
>>>> In the case of a vhost-user backed port, yes (so for instance, if I use
>>>> ovs+dpdk vhost-user in client or server mode).  However, what about the
>>>> non-dpdk case, where I still use a virtio-net driver in kernel and want
>>>> to have it backed with, say, a tap device in the host attached to
>>>> virbr0 (or some other bridge).  It should still pull the mtu from that
>>>> device and offer it, I think.
>>>>
>>>>> Another possibility would be that we could directly pass the MTU value
>>>>> to Qemu. It may be easier to implement, and to handle migration.
>>>>> Problem is that if we do this, this is not the vSwitch that decides the
>>>>> MTU to set.
>>>> Might be better to determined the mtu by looking at what actually
>>>> provides the back-end for the networking.
>>>>
>>>>> Regards,
>>>>> Maxime
>>> Right. So in case it's not vhost-user, I would say it has to
>>> be specified from QEMU command line.
>>> It's probably easier to do the same everywhere, and just send
>>> the MTU from qemu to backend.
>>
>> Or vice-versa? E.g qemu need to be notified if the MTU of tap or macvtap
>> were changed?

I think qemu should just query the MTU at start time and then
provide that as the value to the VM.  Why specify with command line
option?  Seems to me like an easy way to get out of sync.

> The spec says the MTU must not be modified by the device once it has
> been set.

+1 - we don't have an exchange or negotiation mechanism for this.  That
would require additional bits and communication, and it seems like it
isn't worth it.

> I think it would require a device reset if MTU came to change.

It's just too much work for not enough gain.  Guest can change MTU all
it wants.  Host should just know what it will limit to the guest from
the beginning.  Maybe I'm too simple, though.

-Aaron

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Michael S. Tsirkin]

On Tue, Nov 22, 2016 at 09:32:01AM -0500, Aaron Conole wrote:
> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
> 
> > On 11/22/2016 05:07 AM, Jason Wang wrote:
> >>
> >>
> >> On 2016年11月22日 00:23, Michael S. Tsirkin wrote:
> >>> On Fri, Nov 18, 2016 at 02:21:54PM -0500, Aaron Conole wrote:
> >>>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
> >>>>
> >>>>> On 11/18/2016 07:15 PM, Aaron Conole wrote:
> >>>>>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
> >>>>>>
> >>>>>>> This series implements Virtio spec update from Aaron Conole which
> >>>>>>> defines a way for the host to expose its max MTU to the guest.
> >>>>>>>
> >>>>>>> Changes since RFC v1:
> >>>>>>> ---------------------
> >>>>>>>   - Rebased on top of v2.8.0-rc0 (2.7.90)
> >>>>>>>   - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
> >>>>>>>   - Add host_mtu property to be able to disable the feature from QEMU
> >>>>>>>
> >>>>>>> Maxime Coquelin (3):
> >>>>>>>    vhost-user: Add new protocol feature MTU
> >>>>>>>    vhost-net: Add new MTU feature support
> >>>>>>>    virtio-net: Add MTU feature support
> >>>>>>>
> >>>>>>>   hw/net/vhost_net.c             | 11 +++++++++++
> >>>>>>>   hw/net/virtio-net.c            | 14 ++++++++++++++
> >>>>>>>   hw/virtio/vhost-user.c         | 11 +++++++++++
> >>>>>>>   include/hw/virtio/vhost.h      |  1 +
> >>>>>>>   include/hw/virtio/virtio-net.h |  1 +
> >>>>>>>   include/net/vhost_net.h        |  2 ++
> >>>>>>>   6 files changed, 40 insertions(+)
> >>>>>> I ran this with a VM, but it seems the offered maximum MTU was of
> >>>>>> value
> >>>>>> 0 - is this expected with this version?  How can I change the offered
> >>>>>> value?  Sorry, I'm not as familiar with QEMU/libvirt side of the
> >>>>>> world.
> >>>>> They way I implemented it, the MTU value is to be provided by
> >>>>> vhost-user process (e.g. OVS/DPDK). I added a Vhost protocol
> >>>>> feature for this. The sequence is:
> >>>>> 1. Qemu send VHOST_USER_GET_PROTOCOL_FEATURES request
> >>>>> 2. DPDK replies with providing supported features
> >>>>> 3. If DPDK supports VHOST_USER_PROTOCOL_F_MTU, Qemu send
> >>>>>     VHOST_USER_GET_MTU resuest
> >>>>> 4. DPDK replies with MTU value
> >>>>>
> >>>>> Does that make sense?
> >>>> In the case of a vhost-user backed port, yes (so for instance, if I use
> >>>> ovs+dpdk vhost-user in client or server mode).  However, what about the
> >>>> non-dpdk case, where I still use a virtio-net driver in kernel and want
> >>>> to have it backed with, say, a tap device in the host attached to
> >>>> virbr0 (or some other bridge).  It should still pull the mtu from that
> >>>> device and offer it, I think.
> >>>>
> >>>>> Another possibility would be that we could directly pass the MTU value
> >>>>> to Qemu. It may be easier to implement, and to handle migration.
> >>>>> Problem is that if we do this, this is not the vSwitch that decides the
> >>>>> MTU to set.
> >>>> Might be better to determined the mtu by looking at what actually
> >>>> provides the back-end for the networking.
> >>>>
> >>>>> Regards,
> >>>>> Maxime
> >>> Right. So in case it's not vhost-user, I would say it has to
> >>> be specified from QEMU command line.
> >>> It's probably easier to do the same everywhere, and just send
> >>> the MTU from qemu to backend.
> >>
> >> Or vice-versa? E.g qemu need to be notified if the MTU of tap or macvtap
> >> were changed?
> 
> I think qemu should just query the MTU at start time and then
> provide that as the value to the VM.  Why specify with command line
> option?

Passing it on command line is an easy way to make sure we can migrate
the VM correctly.  Also, if we get it from the backend, this requires
backend changes.  In particular, tun/macvtap will need new ioctls.  So
generally that's more work.

>  Seems to me like an easy way to get out of sync.

If we send it to the backend, that has a chance to check
mtu and disconnect on error.

> > The spec says the MTU must not be modified by the device once it has
> > been set.
> 
> +1 - we don't have an exchange or negotiation mechanism for this.  That
> would require additional bits and communication, and it seems like it
> isn't worth it.
> 
> > I think it would require a device reset if MTU came to change.
> 
> It's just too much work for not enough gain.  Guest can change MTU all
> it wants.  Host should just know what it will limit to the guest from
> the beginning.  Maybe I'm too simple, though.
> 
> -Aaron

I agree it's a good start.

-- 
MST

Re: [Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support

[Maxime Coquelin]

On 11/22/2016 03:18 PM, Michael S. Tsirkin wrote:
> On Tue, Nov 22, 2016 at 01:11:50PM +0100, Maxime Coquelin wrote:
>>
>>
>> On 11/21/2016 05:48 PM, Michael S. Tsirkin wrote:
>>>>>>>>> @@ -1695,6 +1706,7 @@ static void virtio_net_set_config_size(VirtIONet *n, uint64_t host_features)
>>>>>>>>>  {
>>>>>>>>>      int i, config_size = 0;
>>>>>>>>>      virtio_add_feature(&host_features, VIRTIO_NET_F_MAC);
>>>>>>>>> +    virtio_add_feature(&host_features, VIRTIO_NET_F_MTU);
>>>>>>>>>      for (i = 0; feature_sizes[i].flags != 0; i++) {
>>>>>>>>>          if (host_features & feature_sizes[i].flags) {
>>>>>>>>>              config_size = MAX(feature_sizes[i].end, config_size);
>>>>>>>>> @@ -1922,6 +1934,8 @@ static Property virtio_net_properties[] = {
>>>>>>>>>      DEFINE_PROP_STRING("tx", VirtIONet, net_conf.tx),
>>>>>>>>>      DEFINE_PROP_UINT16("rx_queue_size", VirtIONet, net_conf.rx_queue_size,
>>>>>>>>>                         VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE),
>>>>>>>>> +    DEFINE_PROP_BIT("host_mtu", VirtIONet, host_features,
>>>>>>>>> +                    VIRTIO_NET_F_MTU, true),
>>>>>>>>>      DEFINE_PROP_END_OF_LIST(),
>>>>>>>>>  };
>>>>>>>>>
>>>>>>>
>>>>>>> Cross version migration support is missing here.
>>>>> Sorry, I'm not sure to understand what you expect here.
>>>>> Could you please provide more details?
>>> feature bits must be consistent for a given machine type.
>>> So you can't add them unconditionally for old machine
>>> types, they must look the same as they looked when
>>> we put that machine type out.
>>
>> Ok, thanks for clarifying.
>> IIUC, idea is to let it enabled by default, and add entries in
>> HW_COMPAT_2_x macros to disable it in all previous versions?
>>
>> Thanks,
>> Maxime
>
> I suspect you should keep it disabled by default,
> set it when user specifies the mtu.

Yes, that make sense.

Thanks,
Maxime

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Maxime Coquelin]

On 11/22/2016 03:41 PM, Michael S. Tsirkin wrote:
> On Tue, Nov 22, 2016 at 09:32:01AM -0500, Aaron Conole wrote:
>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>>
>>> On 11/22/2016 05:07 AM, Jason Wang wrote:
>>>>
>>>>
>>>> On 2016年11月22日 00:23, Michael S. Tsirkin wrote:
>>>>> On Fri, Nov 18, 2016 at 02:21:54PM -0500, Aaron Conole wrote:
>>>>>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>>>>>>
>>>>>>> On 11/18/2016 07:15 PM, Aaron Conole wrote:
>>>>>>>> Maxime Coquelin <maxime.coquelin@redhat.com> writes:
>>>>>>>>
>>>>>>>>> This series implements Virtio spec update from Aaron Conole which
>>>>>>>>> defines a way for the host to expose its max MTU to the guest.
>>>>>>>>>
>>>>>>>>> Changes since RFC v1:
>>>>>>>>> ---------------------
>>>>>>>>>   - Rebased on top of v2.8.0-rc0 (2.7.90)
>>>>>>>>>   - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
>>>>>>>>>   - Add host_mtu property to be able to disable the feature from QEMU
>>>>>>>>>
>>>>>>>>> Maxime Coquelin (3):
>>>>>>>>>    vhost-user: Add new protocol feature MTU
>>>>>>>>>    vhost-net: Add new MTU feature support
>>>>>>>>>    virtio-net: Add MTU feature support
>>>>>>>>>
>>>>>>>>>   hw/net/vhost_net.c             | 11 +++++++++++
>>>>>>>>>   hw/net/virtio-net.c            | 14 ++++++++++++++
>>>>>>>>>   hw/virtio/vhost-user.c         | 11 +++++++++++
>>>>>>>>>   include/hw/virtio/vhost.h      |  1 +
>>>>>>>>>   include/hw/virtio/virtio-net.h |  1 +
>>>>>>>>>   include/net/vhost_net.h        |  2 ++
>>>>>>>>>   6 files changed, 40 insertions(+)
>>>>>>>> I ran this with a VM, but it seems the offered maximum MTU was of
>>>>>>>> value
>>>>>>>> 0 - is this expected with this version?  How can I change the offered
>>>>>>>> value?  Sorry, I'm not as familiar with QEMU/libvirt side of the
>>>>>>>> world.
>>>>>>> They way I implemented it, the MTU value is to be provided by
>>>>>>> vhost-user process (e.g. OVS/DPDK). I added a Vhost protocol
>>>>>>> feature for this. The sequence is:
>>>>>>> 1. Qemu send VHOST_USER_GET_PROTOCOL_FEATURES request
>>>>>>> 2. DPDK replies with providing supported features
>>>>>>> 3. If DPDK supports VHOST_USER_PROTOCOL_F_MTU, Qemu send
>>>>>>>     VHOST_USER_GET_MTU resuest
>>>>>>> 4. DPDK replies with MTU value
>>>>>>>
>>>>>>> Does that make sense?
>>>>>> In the case of a vhost-user backed port, yes (so for instance, if I use
>>>>>> ovs+dpdk vhost-user in client or server mode).  However, what about the
>>>>>> non-dpdk case, where I still use a virtio-net driver in kernel and want
>>>>>> to have it backed with, say, a tap device in the host attached to
>>>>>> virbr0 (or some other bridge).  It should still pull the mtu from that
>>>>>> device and offer it, I think.
>>>>>>
>>>>>>> Another possibility would be that we could directly pass the MTU value
>>>>>>> to Qemu. It may be easier to implement, and to handle migration.
>>>>>>> Problem is that if we do this, this is not the vSwitch that decides the
>>>>>>> MTU to set.
>>>>>> Might be better to determined the mtu by looking at what actually
>>>>>> provides the back-end for the networking.
>>>>>>
>>>>>>> Regards,
>>>>>>> Maxime
>>>>> Right. So in case it's not vhost-user, I would say it has to
>>>>> be specified from QEMU command line.
>>>>> It's probably easier to do the same everywhere, and just send
>>>>> the MTU from qemu to backend.
>>>>
>>>> Or vice-versa? E.g qemu need to be notified if the MTU of tap or macvtap
>>>> were changed?
>>
>> I think qemu should just query the MTU at start time and then
>> provide that as the value to the VM.  Why specify with command line
>> option?
>
> Passing it on command line is an easy way to make sure we can migrate
> the VM correctly.  Also, if we get it from the backend, this requires
> backend changes.  In particular, tun/macvtap will need new ioctls.  So
> generally that's more work.

I agree this is easier for migration.

>>  Seems to me like an easy way to get out of sync.
>
> If we send it to the backend, that has a chance to check
> mtu and disconnect on error.

For vhost-user backend, we can send it the MTU value with a
vhost-user protocol feature.

For tun/macvtap, how do you do without adding a new ioctl ?

>
>>> The spec says the MTU must not be modified by the device once it has
>>> been set.
>>
>> +1 - we don't have an exchange or negotiation mechanism for this.  That
>> would require additional bits and communication, and it seems like it
>> isn't worth it.
>>
>>> I think it would require a device reset if MTU came to change.
>>
>> It's just too much work for not enough gain.  Guest can change MTU all
>> it wants.  Host should just know what it will limit to the guest from
>> the beginning.  Maybe I'm too simple, though.
>>
>> -Aaron
>
> I agree it's a good start.

Thanks,
Maxime

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Michael S. Tsirkin]

On Tue, Nov 22, 2016 at 06:56:43PM +0100, Maxime Coquelin wrote:
> 
> 
> On 11/22/2016 03:41 PM, Michael S. Tsirkin wrote:
> > On Tue, Nov 22, 2016 at 09:32:01AM -0500, Aaron Conole wrote:
> > > Maxime Coquelin <maxime.coquelin@redhat.com> writes:
> > > 
> > > > On 11/22/2016 05:07 AM, Jason Wang wrote:
> > > > > 
> > > > > 
> > > > > On 2016年11月22日 00:23, Michael S. Tsirkin wrote:
> > > > > > On Fri, Nov 18, 2016 at 02:21:54PM -0500, Aaron Conole wrote:
> > > > > > > Maxime Coquelin <maxime.coquelin@redhat.com> writes:
> > > > > > > 
> > > > > > > > On 11/18/2016 07:15 PM, Aaron Conole wrote:
> > > > > > > > > Maxime Coquelin <maxime.coquelin@redhat.com> writes:
> > > > > > > > > 
> > > > > > > > > > This series implements Virtio spec update from Aaron Conole which
> > > > > > > > > > defines a way for the host to expose its max MTU to the guest.
> > > > > > > > > > 
> > > > > > > > > > Changes since RFC v1:
> > > > > > > > > > ---------------------
> > > > > > > > > >   - Rebased on top of v2.8.0-rc0 (2.7.90)
> > > > > > > > > >   - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
> > > > > > > > > >   - Add host_mtu property to be able to disable the feature from QEMU
> > > > > > > > > > 
> > > > > > > > > > Maxime Coquelin (3):
> > > > > > > > > >    vhost-user: Add new protocol feature MTU
> > > > > > > > > >    vhost-net: Add new MTU feature support
> > > > > > > > > >    virtio-net: Add MTU feature support
> > > > > > > > > > 
> > > > > > > > > >   hw/net/vhost_net.c             | 11 +++++++++++
> > > > > > > > > >   hw/net/virtio-net.c            | 14 ++++++++++++++
> > > > > > > > > >   hw/virtio/vhost-user.c         | 11 +++++++++++
> > > > > > > > > >   include/hw/virtio/vhost.h      |  1 +
> > > > > > > > > >   include/hw/virtio/virtio-net.h |  1 +
> > > > > > > > > >   include/net/vhost_net.h        |  2 ++
> > > > > > > > > >   6 files changed, 40 insertions(+)
> > > > > > > > > I ran this with a VM, but it seems the offered maximum MTU was of
> > > > > > > > > value
> > > > > > > > > 0 - is this expected with this version?  How can I change the offered
> > > > > > > > > value?  Sorry, I'm not as familiar with QEMU/libvirt side of the
> > > > > > > > > world.
> > > > > > > > They way I implemented it, the MTU value is to be provided by
> > > > > > > > vhost-user process (e.g. OVS/DPDK). I added a Vhost protocol
> > > > > > > > feature for this. The sequence is:
> > > > > > > > 1. Qemu send VHOST_USER_GET_PROTOCOL_FEATURES request
> > > > > > > > 2. DPDK replies with providing supported features
> > > > > > > > 3. If DPDK supports VHOST_USER_PROTOCOL_F_MTU, Qemu send
> > > > > > > >     VHOST_USER_GET_MTU resuest
> > > > > > > > 4. DPDK replies with MTU value
> > > > > > > > 
> > > > > > > > Does that make sense?
> > > > > > > In the case of a vhost-user backed port, yes (so for instance, if I use
> > > > > > > ovs+dpdk vhost-user in client or server mode).  However, what about the
> > > > > > > non-dpdk case, where I still use a virtio-net driver in kernel and want
> > > > > > > to have it backed with, say, a tap device in the host attached to
> > > > > > > virbr0 (or some other bridge).  It should still pull the mtu from that
> > > > > > > device and offer it, I think.
> > > > > > > 
> > > > > > > > Another possibility would be that we could directly pass the MTU value
> > > > > > > > to Qemu. It may be easier to implement, and to handle migration.
> > > > > > > > Problem is that if we do this, this is not the vSwitch that decides the
> > > > > > > > MTU to set.
> > > > > > > Might be better to determined the mtu by looking at what actually
> > > > > > > provides the back-end for the networking.
> > > > > > > 
> > > > > > > > Regards,
> > > > > > > > Maxime
> > > > > > Right. So in case it's not vhost-user, I would say it has to
> > > > > > be specified from QEMU command line.
> > > > > > It's probably easier to do the same everywhere, and just send
> > > > > > the MTU from qemu to backend.
> > > > > 
> > > > > Or vice-versa? E.g qemu need to be notified if the MTU of tap or macvtap
> > > > > were changed?
> > > 
> > > I think qemu should just query the MTU at start time and then
> > > provide that as the value to the VM.  Why specify with command line
> > > option?
> > 
> > Passing it on command line is an easy way to make sure we can migrate
> > the VM correctly.  Also, if we get it from the backend, this requires
> > backend changes.  In particular, tun/macvtap will need new ioctls.  So
> > generally that's more work.
> 
> I agree this is easier for migration.
> 
> > >  Seems to me like an easy way to get out of sync.
> > 
> > If we send it to the backend, that has a chance to check
> > mtu and disconnect on error.
> 
> For vhost-user backend, we can send it the MTU value with a
> vhost-user protocol feature.
> 
> For tun/macvtap, how do you do without adding a new ioctl ?

Have management configure same mtu on the backend and in qemu.


> > 
> > > > The spec says the MTU must not be modified by the device once it has
> > > > been set.
> > > 
> > > +1 - we don't have an exchange or negotiation mechanism for this.  That
> > > would require additional bits and communication, and it seems like it
> > > isn't worth it.
> > > 
> > > > I think it would require a device reset if MTU came to change.
> > > 
> > > It's just too much work for not enough gain.  Guest can change MTU all
> > > it wants.  Host should just know what it will limit to the guest from
> > > the beginning.  Maybe I'm too simple, though.
> > > 
> > > -Aaron
> > 
> > I agree it's a good start.
> 
> Thanks,
> Maxime

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Jason Wang]

On 2016年11月23日 04:38, Michael S. Tsirkin wrote:
> On Tue, Nov 22, 2016 at 06:56:43PM +0100, Maxime Coquelin wrote:
>> >
>> >
>> >On 11/22/2016 03:41 PM, Michael S. Tsirkin wrote:
>>> > >On Tue, Nov 22, 2016 at 09:32:01AM -0500, Aaron Conole wrote:
>>>> > > >Maxime Coquelin<maxime.coquelin@redhat.com>  writes:
>>>> > > >
>>>>> > > > >On 11/22/2016 05:07 AM, Jason Wang wrote:
>>>>>> > > > > >
>>>>>> > > > > >
>>>>>> > > > > >On 2016年11月22日 00:23, Michael S. Tsirkin wrote:
>>>>>>> > > > > > >On Fri, Nov 18, 2016 at 02:21:54PM -0500, Aaron Conole wrote:
>>>>>>>> > > > > > > >Maxime Coquelin<maxime.coquelin@redhat.com>  writes:
>>>>>>>> > > > > > > >
>>>>>>>>> > > > > > > > >On 11/18/2016 07:15 PM, Aaron Conole wrote:
>>>>>>>>>> > > > > > > > > >Maxime Coquelin<maxime.coquelin@redhat.com>  writes:
>>>>>>>>>> > > > > > > > > >
>>>>>>>>>>> > > > > > > > > > >This series implements Virtio spec update from Aaron Conole which
>>>>>>>>>>> > > > > > > > > > >defines a way for the host to expose its max MTU to the guest.
>>>>>>>>>>> > > > > > > > > > >
>>>>>>>>>>> > > > > > > > > > >Changes since RFC v1:
>>>>>>>>>>> > > > > > > > > > >---------------------
>>>>>>>>>>> > > > > > > > > > >   - Rebased on top of v2.8.0-rc0 (2.7.90)
>>>>>>>>>>> > > > > > > > > > >   - Write MTU unconditionnaly in netcfg to avoid memory leak (Paolo)
>>>>>>>>>>> > > > > > > > > > >   - Add host_mtu property to be able to disable the feature from QEMU
>>>>>>>>>>> > > > > > > > > > >
>>>>>>>>>>> > > > > > > > > > >Maxime Coquelin (3):
>>>>>>>>>>> > > > > > > > > > >    vhost-user: Add new protocol feature MTU
>>>>>>>>>>> > > > > > > > > > >    vhost-net: Add new MTU feature support
>>>>>>>>>>> > > > > > > > > > >    virtio-net: Add MTU feature support
>>>>>>>>>>> > > > > > > > > > >
>>>>>>>>>>> > > > > > > > > > >   hw/net/vhost_net.c             | 11 +++++++++++
>>>>>>>>>>> > > > > > > > > > >   hw/net/virtio-net.c            | 14 ++++++++++++++
>>>>>>>>>>> > > > > > > > > > >   hw/virtio/vhost-user.c         | 11 +++++++++++
>>>>>>>>>>> > > > > > > > > > >   include/hw/virtio/vhost.h      |  1 +
>>>>>>>>>>> > > > > > > > > > >   include/hw/virtio/virtio-net.h |  1 +
>>>>>>>>>>> > > > > > > > > > >   include/net/vhost_net.h        |  2 ++
>>>>>>>>>>> > > > > > > > > > >   6 files changed, 40 insertions(+)
>>>>>>>>>> > > > > > > > > >I ran this with a VM, but it seems the offered maximum MTU was of
>>>>>>>>>> > > > > > > > > >value
>>>>>>>>>> > > > > > > > > >0 - is this expected with this version?  How can I change the offered
>>>>>>>>>> > > > > > > > > >value?  Sorry, I'm not as familiar with QEMU/libvirt side of the
>>>>>>>>>> > > > > > > > > >world.
>>>>>>>>> > > > > > > > >They way I implemented it, the MTU value is to be provided by
>>>>>>>>> > > > > > > > >vhost-user process (e.g. OVS/DPDK). I added a Vhost protocol
>>>>>>>>> > > > > > > > >feature for this. The sequence is:
>>>>>>>>> > > > > > > > >1. Qemu send VHOST_USER_GET_PROTOCOL_FEATURES request
>>>>>>>>> > > > > > > > >2. DPDK replies with providing supported features
>>>>>>>>> > > > > > > > >3. If DPDK supports VHOST_USER_PROTOCOL_F_MTU, Qemu send
>>>>>>>>> > > > > > > > >     VHOST_USER_GET_MTU resuest
>>>>>>>>> > > > > > > > >4. DPDK replies with MTU value
>>>>>>>>> > > > > > > > >
>>>>>>>>> > > > > > > > >Does that make sense?
>>>>>>>> > > > > > > >In the case of a vhost-user backed port, yes (so for instance, if I use
>>>>>>>> > > > > > > >ovs+dpdk vhost-user in client or server mode).  However, what about the
>>>>>>>> > > > > > > >non-dpdk case, where I still use a virtio-net driver in kernel and want
>>>>>>>> > > > > > > >to have it backed with, say, a tap device in the host attached to
>>>>>>>> > > > > > > >virbr0 (or some other bridge).  It should still pull the mtu from that
>>>>>>>> > > > > > > >device and offer it, I think.
>>>>>>>> > > > > > > >
>>>>>>>>> > > > > > > > >Another possibility would be that we could directly pass the MTU value
>>>>>>>>> > > > > > > > >to Qemu. It may be easier to implement, and to handle migration.
>>>>>>>>> > > > > > > > >Problem is that if we do this, this is not the vSwitch that decides the
>>>>>>>>> > > > > > > > >MTU to set.
>>>>>>>> > > > > > > >Might be better to determined the mtu by looking at what actually
>>>>>>>> > > > > > > >provides the back-end for the networking.
>>>>>>>> > > > > > > >
>>>>>>>>> > > > > > > > >Regards,
>>>>>>>>> > > > > > > > >Maxime
>>>>>>> > > > > > >Right. So in case it's not vhost-user, I would say it has to
>>>>>>> > > > > > >be specified from QEMU command line.
>>>>>>> > > > > > >It's probably easier to do the same everywhere, and just send
>>>>>>> > > > > > >the MTU from qemu to backend.
>>>>>> > > > > >
>>>>>> > > > > >Or vice-versa? E.g qemu need to be notified if the MTU of tap or macvtap
>>>>>> > > > > >were changed?
>>>> > > >
>>>> > > >I think qemu should just query the MTU at start time and then
>>>> > > >provide that as the value to the VM.  Why specify with command line
>>>> > > >option?
>>> > >
>>> > >Passing it on command line is an easy way to make sure we can migrate
>>> > >the VM correctly.  Also, if we get it from the backend, this requires
>>> > >backend changes.  In particular, tun/macvtap will need new ioctls.  So
>>> > >generally that's more work.
>> >
>> >I agree this is easier for migration.
>> >
>>>> > > >  Seems to me like an easy way to get out of sync.
>>> > >
>>> > >If we send it to the backend, that has a chance to check
>>> > >mtu and disconnect on error.
>> >
>> >For vhost-user backend, we can send it the MTU value with a
>> >vhost-user protocol feature.
>> >
>> >For tun/macvtap, how do you do without adding a new ioctl ?
> Have management configure same mtu on the backend and in qemu.
>
>

Then why not do same for vhost-user (instead of using two different 
methods)?

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Michael S. Tsirkin]

On Wed, Nov 23, 2016 at 11:42:52AM +0800, Jason Wang wrote:
> > > > > > > >  Seems to me like an easy way to get out of sync.
> > > > > >
> > > > > >If we send it to the backend, that has a chance to check
> > > > > >mtu and disconnect on error.
> > > >
> > > >For vhost-user backend, we can send it the MTU value with a
> > > >vhost-user protocol feature.
> > > >
> > > >For tun/macvtap, how do you do without adding a new ioctl ?
> > Have management configure same mtu on the backend and in qemu.
> > 
> > 
> 
> Then why not do same for vhost-user (instead of using two different
> methods)?

That's what I'm saying. If backend supports that, we can also
check the mtu in some way to make sure it matches.

-- 
MST

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Aaron Conole]

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

> On Wed, Nov 23, 2016 at 11:42:52AM +0800, Jason Wang wrote:
>> > > > > > > >  Seems to me like an easy way to get out of sync.
>> > > > > >
>> > > > > >If we send it to the backend, that has a chance to check
>> > > > > >mtu and disconnect on error.
>> > > >
>> > > >For vhost-user backend, we can send it the MTU value with a
>> > > >vhost-user protocol feature.
>> > > >
>> > > >For tun/macvtap, how do you do without adding a new ioctl ?
>> > Have management configure same mtu on the backend and in qemu.
>> > 
>> > 
>> 
>> Then why not do same for vhost-user (instead of using two different
>> methods)?
>
> That's what I'm saying. If backend supports that, we can also
> check the mtu in some way to make sure it matches.

I'm not sure why we need a new ioctl (or an ioctl at all - netlink
supports all of this)?

ex:

08:58:34 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ sudo ip tuntap add dev tap0 mode tap
[sudo] password for aconole: 
08:58:40 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
...
7: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 46:e0:fc:83:54:1c brd ff:ff:ff:ff:ff:ff
08:58:51 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ sudo ip l set tap0 mtu 8000
08:58:54 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
...
7: tap0: <BROADCAST,MULTICAST> mtu 8000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 46:e0:fc:83:54:1c brd ff:ff:ff:ff:ff:ff

So, at least with iproute2, we can already read and write using the netlink
interface for tuntap devices.  I haven't played with macvtap, but I
think it's similar support - just do a netlink query, get the configured
MTU, and advertise it.  I might be missing something though - I'm a
simple guy with simple ideas.  Maybe there's a cross-platform issue or
something?

-Aaron

Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature

[Michael S. Tsirkin]

On Wed, Nov 23, 2016 at 09:02:53AM -0500, Aaron Conole wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Wed, Nov 23, 2016 at 11:42:52AM +0800, Jason Wang wrote:
> >> > > > > > > >  Seems to me like an easy way to get out of sync.
> >> > > > > >
> >> > > > > >If we send it to the backend, that has a chance to check
> >> > > > > >mtu and disconnect on error.
> >> > > >
> >> > > >For vhost-user backend, we can send it the MTU value with a
> >> > > >vhost-user protocol feature.
> >> > > >
> >> > > >For tun/macvtap, how do you do without adding a new ioctl ?
> >> > Have management configure same mtu on the backend and in qemu.
> >> > 
> >> > 
> >> 
> >> Then why not do same for vhost-user (instead of using two different
> >> methods)?
> >
> > That's what I'm saying. If backend supports that, we can also
> > check the mtu in some way to make sure it matches.
> 
> I'm not sure why we need a new ioctl (or an ioctl at all - netlink
> supports all of this)?
> 
> ex:
> 
> 08:58:34 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ sudo ip tuntap add dev tap0 mode tap
> [sudo] password for aconole: 
> 08:58:40 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ ip l
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> ...
> 7: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>     link/ether 46:e0:fc:83:54:1c brd ff:ff:ff:ff:ff:ff
> 08:58:51 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ sudo ip l set tap0 mtu 8000
> 08:58:54 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ ip l
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> ...
> 7: tap0: <BROADCAST,MULTICAST> mtu 8000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
>     link/ether 46:e0:fc:83:54:1c brd ff:ff:ff:ff:ff:ff
> 
> So, at least with iproute2, we can already read and write using the netlink
> interface for tuntap devices.  I haven't played with macvtap, but I
> think it's similar support - just do a netlink query, get the configured
> MTU, and advertise it.  I might be missing something though - I'm a
> simple guy with simple ideas.  Maybe there's a cross-platform issue or
> something?
> 
> -Aaron

qemu is generally not running with enough priveledges to
allow access to netlink.