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

[Maxime Coquelin]

On 11/30/2016 12:24 PM, Jason Wang wrote:
> On 2016年11月30日 18:10, Maxime Coquelin wrote:
> > This patch allows advising guest with host MTU's by setting
> > host_mtu parameter.
> >
> > If VIRTIO_NET_F_MTU has been successfully negotiated, MTU
> > value is passed to the backend.
> >
> > Cc: Michael S. Tsirkin <address@hidden>
> > Cc: Aaron Conole <address@hidden
> > Signed-off-by: Maxime Coquelin <address@hidden>
> > ---
> >   hw/net/virtio-net.c            | 13 +++++++++++++
> >   include/hw/virtio/virtio-net.h |  1 +
> >   2 files changed, 14 insertions(+)
> >
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 5009533..5225e9b 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->net_conf.mtu);
> >       memcpy(netcfg.mac, n->mac, ETH_ALEN);
> >       memcpy(config, &netcfg, n->config_size);
> >   }
> > @@ -152,6 +155,10 @@ static void virtio_net_vhost_status(VirtIONet *n,
> > uint8_t status)
> >               qemu_net_queue_purge(qnc->incoming_queue, qnc->peer);
> >           }
> >   +        if (virtio_has_feature(vdev->guest_features,
> > VIRTIO_NET_F_MTU)) {
> > +            vhost_net_set_mtu(get_vhost_net(nc->peer), n->net_conf.mtu);
> > +        }
>
> We'd better not ignore errors here and that's why we need management
> tool (who can make sure the mtu is set correctly before launching qemu).

Ok.
Currently, errors are reported if it failed to send the request
(protocol feature not present), maybe the request should require a
reply from the backend whether or not configured MTU is consistent
with what management tool set.

Make sense?

Thanks,
Maxime