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 903EC106A for ; Tue, 29 Nov 2016 09:10:06 +0100 (CET) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 9AA5781F03; Tue, 29 Nov 2016 08:10:05 +0000 (UTC) Received: from [10.36.7.65] (vpn1-7-65.ams2.redhat.com [10.36.7.65]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAT89xsB030271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Nov 2016 03:10:01 -0500 To: Thomas Monjalon , "Kavanagh, Mark B" , Kevin Traynor , Yuanhan Liu References: <20161011173526-mutt-send-email-mst@kernel.org> <67cfb109-8729-916e-5535-80af620bafe5@redhat.com> <5176838.Upmb1ZYUhB@xps13> Cc: dev@dpdk.org, "Weglicki, MichalX" , "Michael S. Tsirkin" , Stephen Hemminger , qemu-devel@nongnu.org, libvir-list@redhat.com, vpp-dev@lists.fd.io, =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , olivier.matz@6wind.com From: Maxime Coquelin Message-ID: <8df88bf1-cd59-74e8-5d18-7bb8ee05ff27@redhat.com> Date: Tue, 29 Nov 2016 09:09:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <5176838.Upmb1ZYUhB@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 29 Nov 2016 08:10:05 +0000 (UTC) Subject: Re: [dpdk-dev] dpdk/vpp and cross-version migration for vhost 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: Tue, 29 Nov 2016 08:10:06 -0000 On 11/28/2016 11:18 PM, Thomas Monjalon wrote: > 2016-11-28 16:28, Maxime Coquelin: >> On 11/24/2016 04:24 PM, Kavanagh, Mark B wrote: >>> DPDK v16.04 added support for vHost User TSO; as such, by default, >>> TSO is advertised to guest devices as an available feature during >>> feature negotiation with QEMU. >>> However, while the vHost user backend sets up the majority of the >>> mbuf fields that are required for TSO, there is still a reliance >>> on the associated DPDK application (i.e. in this case OvS-DPDK) >>> to set the remaining flags and/or offsets. >>> Since OvS-DPDK doesn't currently provide that functionality, it is >>> necessary to explicitly disable TSO; otherwise, undefined behaviour >>> will ensue. >> >> Thanks Mark for the clarification. >> >> In this case, maybe we could add a DPDK build option to disable Vhost's >> TSO support, that would be selected for OVS packages? > > Why do you prefer a build-time option rather than the run-time config > with rte_vhost_feature_disable()? Because we need to lock the features? Right, we need to know what the backend supports before it is started, so that management tool can check where it could be migrated to. > > Reminder: build-time configuration options are forbidden in DPDK for > such usage. It would prevent other applications from using the feature > in a given distribution, just because it is not implemented in OVS. I understand, this is not the right solution. I proposed this because I misunderstood how the distributions package OVS+DPDK. > >> Does that sound reasonable? > > Maybe I'm missing something but I feel it is more reasonnable to implement > the missing code in OVS. Yes, that would be the ideal solution. OVS implements TSO and we let management tool decide whether or not enabling the features. While this is done, we could deprecate rte_vhost_feature_disable, and print error message notifying the user it should be done my the management tool. > If something is missing in DPDK, do not hesitate to request or add more > helper functions. Sure. Thanks, Maxime