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 4E7B8A057C; Thu, 26 Mar 2020 09:25:10 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9EC901C0B2; Thu, 26 Mar 2020 09:25:09 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id DBC9C1C0AD for ; Thu, 26 Mar 2020 09:25:06 +0100 (CET) IronPort-SDR: pEp3f3C7VrzUfR+IUDbVGVjFjBK9Ynf8BmFYyLWgoGMNzGnsQOCofMQYbT3lZnTy5IZQfVAKEy KPrDE9WA02vA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2020 01:25:05 -0700 IronPort-SDR: eUVlPMVeHFyWxUXwzpNU406PbjWfKYk/H6pccxrtxurvSH9sJ2C83HWmWruY8r9jUY+BhSjgh+ cVV8VD6JNw9A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,307,1580803200"; d="scan'208";a="358075763" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga001.fm.intel.com with ESMTP; 26 Mar 2020 01:25:05 -0700 Received: from shsmsx605.ccr.corp.intel.com (10.109.6.215) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 26 Mar 2020 01:25:05 -0700 Received: from shsmsx602.ccr.corp.intel.com (10.109.6.142) by SHSMSX605.ccr.corp.intel.com (10.109.6.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 26 Mar 2020 16:25:03 +0800 Received: from shsmsx602.ccr.corp.intel.com ([10.109.6.142]) by SHSMSX602.ccr.corp.intel.com ([10.109.6.142]) with mapi id 15.01.1713.004; Thu, 26 Mar 2020 16:25:03 +0800 From: "Hu, Jiayu" To: Maxime Coquelin , "dev@dpdk.org" CC: "Ye, Xiaolong" , "Wang, Zhihong" Thread-Topic: [PATCH 0/4] Support DMA-accelerated Tx operations for vhost-user PMD Thread-Index: AQHV/AXRSj5F1TraekipaLGRDPhWjKhMBbGAgAN5u9D//57jAIAAqshQgAo/4gCAAI0RwA== Date: Thu, 26 Mar 2020 08:25:03 +0000 Message-ID: <1007246585054daca2afce895ac9f875@intel.com> References: <1584436885-18651-1-git-send-email-jiayu.hu@intel.com> <370798e0-b006-4a33-d8d9-1aea7bf4af49@redhat.com> <33221483053a41e8bd8d4bd0cb582634@intel.com> <63c79431-96bf-79e9-fb75-1714e194257f@redhat.com> <39c02e0f982a4ce88ae421e6a9c7d26e@intel.com> <2f98b893-c486-6b0d-d824-61a5fef994cf@redhat.com> In-Reply-To: <2f98b893-c486-6b0d-d824-61a5fef994cf@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.2.0.6 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 0/4] Support DMA-accelerated Tx operations for vhost-user PMD 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" Hi Maxime, > -----Original Message----- > From: Maxime Coquelin > Sent: Thursday, March 26, 2020 3:53 PM > To: Hu, Jiayu ; dev@dpdk.org > Cc: Ye, Xiaolong ; Wang, Zhihong > > Subject: Re: [PATCH 0/4] Support DMA-accelerated Tx operations for vhost- > user PMD >=20 > Hi Jiayu, >=20 > On 3/19/20 12:47 PM, Hu, Jiayu wrote: >=20 > >> > >> Ok, so what about: > >> > >> Introducing a pair of callbacks in struct virtio_net for DMA enqueue a= nd > >> dequeue. > >> > >> lib/librte_vhost/ioat.c which would implement dma_enqueue and > >> dma_dequeue callback for IOAT. As it will live in the vhost lib > >> directory, it will be easy to refactor the code to share as much as > >> possible and so avoid code duplication. > >> > >> In rte_vhost_enqueue/dequeue_burst, if the dma callback is set, then > >> call it instead of the SW datapath. It adds a few cycle, but this is > >> much more sane IMHO. > > > > The problem is that current semantics of rte_vhost_enqueue/dequeue API > > are conflict with I/OAT accelerated data path. To improve the performan= ce, > > the I/OAT works in an asynchronous manner, where the CPU just submits > > copy jobs to the I/OAT without waiting for its copy completion. For > > rte_vhost_enqueue_burst, users cannot reuse enqueued pktmbufs when > it > > returns, as the I/OAT may still use them. For rte_vhost_dequeue_burst, > > users will not get incoming packets as the I/OAT is still performing pa= cket > > copies. As you can see, when enabling I/OAT acceleration, the semantics= of > > the two API are changed. If we keep the same API name but changing thei= r > > semantic, this may confuse users, IMHO. >=20 > Ok, so it is basically the same as zero-copy for dequeue path, right? > If a new API is necessary, then it would be better to add it in Vhost > library for async enqueue/dequeue. > It could be used also for Tx zero-copy, and so the sync version would > save some cycles as we could remove the zero-copy support there. >=20 > What do you think? Yes, you are right. The better way is to provide new API with asynchronous semantics in vhost library. In addition, the vhost library better provides = DMA operation callbacks to avoid using vender specific API. The asynchronous AP= I may look like rte_vhost_try_enqueue_burst() and rte_vhost_get_completed_packets= (). The first one is to perform enqueue logic, and the second one is to return pktmbufs whose all copies are completed to users. How do you think? Thanks, Jiayu >=20 > I really object to implement vring handling into the Vhost PMD, this is > the role of the Vhost library. >=20 > Thanks, > Maxime