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 8023EA0350; Wed, 1 Jul 2020 10:51:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D4F701C1E1; Wed, 1 Jul 2020 10:51:46 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 4F5A81C1A8 for ; Wed, 1 Jul 2020 10:51:44 +0200 (CEST) IronPort-SDR: DHyWrF9dMyPcgbau4G6uvdRj+Z772kzzpw5Kvh3M1YeWMGLEcn89sXNroHnuISt3ZpU+ZOQFkl iYhk8hWrBAdw== X-IronPort-AV: E=McAfee;i="6000,8403,9668"; a="144685784" X-IronPort-AV: E=Sophos;i="5.75,299,1589266800"; d="scan'208";a="144685784" 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; 01 Jul 2020 01:51:43 -0700 IronPort-SDR: kY0OTgadOcLlYpUzVtBaN0oLp14+/KH0llbTxAT/02ASZEX2AcZCcVAU1uPqIV8IOkS6UoKIsE 9KpJTIMKTB/g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,299,1589266800"; d="scan'208";a="386948519" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga001.fm.intel.com with ESMTP; 01 Jul 2020 01:51:43 -0700 Received: from fmsmsx123.amr.corp.intel.com (10.18.125.38) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 1 Jul 2020 01:50:57 -0700 Received: from shsmsx108.ccr.corp.intel.com (10.239.4.97) by fmsmsx123.amr.corp.intel.com (10.18.125.38) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 1 Jul 2020 01:50:57 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.89]) by SHSMSX108.ccr.corp.intel.com ([169.254.8.185]) with mapi id 14.03.0439.000; Wed, 1 Jul 2020 16:50:54 +0800 From: "Liu, Yong" To: "Fu, Patrick" , "dev@dpdk.org" , "maxime.coquelin@redhat.com" , "Xia, Chenbo" , "Wang, Zhihong" CC: "Fu, Patrick" , "Wang, Yinan" , "Jiang, Cheng1" , "Liang, Cunming" Thread-Topic: [dpdk-dev] [PATCH v2 2/2] vhost: introduce async enqueue for split ring Thread-Index: AQHWTiVbMnXIbhjm6UiUWGzDlWa9C6jyaPhg Date: Wed, 1 Jul 2020 08:50:54 +0000 Message-ID: <86228AFD5BCD8E4EBFD2B90117B5E81E63602CC3@SHSMSX103.ccr.corp.intel.com> References: <1593441849-27306-1-git-send-email-patrick.fu@intel.com> <1593441849-27306-3-git-send-email-patrick.fu@intel.com> In-Reply-To: <1593441849-27306-3-git-send-email-patrick.fu@intel.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 2/2] vhost: introduce async enqueue for split ring 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" >=20 > +#define VHOST_ASYNC_BATCH_THRESHOLD 8 > + Not very clear about why batch number is 8. It is better to save it in rte_= vhost_async_features if the value come from hardware requirement.=20 > + > +static __rte_noinline uint32_t > +virtio_dev_rx_async_submit_split(struct virtio_net *dev, > + struct vhost_virtqueue *vq, uint16_t queue_id, > + struct rte_mbuf **pkts, uint32_t count) > +{ > + uint32_t pkt_idx =3D 0, pkt_burst_idx =3D 0; > + uint16_t num_buffers; > + struct buf_vector buf_vec[BUF_VECTOR_MAX]; > + uint16_t avail_head, last_idx, shadow_idx; > + > + struct rte_vhost_iov_iter *it_pool =3D vq->it_pool; > + struct iovec *vec_pool =3D vq->vec_pool; > + struct rte_vhost_async_desc tdes[MAX_PKT_BURST]; > + struct iovec *src_iovec =3D vec_pool; > + struct iovec *dst_iovec =3D vec_pool + (VHOST_MAX_ASYNC_VEC >> 1); > + struct rte_vhost_iov_iter *src_it =3D it_pool; > + struct rte_vhost_iov_iter *dst_it =3D it_pool + 1; > + uint16_t n_free_slot, slot_idx; > + int n_pkts =3D 0; > + > + avail_head =3D *((volatile uint16_t *)&vq->avail->idx); > + last_idx =3D vq->last_avail_idx; > + shadow_idx =3D vq->shadow_used_idx; > + > + /* > + * The ordering between avail index and > + * desc reads needs to be enforced. > + */ > + rte_smp_rmb(); > + > + rte_prefetch0(&vq->avail->ring[vq->last_avail_idx & (vq->size - 1)]); > + > + for (pkt_idx =3D 0; pkt_idx < count; pkt_idx++) { > + uint32_t pkt_len =3D pkts[pkt_idx]->pkt_len + dev->vhost_hlen; > + uint16_t nr_vec =3D 0; > + > + if (unlikely(reserve_avail_buf_split(dev, vq, > + pkt_len, buf_vec, > &num_buffers, > + avail_head, &nr_vec) < 0)) { > + VHOST_LOG_DATA(DEBUG, > + "(%d) failed to get enough desc from > vring\n", > + dev->vid); > + vq->shadow_used_idx -=3D num_buffers; > + break; > + } > + > + VHOST_LOG_DATA(DEBUG, "(%d) current index %d | end > index %d\n", > + dev->vid, vq->last_avail_idx, > + vq->last_avail_idx + num_buffers); > + > + if (async_mbuf_to_desc(dev, vq, pkts[pkt_idx], > + buf_vec, nr_vec, num_buffers, > + src_iovec, dst_iovec, src_it, dst_it) < 0) { > + vq->shadow_used_idx -=3D num_buffers; > + break; > + } > + > + slot_idx =3D (vq->async_pkts_idx + pkt_idx) & (vq->size - 1); > + if (src_it->count) { > + async_fill_des(&tdes[pkt_burst_idx], src_it, dst_it); > + pkt_burst_idx++; > + vq->async_pending_info[slot_idx] =3D > + num_buffers | (src_it->nr_segs << 16); > + src_iovec +=3D src_it->nr_segs; > + dst_iovec +=3D dst_it->nr_segs; > + src_it +=3D 2; > + dst_it +=3D 2; Patrick,=20 In my understanding, nr_segs type definition can follow nr_vec type definit= ion (uint16_t). By that can short the data saved in async_pkts_pending from= 64bit to 32bit.=20 Since those information will be used in datapath, the smaller size will get= the better perf.=20 It is better to replace integer 2 with macro.=20 Thanks, Marvin