From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8o38-0002sk-4H for qemu-devel@nongnu.org; Mon, 21 Nov 2016 07:50:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8o33-0000xR-5X for qemu-devel@nongnu.org; Mon, 21 Nov 2016 07:50:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42786) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c8o32-0000xA-SL for qemu-devel@nongnu.org; Mon, 21 Nov 2016 07:50:13 -0500 References: <1479419887-10515-1-git-send-email-maxime.coquelin@redhat.com> <1479419887-10515-2-git-send-email-maxime.coquelin@redhat.com> From: Maxime Coquelin Message-ID: <34d929be-2bd0-7c5e-2ca3-6f39d6613669@redhat.com> Date: Mon, 21 Nov 2016 13:50:07 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Aaron Conole Cc: mst@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, jasowang@redhat.com, yuanhan.liu@linux.intel.com On 11/18/2016 03:26 PM, Aaron Conole wrote: > 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? This is because the vihst-user message payload is 64 bits. Note that the max number of queues is also 64 bits. However, a check could be added to ensure the value is coherent. Maxime