From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 213D0A2EDB for ; Wed, 2 Oct 2019 01:10:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2DE4C1B94D; Wed, 2 Oct 2019 01:10:28 +0200 (CEST) Received: from sysclose.org (smtp.sysclose.org [69.164.214.230]) by dpdk.org (Postfix) with ESMTP id 45B4D1B948 for ; Wed, 2 Oct 2019 01:10:26 +0200 (CEST) Received: by sysclose.org (Postfix, from userid 5001) id 65D256630; Tue, 1 Oct 2019 23:10:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 sysclose.org 65D256630 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sysclose.org; s=201903; t=1569971446; bh=A1qURFrehrDl9HwKevNqomvihfzcGa4uTNLhmw6SFa0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HsfCrnWGXLcC0R0G7eb7nKxxodhIUJWXRvKLkIdW1Fu9ELV/rGjtzIWvi+xTLlD4H CPK1M75xNO0qO3w3oy+5/pBXXzQ0dbwnlkuW11cGcQXlG9AxczLu5X373jhMILLiaM 26kcVhfmPJuZa2LCh+QJF5mtLYn58QguznSYyuMaeGy27l9mG2K0mbxobtIuakHAcl JC9slBCy7DihHoBHoGLgweeXeKbxExDOxKNkyda2YKMja4CIVnCQ1IJUqm5JIgKYX4 cKgLT+S8jKQ8yxMTZO7D+FfI3eDBQD0cm2czOSZ4jzqKv63lZEi4S+K8UpeIi8rtV/ 5JurLnrs7fXow== X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.sysclose.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.0 Received: from p50.lan (unknown [177.183.215.210]) by sysclose.org (Postfix) with ESMTPSA id 79C7065B4; Tue, 1 Oct 2019 23:10:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 sysclose.org 79C7065B4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sysclose.org; s=201903; t=1569971445; bh=A1qURFrehrDl9HwKevNqomvihfzcGa4uTNLhmw6SFa0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RumXU2leHxHEigAEbfhaZ4XprfpU5d0BqcVUx+WLEZfLmINzEc3jVB4ZrEjvpIKQU 9Kci0q6Dwe1GYss5EQSSdA1g/hBJ+m+MEgeWhJ0bXUejWnp7vBkB/Loo4OAWwglFGG pp0wAM1BInsQzF6dnel0Bx6onnkka8Fclj9c9WrlPXHNcMiAriyxrYwN8TrQ5l1t/3 HJiGzu1zB1jNhmhF75T1mRdXIfukFsx3s3sVF6Ri/nHiJfgmO2uE8qWylh9v3Q1udV 7BLADe69uc09rJRszn/fGlscxmRXk7hTuoiW/sIT8XRxjQNnoG0TISkyJRny6nok7d Z6BlySnJhn6Ag== Date: Tue, 1 Oct 2019 20:10:17 -0300 From: Flavio Leitner To: dev@dpdk.org Cc: Maxime Coquelin , Tiwei Bie , Zhihong Wang , Obrembski MichalX , Stokes Ian Message-ID: <20191001193827.44597f35@p50.lan> In-Reply-To: <20191001221935.12140-1-fbl@sysclose.org> References: <20191001221935.12140-1-fbl@sysclose.org> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] vhost: add support to large linear mbufs 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 1 Oct 2019 19:19:35 -0300 Flavio Leitner wrote: > The rte_vhost_dequeue_burst supports two ways of dequeuing data. If > the data fits into a buffer, then all data is copied and a single > linear buffer is returned. Otherwise it allocates additional mbufs > and chains them together to return a multiple segments mbuf. > > While that covers most use cases, it forces applications that need > to work with larger data sizes to support multiple segments mbufs. > The non-linear characteristic brings complexity and performance > implications to the application. > > To resolve the issue, change the API so that the application can > optionally provide a second mempool containing larger mbufs. If that > is not provided (NULL), the behavior remains as before the change. > Otherwise, the data size is checked and the corresponding mempool > is used to return linear mbufs. > > Signed-off-by: Flavio Leitner The use case behind the patch is TSO support in DPDK accelerated Open vSwitch (customers are using ovs-dpdk to send big packets too!). The effort has been going on for many months now. There is a recent proposal in OvS dev mailing using the API as is today here: https://mail.openvswitch.org/pipermail/ovs-dev/2019-September/362573.html There is also a reply from me in that thread with the patches implementing a Proof-Of-Concept with the proposed API change: https://mail.openvswitch.org/pipermail/ovs-dev/2019-September/362881.html I opted to improve the current API instead of adding a new one, but I have no strong opinion either way. I know it's a bit late for v19.11, but since the TSO support effort is going on for months now and OvS uses only LTS, I wonder if this can be part of v19.11. Thanks, fbl