From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 7F801D1BB for ; Thu, 30 Mar 2017 13:34:15 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 62C2BC04BD5B; Thu, 30 Mar 2017 11:34:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 62C2BC04BD5B Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=maxime.coquelin@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 62C2BC04BD5B Received: from [10.36.112.26] (ovpn-112-26.ams2.redhat.com [10.36.112.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 56AE178C0C; Thu, 30 Mar 2017 11:34:12 +0000 (UTC) To: "Yao, Lei A" , "aconole@redhat.com" , "sodey@sonusnet.com" , "yuanhan.liu@linux.intel.com" , "Tan, Jianfeng" , "thomas.monjalon@6wind.com" , "dev@dpdk.org" References: <20170213142820.8964-1-maxime.coquelin@redhat.com> <20170312163406.17714-1-maxime.coquelin@redhat.com> <2DBBFF226F7CF64BAFCA79B681719D953A175FB5@shsmsx102.ccr.corp.intel.com> From: Maxime Coquelin Message-ID: Date: Thu, 30 Mar 2017 13:34:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2DBBFF226F7CF64BAFCA79B681719D953A175FB5@shsmsx102.ccr.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 30 Mar 2017 11:34:14 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v3 0/9] virtio/vhost: Add MTU feature support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 11:34:16 -0000 Hi Lei, On 03/28/2017 07:39 AM, Yao, Lei A wrote: > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Maxime Coquelin >> Sent: Monday, March 13, 2017 12:34 AM >> To: aconole@redhat.com; sodey@sonusnet.com; >> yuanhan.liu@linux.intel.com; Tan, Jianfeng ; >> thomas.monjalon@6wind.com; dev@dpdk.org >> Cc: Maxime Coquelin >> Subject: [dpdk-dev] [PATCH v3 0/9] virtio/vhost: Add MTU feature support >> >> This series adds support to new Virtio's MTU feature[1]. The MTU >> value is set via QEMU parameters. >> >> If the feature is negotiated (i.e supported by both host and guest, >> and valid MTU value is set in QEMU via its host_mtu parameter), QEMU >> shares the configured MTU value throught dedicated Vhost protocol >> feature. >> >> On vhost side, the value is stored in the virtio_net structure, and >> made available to the application thanks to new vhost lib's >> rte_vhost_get_mtu() function. >> >> To be able to set eth_dev's MTU value at the right time, i.e. to call >> rte_vhost_get_mtu() just after Virtio features have been negotiated >> and before the device is really started, a new vhost flag has been >> introduced (VIRTIO_DEV_READY), because the VIRTIO_DEV_RUNNING flag is >> set too late (after .new_device() ops is called). >> >> Regarding valid MTU values, the maximum MTU value accepted on vhost >> side is 65535 bytes, as defined in Virtio Spec and supported in >> Virtio-net Kernel driver. But in Virtio PMD, current maximum frame >> size is 9728 bytes (~9700 bytes MTU). So maximum MTU size accepted in >> Virtio PMD is the minimum between ~9700 bytes and host's MTU. >> >> Finally, this series also adds MTU value printing in testpmd's >> "show port info" command when non-zero. >> >> This series target v17.05 release. >> >> Cheers, >> Maxime >> >> [1]: https://lists.oasis-open.org/archives/virtio-dev/201609/msg00128.html >> >> Changes since v1: >> ----------------- >> * Rebased on top of v17.02 >> * Virtio PMD: ensure MTU value is valid before ack'ing the feature (Aaron) >> * Vhost lib/PMD: Remove MTU setting API/op (Yuanhan) >> >> Changes since v2: >> ----------------- >> * Update release notes (Thomas) >> * s/rte_vhost_mtu_get/rte_vhost_get_mtu/ (Yuanhan) >> * Use %"PRIu64" instead of %lu (Yuanhan) >> * Add rte_vhost_get_mtu in rte_vhost_version.map >> >> Maxime Coquelin (9): >> vhost: Enable VIRTIO_NET_F_MTU feature >> vhost: vhost-user: Add MTU protocol feature support >> vhost: Add new ready status flag >> vhost: Add API to get MTU value >> vhost: export MTU value >> net/vhost: Fill rte_eth_dev's MTU property >> net/virtio: Add MTU feature support >> doc: announce Virtio and Vhost MTU support >> app/testpmd: print MTU value in show port info >> >> app/test-pmd/config.c | 5 ++++ >> doc/guides/nics/features/virtio.ini | 1 + >> doc/guides/rel_notes/release_17_05.rst | 8 ++++++ >> drivers/net/vhost/rte_eth_vhost.c | 2 ++ >> drivers/net/virtio/virtio_ethdev.c | 45 >> ++++++++++++++++++++++++++++++++-- >> drivers/net/virtio/virtio_ethdev.h | 3 ++- >> drivers/net/virtio/virtio_pci.h | 3 +++ >> lib/librte_vhost/rte_vhost_version.map | 7 ++++++ >> lib/librte_vhost/rte_virtio_net.h | 15 ++++++++++++ >> lib/librte_vhost/vhost.c | 22 ++++++++++++++++- >> lib/librte_vhost/vhost.h | 9 ++++++- >> lib/librte_vhost/vhost_user.c | 44 +++++++++++++++++++++++++++--- >> --- >> lib/librte_vhost/vhost_user.h | 5 +++- >> 13 files changed, 156 insertions(+), 13 deletions(-) >> >> -- >> 2.9.3 > Hi, Maxime > > If I want have a try for this MTU function, is there any specific requirement for the settings? > Such as the qemu version, kernel version or any others? Looks like this feature are very new > in Qemu and linux side. > Thanks a lot! Sorry, for the delay. You need QEMU v2.9.0-rc at least, as this is not in v2.8? Regarding the Kernel, there are no version dependency for the host. For the guest, this is only if you use the Kernel virtio-net driver. In this case, your guest Kernel should be at least v4.10. Regards, Maxime