From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A1ACEA0A0E; Wed, 3 Feb 2021 15:21:31 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 889A52405E9; Wed, 3 Feb 2021 15:21:31 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id A9DBE2405E7 for ; Wed, 3 Feb 2021 15:21:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612362089; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9mpKVb8/Rl+2qt+nTEieKxQJUXt+QIFcRZKRcFDjasg=; b=hjg1VIB03ZgjRMsSfWQzhbk3kuyn9vmbEpfjLo28R6oUsSqpuSam6NJAYT/Qh+kMiJnqtU xOdKhwFaNQVbY4gQrgme7GakuutAFrGFBnw7Z+/mXhz0Ch2YvVvdjnf3TODoMUyV4wD737 bgRggiiVW8XB1zfOoI+4f871twV73Ls= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-585-l-c9QoIJOJWzJmjXOe5S7w-1; Wed, 03 Feb 2021 09:21:26 -0500 X-MC-Unique: l-c9QoIJOJWzJmjXOe5S7w-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 505A8100C661; Wed, 3 Feb 2021 14:21:24 +0000 (UTC) Received: from [10.36.110.4] (unknown [10.36.110.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CAD78779FB; Wed, 3 Feb 2021 14:21:22 +0000 (UTC) To: "Jiang, Cheng1" , "Xia, Chenbo" Cc: "dev@dpdk.org" , "Hu, Jiayu" , "Yang, YvonneX" , "Wang, Yinan" References: <20210131125617.53078-1-Cheng1.jiang@intel.com> <20210202061751.1614-1-Cheng1.jiang@intel.com> <046d515b-2c69-0f99-d97e-c2342512540c@redhat.com> From: Maxime Coquelin Message-ID: <956ba30b-7b99-1bc8-6c2d-20a6e65d576e@redhat.com> Date: Wed, 3 Feb 2021 15:21:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=maxime.coquelin@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3] examples/vhost: remove async inflight packet counter X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 2/3/21 2:42 PM, Jiang, Cheng1 wrote: > > >> -----Original Message----- >> From: Maxime Coquelin >> Sent: Wednesday, February 3, 2021 8:55 PM >> To: Jiang, Cheng1 ; Xia, Chenbo >> >> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX >> ; Wang, Yinan >> Subject: Re: [PATCH v3] examples/vhost: remove async inflight packet >> counter >> >> >> >> On 2/3/21 1:11 PM, Jiang, Cheng1 wrote: >>> Hi, >>> >>>> -----Original Message----- >>>> From: Maxime Coquelin >>>> Sent: Wednesday, February 3, 2021 5:52 PM >>>> To: Jiang, Cheng1 ; Xia, Chenbo >>>> >>>> Cc: dev@dpdk.org; Hu, Jiayu ; Yang, YvonneX >>>> ; Wang, Yinan >>>> Subject: Re: [PATCH v3] examples/vhost: remove async inflight packet >>>> counter >>>> >>>> >>>> >>>> On 2/2/21 7:17 AM, Cheng Jiang wrote: >>>>> Remove async inflight packet counter since there is no need to keep >>>>> tracking it. Increase MAX_ENQUEUED_SIZE to prevent packet segment >>>>> number tracking ring from being exhausted. >>>> >>>> Is that an optimization or a fix? >>>> >>>> If the former, let's move it to v21.05. >>>> >>> >>> I think it's a fix since there is no need to keep the inflight packet counter, >> sorry I forget adding the fixes, I can submit a v4 to fix it. >> OK >>>>> >>>>> Fixes: a68ba8e0a6b6 ("examples/vhost: refactor vhost data path") > > Oh, I got fixes here, sorry for the miss. > >>>>> >>>>> Signed-off-by: Cheng Jiang >>>>> --- >>>>> v3: fixed fixes commit id in git log >>>>> >>>>> v2: fixed a typo >>>>> >>>>> examples/vhost/ioat.h | 2 +- >>>>> examples/vhost/main.c | 10 +--------- examples/vhost/main.h | 1 - >>>>> 3 files changed, 2 insertions(+), 11 deletions(-) >>>>> >>>>> diff --git a/examples/vhost/ioat.h b/examples/vhost/ioat.h index >>>>> 0a1dbb811..1aa28ed6a 100644 >>>>> --- a/examples/vhost/ioat.h >>>>> +++ b/examples/vhost/ioat.h >>>>> @@ -11,7 +11,7 @@ >>>>> >>>>> #define MAX_VHOST_DEVICE 1024 >>>>> #define IOAT_RING_SIZE 4096 >>>>> -#define MAX_ENQUEUED_SIZE 512 >>>>> +#define It might be further simplified then 4096 >>>> >>>> Basically, this the size of the ring size, correct? >>>> It might be further simplified then. >>>> >>> >>> Yes, it's a the size of packet tracking ring, and it should be no less then >> IOAT_RING_SIZE for some corner cases. >>> I'm not sure I understand what you mean by saying It might be further >> simplified then. >> >> I meant maybe in this case just use IOAT_RING_SIZE? > > I have thought about it before I use MAX_ENQUEUED_SIZE. > But actually MAX_ENQUEUED_SIZE is used to for packet tracking ring, and IOAT_RING_SIZE is for ioat ring. > Using IOAT_RING_SIZE for packet tracking ring, I think maybe it's not so logical and a little bit confusing. What do you think? OK, let's keep it as is then. Thanks, Maxime > Thanks, > Cheng > >> >>> Thanks, >>> Cheng >>> >>>>> >>>>> struct dma_info { >>>>> struct rte_pci_addr addr; >>>>> diff --git a/examples/vhost/main.c b/examples/vhost/main.c index >>>>> e74fc8750..ca73e7086 100644 >>>>> --- a/examples/vhost/main.c >>>>> +++ b/examples/vhost/main.c >>>>> @@ -831,11 +831,8 @@ complete_async_pkts(struct vhost_dev *vdev) >>>>> >>>>> complete_count = rte_vhost_poll_enqueue_completed(vdev->vid, >>>>> VIRTIO_RXQ, p_cpl, >>>> MAX_PKT_BURST); >>>>> - if (complete_count) { >>>>> - __atomic_sub_fetch(&vdev->nr_async_pkts, >>>> complete_count, >>>>> - __ATOMIC_SEQ_CST); >>>>> + if (complete_count) >>>>> free_pkts(p_cpl, complete_count); >>>>> - } >>>>> } >>>>> >>>>> static __rte_always_inline void >>>>> @@ -878,8 +875,6 @@ drain_vhost(struct vhost_dev *vdev) >>>>> complete_async_pkts(vdev); >>>>> ret = rte_vhost_submit_enqueue_burst(vdev->vid, >>>> VIRTIO_RXQ, >>>>> m, nr_xmit, m_cpu_cpl, >>>> &cpu_cpl_nr); >>>>> - __atomic_add_fetch(&vdev->nr_async_pkts, ret - >>>> cpu_cpl_nr, >>>>> - __ATOMIC_SEQ_CST); >>>>> >>>>> if (cpu_cpl_nr) >>>>> free_pkts(m_cpu_cpl, cpu_cpl_nr); @@ -1210,9 >> +1205,6 @@ >>>>> drain_eth_rx(struct vhost_dev *vdev) >>>>> enqueue_count = rte_vhost_submit_enqueue_burst(vdev- >>>>> vid, >>>>> VIRTIO_RXQ, pkts, rx_count, >>>>> m_cpu_cpl, &cpu_cpl_nr); >>>>> - __atomic_add_fetch(&vdev->nr_async_pkts, >>>>> - enqueue_count - cpu_cpl_nr, >>>>> - __ATOMIC_SEQ_CST); >>>>> if (cpu_cpl_nr) >>>>> free_pkts(m_cpu_cpl, cpu_cpl_nr); >>>>> >>>>> diff --git a/examples/vhost/main.h b/examples/vhost/main.h index >>>>> 2d6c05fd7..0ccdce4b4 100644 >>>>> --- a/examples/vhost/main.h >>>>> +++ b/examples/vhost/main.h >>>>> @@ -51,7 +51,6 @@ struct vhost_dev { >>>>> uint64_t features; >>>>> size_t hdr_len; >>>>> uint16_t nr_vrings; >>>>> - uint64_t nr_async_pkts; >>>>> struct rte_vhost_memory *mem; >>>>> struct device_statistics stats; >>>>> TAILQ_ENTRY(vhost_dev) global_vdev_entry; >>>>> -- >>>>> 2.29.2 >>>>> >>> >