From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8no3-0006JY-LI for qemu-devel@nongnu.org; Mon, 21 Nov 2016 07:34:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8no0-0003fg-IR for qemu-devel@nongnu.org; Mon, 21 Nov 2016 07:34:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54758) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c8no0-0003fL-8R for qemu-devel@nongnu.org; Mon, 21 Nov 2016 07:34:40 -0500 References: <1479419887-10515-1-git-send-email-maxime.coquelin@redhat.com> <1479419887-10515-4-git-send-email-maxime.coquelin@redhat.com> <20161118003558-mutt-send-email-mst@kernel.org> From: Maxime Coquelin Message-ID: <3120fbd4-99eb-a9f2-a2b3-a5f686dbc7ee@redhat.com> Date: Mon, 21 Nov 2016 13:34:32 +0100 MIME-Version: 1.0 In-Reply-To: <20161118003558-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: aconole@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, jasowang@redhat.com, yuanhan.liu@linux.intel.com 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 >> Cc: Aaron Conole > Signed-off-by: Maxime Coquelin >> --- >> 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