From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: aconole@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org,
jasowang@redhat.com, yuanhan.liu@linux.intel.com
Subject: Re: [Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support
Date: Mon, 21 Nov 2016 13:34:32 +0100 [thread overview]
Message-ID: <3120fbd4-99eb-a9f2-a2b3-a5f686dbc7ee@redhat.com> (raw)
In-Reply-To: <20161118003558-mutt-send-email-mst@kernel.org>
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
next prev parent reply other threads:[~2016-11-21 12:34 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-17 21:58 [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature Maxime Coquelin
2016-11-17 21:58 ` [Qemu-devel] [RFC v2 1/3] vhost-user: Add new protocol feature MTU Maxime Coquelin
2016-11-18 14:26 ` Aaron Conole
2016-11-21 12:50 ` Maxime Coquelin
2016-11-17 21:58 ` [Qemu-devel] [RFC v2 2/3] vhost-net: Add new MTU feature support Maxime Coquelin
2016-11-17 22:39 ` Michael S. Tsirkin
2016-11-21 12:51 ` Maxime Coquelin
2016-11-18 18:13 ` Aaron Conole
2016-11-17 21:58 ` [Qemu-devel] [RFC v2 3/3] virtio-net: Add " Maxime Coquelin
2016-11-17 22:38 ` Michael S. Tsirkin
2016-11-21 12:34 ` Maxime Coquelin [this message]
2016-11-21 16:48 ` Michael S. Tsirkin
2016-11-22 12:11 ` Maxime Coquelin
2016-11-22 14:18 ` Michael S. Tsirkin
2016-11-22 15:33 ` Maxime Coquelin
2016-11-17 22:34 ` [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature Michael S. Tsirkin
2016-11-18 6:42 ` John Fastabend
2016-11-18 18:15 ` Aaron Conole
2016-11-18 18:52 ` Maxime Coquelin
2016-11-18 19:21 ` Aaron Conole
2016-11-21 16:23 ` Michael S. Tsirkin
2016-11-22 4:07 ` Jason Wang
2016-11-22 7:40 ` Maxime Coquelin
2016-11-22 14:32 ` Aaron Conole
2016-11-22 14:41 ` Michael S. Tsirkin
2016-11-22 17:56 ` Maxime Coquelin
2016-11-22 20:38 ` Michael S. Tsirkin
2016-11-23 3:42 ` Jason Wang
2016-11-23 4:26 ` Michael S. Tsirkin
2016-11-23 14:02 ` Aaron Conole
2016-11-23 17:42 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3120fbd4-99eb-a9f2-a2b3-a5f686dbc7ee@redhat.com \
--to=maxime.coquelin@redhat.com \
--cc=aconole@redhat.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).