From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 800602BA3 for ; Wed, 5 Apr 2017 11:42:42 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP; 05 Apr 2017 02:42:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,278,1486454400"; d="scan'208";a="84938865" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.196]) ([10.239.67.196]) by fmsmga006.fm.intel.com with ESMTP; 05 Apr 2017 02:42:40 -0700 To: Maxime Coquelin , aconole@redhat.com, sodey@sonusnet.com, yuanhan.liu@linux.intel.com, thomas.monjalon@6wind.com, dev@dpdk.org References: <20170213142820.8964-1-maxime.coquelin@redhat.com> <20170312163406.17714-1-maxime.coquelin@redhat.com> <20170312163406.17714-8-maxime.coquelin@redhat.com> <0e5df10f-c61f-b1cd-a604-148379485ef2@intel.com> <12327337-70fd-168a-d836-026d619089f8@redhat.com> From: "Tan, Jianfeng" Message-ID: Date: Wed, 5 Apr 2017 17:42:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <12327337-70fd-168a-d836-026d619089f8@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v3 7/9] net/virtio: 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: Wed, 05 Apr 2017 09:42:43 -0000 Hi Maxime, Thank you for replying. On 4/5/2017 3:11 PM, Maxime Coquelin wrote: > Hi Jianfeng, > > On 04/05/2017 06:52 AM, Tan, Jianfeng wrote: >> Hi Maxime, >> >> Have some confusion about this feature. Please help confirm. >> >> (1) With this feature, we only support to advertise MTU value which is >> defined by QEMU to frontend and backend driver separately. (2) But it >> does not allow frontend driver to set a different MTU to QEMU and then >> to vhost backend. >> >> Correct? >> If it's correct, why not MTU works like (2)? > > Because idea is that the hosts advertises the maximum MTU value it > supports. The frontend driver is free to use a smaller value. The goal > of this change is to make possible to set a uniform MTU value across > the infrastructure, the management tools giving a hint to the guests on > the MTU value it should use. Based on that MTU is the maximum packet size that can be sent instead of that can be received: (1) Why vhost (as a device) does not drop any packets which are longer than MTU when dequeue()? (2) See some NICs also use MTU to calculate maximum packet size that can be received, like ixgbe, i40e, shall we also do that? > > Having the frontend setting the backend MTU dynamically would require > some negotiation at runtime, and is out of the scope of this change. > Do you have some use cases for this? No, just to understand more about this feature. Thank you! Thanks, Jianfeng > > Regards, > Maxime >> Thanks, >> Jianfeng