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 8E135A04F1; Thu, 18 Jun 2020 11:08:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3FF9B1BE9E; Thu, 18 Jun 2020 11:08:46 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 7D88A5B3A for ; Thu, 18 Jun 2020 11:08:44 +0200 (CEST) IronPort-SDR: I1O2hb9Z1oJTCB7GocrKYl2BCpgE2tvKGCsIsq3H1VhbJ19JtrLZj4asWnZowB3/xxKYI0q71n 8w5dqKLETr4A== X-IronPort-AV: E=McAfee;i="6000,8403,9655"; a="203987374" X-IronPort-AV: E=Sophos;i="5.73,526,1583222400"; d="scan'208";a="203987374" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2020 02:08:43 -0700 IronPort-SDR: 00irtoZCmjHaYM3bjzahZdNab89RTySGgDO8nzGIYnfYfd7polUbLFCtFBGMZq89hnO4V4ChmA DksQ5bRsBauA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,526,1583222400"; d="scan'208";a="421437172" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by orsmga004.jf.intel.com with ESMTP; 18 Jun 2020 02:08:43 -0700 Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by ORSMSX109.amr.corp.intel.com (10.22.240.7) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 18 Jun 2020 02:08:43 -0700 Received: from ORSEDG002.ED.cps.intel.com (10.7.248.5) by ORSMSX155.amr.corp.intel.com (10.22.240.21) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 18 Jun 2020 02:08:43 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.53) by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 18 Jun 2020 02:08:42 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hZLmVQ2/KWvyOCpegWvbfwNASqKHkJzNJWI9BoX3MFX8y8FxLtsZyMWWnvoAyZCe1sJjbxZJTjQb22WdqJTJLEo2JDp6HZ5vNiYgfHipJE6IyLnP5kqw+SIgZyUskYbg98uSE4iSVkMjO4vhZL5bhzMSW93dIkFFKh6EKB+iyo7nbmeS85rqIsGuPcVWROgxc1u7j+xykcFZF55JhtD0Pl6cAXfVaU5bsrlH9GwoOJ3hz5VMRmpBFsSmTcW/WZE36O2OHQRbUJROpHJ3NLdGrDhktydfHBhOpItsniq1cuWGm1Avq+WbKVfOpfHOBfs5JllYoYjTpcosuwMrlclBSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=stppz56llTkK8RLCCPx55/AMfpRa2dghOp63tKNZXPU=; b=Z5CMnc7jBkjVgsprDJh5XOD+0Whc8GsADSgiJVSshAGDbCnTe3SEnRvEBN+oz+ZXSonuG+QPLOLVyy2szZdvTnbF65HMv814l2//Chfq0/kV2ACt1axGms4A0puV4Pl5OB8gjgcPZJvGym5tXK5ZiRIs9wlhJMgvB6ca6cRRIMsnCEuMGBBjHbaDQJElVMt7Q40n8PMWjKNSzz7OyAGov5YUekpFPhoPjoePQyM/amD5w5ExEVNoHyI7/UJQQaGy/fiBk9Jz8b3S4H8TFify4s4Qz9L2cP46MREpqPuzrTsq1qb1j7/Eao7/6ismQEDhX6PlNdjRphBdxPNu3jReLw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=stppz56llTkK8RLCCPx55/AMfpRa2dghOp63tKNZXPU=; b=pwUBjsabycdvQu3WZm1psv5LHwTeFMYM+VhZE4dN7i1uCAfALekRKIHVjBSFoBNjTi+G094NnFCPL9Mt3SiA9aAhg+Ie5LVG5ZLPXWfzpiYzKT5vPUystwsHR7UPgFxSlR9RHzDvfTcL1SSZvtwunqzfVXGylyTPiK1mK5hRbss= Received: from BYAPR11MB3735.namprd11.prod.outlook.com (2603:10b6:a03:b4::31) by BY5PR11MB4167.namprd11.prod.outlook.com (2603:10b6:a03:185::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Thu, 18 Jun 2020 09:08:40 +0000 Received: from BYAPR11MB3735.namprd11.prod.outlook.com ([fe80::4d57:a18:a46e:4a27]) by BYAPR11MB3735.namprd11.prod.outlook.com ([fe80::4d57:a18:a46e:4a27%7]) with mapi id 15.20.3109.021; Thu, 18 Jun 2020 09:08:40 +0000 From: "Fu, Patrick" To: "Liu, Yong" CC: "Jiang, Cheng1" , "Liang, Cunming" , "dev@dpdk.org" , "maxime.coquelin@redhat.com" , "Xia, Chenbo" , "Wang, Zhihong" , "Ye, Xiaolong" Thread-Topic: [dpdk-dev] [PATCH v1 1/2] vhost: introduce async data path registration API Thread-Index: AQHWRTR11pVm6KHbwkKV3kjbr7wJ4ajeDwqw Date: Thu, 18 Jun 2020 09:08:40 +0000 Message-ID: References: <1591869725-13331-1-git-send-email-patrick.fu@intel.com> <1591869725-13331-2-git-send-email-patrick.fu@intel.com> <86228AFD5BCD8E4EBFD2B90117B5E81E635F601B@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <86228AFD5BCD8E4EBFD2B90117B5E81E635F601B@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.147.197] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bec3bde8-d649-4f92-23c0-08d8136731a2 x-ms-traffictypediagnostic: BY5PR11MB4167: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HiLET0tQys96PCZ1XJNRhzi8oBnbQcgnnC55nL6HVXqYkob7RsMzspmSzdscJWipMlK+bfyyKZlefonASUjJ2qxsMdFScqeR0PtWLiwM/3X1s5BEx9xYCaKOkvKKnjZwaYX7UcsAhNq3F7nn0e6bLvIq/9MGjzqCCbO05R1PsQpuqFSbStFvGY0wvDliErETWtH+DDIYnMS80+H/y4xjP700b5e2bDZACU54avdOKKDgsPQSmHBVjrqtJeJnNfRjKrKdioZTW37TzId0MFjLmKjQiJtWw0Hw0HivjOE2DnbWtQW18/dAn7p8UqS0avxJ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3735.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(366004)(376002)(39860400002)(346002)(8936002)(26005)(4326008)(9686003)(6506007)(52536014)(53546011)(6862004)(33656002)(2906002)(55016002)(7696005)(30864003)(5660300002)(186003)(478600001)(54906003)(64756008)(66446008)(107886003)(66556008)(86362001)(6636002)(83380400001)(71200400001)(316002)(66946007)(66476007)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 8Yzu0vahPrYSz++yuYzZ6zAxpwIhx++3voQq7AVJsIkc9VC4B0lOeVMhPyqeybS9Lu0Hq0HOWPPSCmBBXaCle1dk2vEPVDtTdTWKHnLiuV9WPB4dg7NFedQ4nU8wLNy/leTOCTNdc9djjq+6HuXMSJ34wLQaQ3hWLot2DE2xg7uy+IujBhzWcEz3MWVjdgMdEqSIuTSA2YLHgBGKFXqPgMNxEEgbCsCZfU4wBsd5JBHj1ZQhwPX5+rg5HMQpaqOfMRtbON/OzLcknADu7x+6vqyvNywUOW0gv60bkt96QuHVo1H8byN1OXcWu3CTY5NTVEuUpJB6n42NVSFB6YWaK+GJLMioOM//tku2IjUITkdB3TiuoRtr7YdysLFJEvTibVJK+495zfLvdMIUovtt+44Olg+OfkITlVgXZ6QfymbhuF5tQJiN/4JQmw58yuS9bx33vPFzE5s7fIQhGfJPZomDlHojgib4Qs0ITExbxeCD6EUnLc2rSA3/hHUln6Q6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bec3bde8-d649-4f92-23c0-08d8136731a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 09:08:40.6464 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UyHouu6qjqybU25aZ9SutBLBabK+4LJELirppfxyM2eu/D7vZmaVLSopC6/efiNeyhYPaxME/g4nXfHTYBTNfw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4167 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v1 1/2] vhost: introduce async data path registration API 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" > -----Original Message----- > From: Liu, Yong > Sent: Thursday, June 18, 2020 1:51 PM > To: Fu, Patrick > Cc: Fu, Patrick ; Jiang, Cheng1 > ; Liang, Cunming ; > dev@dpdk.org; maxime.coquelin@redhat.com; Xia, Chenbo > ; Wang, Zhihong ; Ye, > Xiaolong > Subject: RE: [dpdk-dev] [PATCH v1 1/2] vhost: introduce async data path > registration API >=20 > Thanks, Patrick. So comments are inline. >=20 > > -----Original Message----- > > From: dev On Behalf Of patrick.fu@intel.com > > Sent: Thursday, June 11, 2020 6:02 PM > > To: dev@dpdk.org; maxime.coquelin@redhat.com; Xia, Chenbo > > ; Wang, Zhihong ; Ye, > > Xiaolong > > Cc: Fu, Patrick ; Jiang, Cheng1 > > ; Liang, Cunming > > Subject: [dpdk-dev] [PATCH v1 1/2] vhost: introduce async data path > > registration API > > > > From: Patrick > > > > This patch introduces registration/un-registration APIs for async data > > path together with all required data structures and DMA callback > > function proto-types. > > > > Signed-off-by: Patrick > > --- > > lib/librte_vhost/Makefile | 3 +- > > lib/librte_vhost/rte_vhost.h | 1 + > > lib/librte_vhost/rte_vhost_async.h | 134 > > +++++++++++++++++++++++++++++++++++++ > > lib/librte_vhost/socket.c | 20 ++++++ > > lib/librte_vhost/vhost.c | 74 +++++++++++++++++++- > > lib/librte_vhost/vhost.h | 30 ++++++++- > > lib/librte_vhost/vhost_user.c | 28 ++++++-- > > 7 files changed, 283 insertions(+), 7 deletions(-) create mode > > 100644 lib/librte_vhost/rte_vhost_async.h > > > > diff --git a/lib/librte_vhost/Makefile b/lib/librte_vhost/Makefile > > index e592795..3aed094 100644 > > --- a/lib/librte_vhost/Makefile > > +++ b/lib/librte_vhost/Makefile > > @@ -41,7 +41,8 @@ SRCS-$(CONFIG_RTE_LIBRTE_VHOST) :=3D fd_man.c > iotlb.c > > socket.c vhost.c \ > > vhost_user.c virtio_net.c vdpa.c > > > > # install includes > > -SYMLINK-$(CONFIG_RTE_LIBRTE_VHOST)-include +=3D rte_vhost.h > rte_vdpa.h > > +SYMLINK-$(CONFIG_RTE_LIBRTE_VHOST)-include +=3D rte_vhost.h > rte_vdpa.h > > \ > > + rte_vhost_async.h > > > Hi Patrick, > Please also update meson build for newly added file. >=20 > Thanks, > Marvin >=20 > > # only compile vhost crypto when cryptodev is enabled ifeq > > ($(CONFIG_RTE_LIBRTE_CRYPTODEV),y) > > diff --git a/lib/librte_vhost/rte_vhost.h > > b/lib/librte_vhost/rte_vhost.h index d43669f..cec4d07 100644 > > --- a/lib/librte_vhost/rte_vhost.h > > +++ b/lib/librte_vhost/rte_vhost.h > > @@ -35,6 +35,7 @@ > > #define RTE_VHOST_USER_EXTBUF_SUPPORT (1ULL << 5) > > /* support only linear buffers (no chained mbufs) */ > > #define RTE_VHOST_USER_LINEARBUF_SUPPORT (1ULL << 6) > > +#define RTE_VHOST_USER_ASYNC_COPY (1ULL << 7) > > > > /** Protocol features. */ > > #ifndef VHOST_USER_PROTOCOL_F_MQ > > diff --git a/lib/librte_vhost/rte_vhost_async.h > > b/lib/librte_vhost/rte_vhost_async.h > > new file mode 100644 > > index 0000000..82f2ebe > > --- /dev/null > > +++ b/lib/librte_vhost/rte_vhost_async.h > > @@ -0,0 +1,134 @@ > > +/* SPDX-License-Identifier: BSD-3-Clause > > + * Copyright(c) 2018 Intel Corporation */ >=20 > s/2018/2020/ >=20 > > + > > +#ifndef _RTE_VHOST_ASYNC_H_ > > +#define _RTE_VHOST_ASYNC_H_ > > + > > +#include "rte_vhost.h" > > + > > +/** > > + * iovec iterator > > + */ > > +struct iov_it { > > + /** offset to the first byte of interesting data */ > > + size_t offset; > > + /** total bytes of data in this iterator */ > > + size_t count; > > + /** pointer to the iovec array */ > > + struct iovec *iov; > > + /** number of iovec in this iterator */ > > + unsigned long nr_segs; > > +}; >=20 > Patrick, > I think structure named as "it" is too generic for understanding, please = use > more meaningful name like "iov_iter". >=20 > > + > > +/** > > + * dma transfer descriptor pair > > + */ > > +struct dma_trans_desc { > > + /** source memory iov_it */ > > + struct iov_it *src; > > + /** destination memory iov_it */ > > + struct iov_it *dst; > > +}; > > + >=20 > This series patch named as sync copy, and dma is just one async copy > method which underneath hardware supplied. > IMHO, structure is better to named as "async_copy_desc" which matched the > overall concept. >=20 > > +/** > > + * dma transfer status > > + */ > > +struct dma_trans_status { > > + /** An array of application specific data for source memory */ > > + uintptr_t *src_opaque_data; > > + /** An array of application specific data for destination memory */ > > + uintptr_t *dst_opaque_data; > > +}; > > + > Same as pervious comment. >=20 > > +/** > > + * dma operation callbacks to be implemented by applications */ > > +struct rte_vhost_async_channel_ops { > > + /** > > + * instruct a DMA channel to perform copies for a batch of packets > > + * > > + * @param vid > > + * id of vhost device to perform data copies > > + * @param queue_id > > + * queue id to perform data copies > > + * @param descs > > + * an array of DMA transfer memory descriptors > > + * @param opaque_data > > + * opaque data pair sending to DMA engine > > + * @param count > > + * number of elements in the "descs" array > > + * @return > > + * -1 on failure, number of descs processed on success > > + */ > > + int (*transfer_data)(int vid, uint16_t queue_id, > > + struct dma_trans_desc *descs, > > + struct dma_trans_status *opaque_data, > > + uint16_t count); > > + /** > > + * check copy-completed packets from a DMA channel > > + * @param vid > > + * id of vhost device to check copy completion > > + * @param queue_id > > + * queue id to check copyp completion > > + * @param opaque_data > > + * buffer to receive the opaque data pair from DMA engine > > + * @param max_packets > > + * max number of packets could be completed > > + * @return > > + * -1 on failure, number of iov segments completed on success > > + */ > > + int (*check_completed_copies)(int vid, uint16_t queue_id, > > + struct dma_trans_status *opaque_data, > > + uint16_t max_packets); > > +}; > > + > > +/** > > + * dma channel feature bit definition */ struct > > +dma_channel_features { > > + union { > > + uint32_t intval; > > + struct { > > + uint32_t inorder:1; > > + uint32_t resvd0115:15; > > + uint32_t threshold:12; > > + uint32_t resvd2831:4; > > + }; > > + }; > > +}; > > + >=20 > Naming feature bits as "intval" may cause confusion, why not just use its > meaning like "engine_features"? > I'm not sure whether format "resvd0115" match dpdk copy style. In my mind= , > dpdk will use resvd_0 and resvd_1 for two reserved elements. >=20 For comments here above, I will take changes in v2 patch > > + if (dev) > > + dev->async_copy =3D 1; > > + } > > + >=20 > IMHO, user can chose which queue utilize async copy as backend hardware > resource is limited. > So should async_copy enable flag be saved in virtqueue structure? >=20 We have per queue flag to identify the enabling status of a specific queue.= =20 "async_copy" flag is a dev level flag which identifies the async capability= of a vhost device.=20 This is necessary because we rely on this flag to do initialization work if= the vhost backend need to support async mode at any of its queues.=20 > > VHOST_LOG_CONFIG(INFO, "new device, handle is %d\n", vid); > > > > if (vsocket->notify_ops->new_connection) { @@ -891,6 +900,17 @@ > > struct vhost_user_reconnect_list { > > goto out_mutex; > > } > > > > + vsocket->async_copy =3D flags & RTE_VHOST_USER_ASYNC_COPY; > > + > > + if (vsocket->async_copy && > > + (flags & (RTE_VHOST_USER_IOMMU_SUPPORT | > > + RTE_VHOST_USER_POSTCOPY_SUPPORT))) { > > + VHOST_LOG_CONFIG(ERR, "error: enabling async copy and > > IOMMU " > > + "or post-copy feature simultaneously is not " > > + "supported\n"); > > + goto out_mutex; > > + } > > + > > /* > > * Set the supported features correctly for the builtin vhost-user > > * net driver. > > diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c index > > 0266318..e6b688a 100644 > > --- a/lib/librte_vhost/vhost.c > > +++ b/lib/librte_vhost/vhost.c > > @@ -332,8 +332,13 @@ > > { > > if (vq_is_packed(dev)) > > rte_free(vq->shadow_used_packed); > > - else > > + else { > > rte_free(vq->shadow_used_split); > > + if (vq->async_pkts_pending) > > + rte_free(vq->async_pkts_pending); > > + if (vq->async_pending_info) > > + rte_free(vq->async_pending_info); > > + } > > rte_free(vq->batch_copy_elems); > > rte_mempool_free(vq->iotlb_pool); > > rte_free(vq); > > @@ -1527,3 +1532,70 @@ int rte_vhost_extern_callback_register(int vid, > > if (vhost_data_log_level >=3D 0) > > rte_log_set_level(vhost_data_log_level, > > RTE_LOG_WARNING); > > } > > + > > +int rte_vhost_async_channel_register(int vid, uint16_t queue_id, > > + uint32_t features, > > + struct rte_vhost_async_channel_ops > > *ops) > > +{ > > + struct vhost_virtqueue *vq; > > + struct virtio_net *dev =3D get_device(vid); > > + struct dma_channel_features f; > > + > > + if (dev =3D=3D NULL || ops =3D=3D NULL) > > + return -1; > > + > > + f.intval =3D features; > > + > > + vq =3D dev->virtqueue[queue_id]; > > + > > + if (vq =3D=3D NULL) > > + return -1; > > + > > + /** packed queue is not supported */ > > + if (vq_is_packed(dev) || !f.inorder) > > + return -1; > > + > Virtio already has in_order concept, these two names are so like and can = be > easily messed up. Please consider how to distinguish them. >=20 What about "async_inorder" > > + if (ops->check_completed_copies =3D=3D NULL || > > + ops->transfer_data =3D=3D NULL) > > + return -1; > > + >=20 > Previous error is unlikely to be true, unlikely macro may be helpful for > understanding. >=20 Will update in v2 patch > > + rte_spinlock_lock(&vq->access_lock); > > + > > + vq->async_ops.check_completed_copies =3D ops- > > >check_completed_copies; > > + vq->async_ops.transfer_data =3D ops->transfer_data; > > + > > + vq->async_inorder =3D f.inorder; > > + vq->async_threshold =3D f.threshold; > > + > > + vq->async_registered =3D true; > > + > > + rte_spinlock_unlock(&vq->access_lock); > > + > > + return 0; > > +} > > + > > +int rte_vhost_async_channel_unregister(int vid, uint16_t queue_id) { > > + struct vhost_virtqueue *vq; > > + struct virtio_net *dev =3D get_device(vid); > > + > > + if (dev =3D=3D NULL) > > + return -1; > > + > > + vq =3D dev->virtqueue[queue_id]; > > + > > + if (vq =3D=3D NULL) > > + return -1; > > + > > + rte_spinlock_lock(&vq->access_lock); > > + > > + vq->async_ops.transfer_data =3D NULL; > > + vq->async_ops.check_completed_copies =3D NULL; > > + > > + vq->async_registered =3D false; > > + > > + rte_spinlock_unlock(&vq->access_lock); > > + > > + return 0; > > +} > > + > > diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h index > > df98d15..a7fbe23 100644 > > --- a/lib/librte_vhost/vhost.h > > +++ b/lib/librte_vhost/vhost.h > > @@ -23,6 +23,8 @@ > > #include "rte_vhost.h" > > #include "rte_vdpa.h" > > > > +#include "rte_vhost_async.h" > > + > > /* Used to indicate that the device is running on a data core */ > > #define VIRTIO_DEV_RUNNING 1 > > /* Used to indicate that the device is ready to operate */ @@ -39,6 > > +41,11 @@ > > > > #define VHOST_LOG_CACHE_NR 32 > > > > +#define MAX_PKT_BURST 32 > > + > > +#define VHOST_MAX_ASYNC_IT (MAX_PKT_BURST * 2) #define > > +VHOST_MAX_ASYNC_VEC (BUF_VECTOR_MAX * 2) > > + > > #define PACKED_DESC_ENQUEUE_USED_FLAG(w) \ > > ((w) ? (VRING_DESC_F_AVAIL | VRING_DESC_F_USED | > > VRING_DESC_F_WRITE) : \ > > VRING_DESC_F_WRITE) > > @@ -200,6 +207,25 @@ struct vhost_virtqueue { > > TAILQ_HEAD(, vhost_iotlb_entry) iotlb_list; > > int iotlb_cache_nr; > > TAILQ_HEAD(, vhost_iotlb_entry) iotlb_pending_list; > > + > > + /* operation callbacks for async dma */ > > + struct rte_vhost_async_channel_ops async_ops; > > + > > + struct iov_it it_pool[VHOST_MAX_ASYNC_IT]; > > + struct iovec vec_pool[VHOST_MAX_ASYNC_VEC]; > > + > > + /* async data transfer status */ > > + uintptr_t **async_pkts_pending; > > + #define ASYNC_PENDING_INFO_N_MSK 0xFFFF > > + #define ASYNC_PENDING_INFO_N_SFT 16 > > + uint64_t *async_pending_info; > > + uint16_t async_pkts_idx; > > + uint16_t async_pkts_inflight_n; > > + > > + /* vq async features */ > > + bool async_inorder; > > + bool async_registered; > > + uint16_t async_threshold; > > } __rte_cache_aligned; > > > > /* Old kernels have no such macros defined */ @@ -353,6 +379,7 @@ > > struct virtio_net { > > int16_t broadcast_rarp; > > uint32_t nr_vring; > > int dequeue_zero_copy; > > + int async_copy; > > int extbuf; > > int linearbuf; > > struct vhost_virtqueue *virtqueue[VHOST_MAX_QUEUE_PAIRS * 2]; > > @@ -702,7 +729,8 @@ uint64_t translate_log_addr(struct virtio_net > > *dev, struct vhost_virtqueue *vq, > > /* Don't kick guest if we don't reach index specified by guest. */ > > if (dev->features & (1ULL << VIRTIO_RING_F_EVENT_IDX)) { > > uint16_t old =3D vq->signalled_used; > > - uint16_t new =3D vq->last_used_idx; > > + uint16_t new =3D vq->async_pkts_inflight_n ? > > + vq->used->idx:vq->last_used_idx; > > bool signalled_used_valid =3D vq->signalled_used_valid; > > > > vq->signalled_used =3D new; > > diff --git a/lib/librte_vhost/vhost_user.c > > b/lib/librte_vhost/vhost_user.c index 84bebad..d7600bf 100644 > > --- a/lib/librte_vhost/vhost_user.c > > +++ b/lib/librte_vhost/vhost_user.c > > @@ -464,12 +464,25 @@ > > } else { > > if (vq->shadow_used_split) > > rte_free(vq->shadow_used_split); > > + if (vq->async_pkts_pending) > > + rte_free(vq->async_pkts_pending); > > + if (vq->async_pending_info) > > + rte_free(vq->async_pending_info); > > + > > vq->shadow_used_split =3D rte_malloc(NULL, > > vq->size * sizeof(struct vring_used_elem), > > RTE_CACHE_LINE_SIZE); > > - if (!vq->shadow_used_split) { > > + vq->async_pkts_pending =3D rte_malloc(NULL, > > + vq->size * sizeof(uintptr_t), > > + RTE_CACHE_LINE_SIZE); > > + vq->async_pending_info =3D rte_malloc(NULL, > > + vq->size * sizeof(uint64_t), > > + RTE_CACHE_LINE_SIZE); > > + if (!vq->shadow_used_split || > > + !vq->async_pkts_pending || > > + !vq->async_pending_info) { > > VHOST_LOG_CONFIG(ERR, > > - "failed to allocate memory for > > shadow used ring.\n"); > > + "failed to allocate memory for vq > > internal data.\n"); >=20 > If async copy not enabled, there will be no need to allocate related stru= ctures. >=20 Will update in v2 patch Thanks, Patrick