From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7k7v-0000bg-VX for qemu-devel@nongnu.org; Fri, 18 Nov 2016 09:26:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7k7v-00015Y-0y for qemu-devel@nongnu.org; Fri, 18 Nov 2016 09:26:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60040) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c7k7u-00015G-Nw for qemu-devel@nongnu.org; Fri, 18 Nov 2016 09:26:50 -0500 From: Aaron Conole References: <1479419887-10515-1-git-send-email-maxime.coquelin@redhat.com> <1479419887-10515-2-git-send-email-maxime.coquelin@redhat.com> Date: Fri, 18 Nov 2016 09:26:47 -0500 In-Reply-To: <1479419887-10515-2-git-send-email-maxime.coquelin@redhat.com> (Maxime Coquelin's message of "Thu, 17 Nov 2016 22:58:05 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [RFC v2 1/3] vhost-user: Add new protocol feature MTU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Maxime Coquelin Cc: mst@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, jasowang@redhat.com, yuanhan.liu@linux.intel.com Maxime Coquelin 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 > Cc: Aaron Conole > Signed-off-by: Maxime Coquelin > --- > 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;