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 CE97CFE5 for ; Wed, 7 Sep 2016 10:28:10 +0200 (CEST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EEC7AC057FA9; Wed, 7 Sep 2016 08:28:09 +0000 (UTC) Received: from [10.36.7.10] (vpn1-7-10.ams2.redhat.com [10.36.7.10]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u878S7jF015876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2016 04:28:08 -0400 To: "Dey, Souvik" , "stephen@networkplumber.org" References: <20160829230240.20164-1-sodey@sonusnet.com> <49bce2ef-ffbd-96ff-6f9c-6c37bb7c7a90@redhat.com> Cc: "dev@dpdk.org" From: Maxime Coquelin Message-ID: <885bb225-8841-a758-4ed3-0ca9b54e6bf3@redhat.com> Date: Wed, 7 Sep 2016 10:28:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 07 Sep 2016 08:28:10 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2016 08:28:11 -0000 On 09/07/2016 04:11 AM, Dey, Souvik wrote: > Hi Maxime, > In that case let this fix be there till the time the new implementation comes in. We can re-visit the changes again in the new implementation and then decide to keep this or remove it. Hope this serves all the purposes. Sure, I'm fine with your proposal. Thanks, Maxime > > -- > Regards, > Souvik > > -----Original Message----- > From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] > Sent: Friday, September 2, 2016 3:06 AM > To: Dey, Souvik ; stephen@networkplumber.org > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio > > Hi Souvik, > > On 09/02/2016 12:20 AM, Dey, Souvik wrote: >> Hi Maxime, >> When is patches or new implementation going to come in the release ? if it is not 16.11 then, can we keep this change till the new virtio changes come in the release. And if it is already planned for 16.11, then can I get a little more information on that. >> > I'm currently working on qemu part implementation, first RFC should be sent next week. > > Goal is to have it in 16.11, but I cannot commit, as the spec update has not been acked yet. > > For more information, you can start by having a look at the spec review: > https://lists.oasis-open.org/archives/virtio-dev/201608/msg00056.html > > Regards, > Maxime > >> -- >> Regards, >> Souvik >> >> -----Original Message----- >> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] >> Sent: Tuesday, August 30, 2016 3:58 AM >> To: Dey, Souvik ; stephen@networkplumber.org; >> huawei.xie@intel.com; yuanhan.liu@linux.intel.com >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v2] add mtu set in virtio >> >> Hi Souvik, >> >> On 08/30/2016 01:02 AM, souvikdey33 wrote: >>> Signed-off-by: Souvik Dey >>> >>> Fixes: 1fb8e8896ca8 ("Signed-off-by: Souvik Dey >>> ") >>> Reviewed-by: Stephen Hemminger >>> >>> Virtio interfaces should also support setting of mtu, as in case of >>> cloud it is expected to have the consistent mtu across the >>> infrastructure that the dhcp server sends and not hardcoded to 1500(default). >>> --- >>> drivers/net/virtio/virtio_ethdev.c | 12 ++++++++++++ >>> 1 file changed, 12 insertions(+) >> >> FYI, there are some on-going changes in the VIRTIO specification so that the VHOST interface exposes its MTU to its VIRTIO peer. >> It may also be used as an alternative of what you patch achieves. >> >> I am working on its implementation in Qemu/DPDK, our goal being to reduce performance drops for small packets with Rx mergeable buffers feature enabled. >> >> Regards, >> Maxime >>