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 3FD6D2A6C for ; Wed, 5 Apr 2017 09:11:12 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5AF7280084; Wed, 5 Apr 2017 07:11:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5AF7280084 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=maxime.coquelin@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5AF7280084 Received: from [10.36.112.18] (ovpn-112-18.ams2.redhat.com [10.36.112.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ABA139182A; Wed, 5 Apr 2017 07:11:09 +0000 (UTC) To: "Tan, Jianfeng" , 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> From: Maxime Coquelin Message-ID: <12327337-70fd-168a-d836-026d619089f8@redhat.com> Date: Wed, 5 Apr 2017 09:11:08 +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: <0e5df10f-c61f-b1cd-a604-148379485ef2@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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 05 Apr 2017 07:11:11 +0000 (UTC) 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 07:11:12 -0000 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. 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? Regards, Maxime > Thanks, > Jianfeng