From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gowrishankar Subject: [PATCH v2] kni: add new mbuf in alloc_q only based on its empty slots Date: Thu, 11 May 2017 17:21:26 +0530 Message-ID: <1494503486-20876-1-git-send-email-gowrishankar.m@linux.vnet.ibm.com> References: <1494502172-16950-1-git-send-email-gowrishankar.m@linux.vnet.ibm.com> Cc: dev@dpdk.org, Gowrishankar Muthukrishnan To: Ferruh Yigit Return-path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by dpdk.org (Postfix) with ESMTP id A9C4C2952 for ; Thu, 11 May 2017 13:52:21 +0200 (CEST) Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4BBnXih088826 for ; Thu, 11 May 2017 07:52:20 -0400 Received: from e23smtp06.au.ibm.com (e23smtp06.au.ibm.com [202.81.31.148]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ac457msu1-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 11 May 2017 07:52:20 -0400 Received: from localhost by e23smtp06.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 11 May 2017 21:52:18 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay07.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v4BBq7LD6881720 for ; Thu, 11 May 2017 21:52:15 +1000 Received: from d23av01.au.ibm.com (localhost [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id v4BBpgB7009494 for ; Thu, 11 May 2017 21:51:42 +1000 In-Reply-To: <1494502172-16950-1-git-send-email-gowrishankar.m@linux.vnet.ibm.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Gowrishankar Muthukrishnan In kni_allocate_mbufs(), we attempt to add max_burst (32) count of mbuf always into alloc_q, which is excessively leading too many rte_pktmbuf_ free() when alloc_q is contending at high packet rate (for eg 10Gig data). In a situation when alloc_q fifo can only accommodate very few (or zero) mbuf, create only what needed and add in fifo. With this patch, we could stop random network stall in KNI at higher packet rate (eg 1G or 10G data between vEth0 and PMD) sufficiently exhausting alloc_q on above condition. I tested i40e PMD for this purpose in ppc64le. Changes: v2 - alloc_q free count calculation corrected. line wrap fixed for commit message. Signed-off-by: Gowrishankar Muthukrishnan --- lib/librte_kni/rte_kni.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c index c3f9208..9c5d485 100644 --- a/lib/librte_kni/rte_kni.c +++ b/lib/librte_kni/rte_kni.c @@ -624,6 +624,7 @@ struct rte_kni * int i, ret; struct rte_mbuf *pkts[MAX_MBUF_BURST_NUM]; void *phys[MAX_MBUF_BURST_NUM]; + int allocq_free; RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, pool) != offsetof(struct rte_kni_mbuf, pool)); @@ -646,7 +647,9 @@ struct rte_kni * return; } - for (i = 0; i < MAX_MBUF_BURST_NUM; i++) { + allocq_free = (kni->alloc_q->read - kni->alloc_q->write - 1) \ + & (MAX_MBUF_BURST_NUM - 1); + for (i = 0; i < allocq_free; i++) { pkts[i] = rte_pktmbuf_alloc(kni->pktmbuf_pool); if (unlikely(pkts[i] == NULL)) { /* Out of memory */ -- 1.9.1