[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support |
Date: |
Mon, 21 Nov 2016 18:48:02 +0200 |
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 <address@hidden>
> > > Cc: Aaron Conole <address@hidden
> > > Signed-off-by: Maxime Coquelin <address@hidden>
> > > ---
> > > 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
- [Qemu-devel] [RFC v2 1/3] vhost-user: Add new protocol feature MTU, (continued)
Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Michael S. Tsirkin, 2016/11/17
Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Aaron Conole, 2016/11/18