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 3CD1DA0C50; Sat, 24 Jul 2021 08:32:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A892340DDA; Sat, 24 Jul 2021 08:32:10 +0200 (CEST) Received: from mx0b-00000d04.pphosted.com (mx0b-00000d04.pphosted.com [148.163.153.235]) by mails.dpdk.org (Postfix) with ESMTP id DE8F740041; Sat, 24 Jul 2021 08:32:09 +0200 (CEST) Received: from pps.filterd (m0102894.ppops.net [127.0.0.1]) by mx0a-00000d04.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16O6Eh78014267; Fri, 23 Jul 2021 23:32:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stanford.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=pps05272020; bh=xVWpdi33VtnGbrCC1DtKmKHmdOkTOv699CWM8RmhOPs=; b=BaP46b5gRuGgysnsVDQSkreIDf6TldZfJniOsISUQTMts1/IrZmLwkeLMVTwBqWMR+uK 1f1wdDo1AH5YsZfRr2n/6ceTmUAZumoDbbsAw0osIt0app6SKAfWDVVz3Q6mhkwKPckL tGtTUXKuBJA9sdjk2IaIAnxr3V43MYo2/r6cyHpImkeM52FfbqrNXeb3OoUsi6WVQfZb UeqNUKub8QQ/p1r/0A4um4ki64ib3fTpuURv2DF9fMaq0qp9h7CDRMIFaRGj4gju9VWM X0Vw9sRPQ9z9T3BhEzQdIiG3vfTXOvWv3pSzO1dCAPWfSdgPZnaLoBSHbDVXp6hf3Nsz sQ== Received: from mx0b-00000d03.pphosted.com (mx0b-00000d03.pphosted.com [148.163.153.234]) by mx0a-00000d04.pphosted.com with ESMTP id 39xptjwgj2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jul 2021 23:32:08 -0700 Received: from pps.filterd (m0206578.ppops.net [127.0.0.1]) by mx0a-00000d03.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16O6D7nl016165; Fri, 23 Jul 2021 23:32:08 -0700 Received: from mx0a-00000d06.pphosted.com (mx0a-00000d06.pphosted.com [148.163.135.119]) by mx0a-00000d03.pphosted.com with ESMTP id 39uwbxpd0n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jul 2021 23:32:08 -0700 Received: from pps.filterd (m0167935.ppops.net [127.0.0.1]) by mx0a-00000d06.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16O6W7cf018120; Fri, 23 Jul 2021 23:32:07 -0700 Received: from smtp.stanford.edu (smtp6.stanford.edu [171.67.219.73]) by mx0a-00000d06.pphosted.com with ESMTP id 39uujj8ety-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jul 2021 23:32:07 -0700 Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gerryw) by smtp.stanford.edu (Postfix) with ESMTPSA id ED02A445A7; Fri, 23 Jul 2021 23:32:06 -0700 (PDT) Received: by mail-il1-f182.google.com with SMTP id r5so3532351ilc.13; Fri, 23 Jul 2021 23:32:06 -0700 (PDT) X-Gm-Message-State: AOAM531lQf/5sUmUKIZdpfMKKCv4B1fnDgY1/NuXVGzvoqSeY+do7Hm5 giSHDSF4FhAXbRNMUdm3vl0S7p42sPWEcGsDigI= X-Google-Smtp-Source: ABdhPJwyvzZ5UFYQzGD6UpkLVOiQYVOChVlV8h2rdfT1dAch6pXcSUpndxrV3B/1RW6tdU0xCHiiMSq7bgAulyfAmbc= X-Received: by 2002:a05:6e02:5ad:: with SMTP id k13mr5764403ils.284.1627108326425; Fri, 23 Jul 2021 23:32:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gerry Wan Date: Fri, 23 Jul 2021 23:31:55 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Yaron Illouz Cc: Matan Azrad , "users@dpdk.org" , "dev@dpdk.org" x-proofpoint-stanford-dir: outbound X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-24_02:2021-07-23, 2021-07-24 signatures=0 X-Proofpoint-ORIG-GUID: JFvo-4U0w7XHAq4f4SqFhmIVuXLrd03u X-Proofpoint-GUID: JFvo-4U0w7XHAq4f4SqFhmIVuXLrd03u X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-24_02:2021-07-23, 2021-07-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 spamscore=0 mlxscore=0 bulkscore=0 phishscore=0 suspectscore=0 adultscore=100 clxscore=1011 priorityscore=1501 malwarescore=0 mlxlogscore=999 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107240039 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [dpdk-users] imissed drop with mellanox connectx5 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" My understanding of an increasing imissed counter is that it indicates your processing logic in the lcore is not fast enough to handle the rate of incoming packets, and is independent of the number of free mbufs. I would guess that using the pipeline model (passing mbufs between lcores via rings) involves some cross core communication that causes cache misses (as mentioned by Matan). A run-to-completion model may very well perform better, although it probably depends on your entire workflow. On Thu, Jul 22, 2021 at 3:34 AM Yaron Illouz wrote: > Hi Matan > > We work with mbuf in all threads and lcores, > We pass them from one thread to another through the dpdk ring before > releasing them. > There are drops in 10K to 100K pps, we can't stay with these drops. > > The drops are in the imissed counter from rte_eth_stats_get, so I thought > that the drops are at the port level and not drop at mempool level > From what I see number of mbuf in pool is stable( and close to the > total/original number of mbuf in pool), the rings are empty, Traffic is > well balanced between threads, All threads are running in pool from port > and from ring. > And from perf top profiler there doesn't seem to be any unexpected > function taking cpu. > > So the only possible architecture would be to implement all logic in the > threads that read from port, and to launch hundreds of threads in > multiqueue mode that read from port? I don't think this is a viable > solution ( In the following link for example they show an example of > application that pass packet from one core/thread to another > https://doc.dpdk.org/guides-16.04/sample_app_ug/qos_scheduler.html ) > > Thank you answer > > -----Original Message----- > From: Matan Azrad > Sent: Thursday, July 22, 2021 8:19 AM > To: Yaron Illouz ; users@dpdk.org > Cc: dev@dpdk.org > Subject: RE: imissed drop with mellanox connectx5 > > Hi Yaron > > Freeing mbufs from a different lcore than the original lcore allocated > them causes cache miss in the mempool cache of the original lcore per mbuf > allocation - all the time the PMD will get non-hot mbufs to work with. > > It can be one of the reasons for the earlier drops you see. > > Matan > > From: Yaron Illouz > > Hi > > > > We try to read from 100G NIC Mellanox ConnectX-5 without drop at nic. > > All thread are with core pinning and cpu isolation. > > We use dpdk 19.11 > > I tried to apply all configuration that are in > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffast > > .dpdk.org%2Fdoc%2Fperf%2FDPDK_19_08_Mellanox_NIC_performance_r&dat > > a=04%7C01%7C%7Cdcbb2d8246be4dc456c508d94cd038a7%7C0eb9e2d98763412e9709 > > 3f539e9e25bc%7C0%7C0%7C637625279453292671%7CUnknown%7CTWFpbGZsb3d8eyJW > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > > amp;sdata=KMBFyIMEFV4B0JqxQE%2BiMXJ2p9qE8lEOpUWRsFhD0gM%3D&reserve > > d=0 > > eport.pdf > > > > We have a strange behavior, 1 thread can receive receive 20 Gbps/12 > > Mpps and free mbuf without dropps, but when trying to pass these mbuf > > to another thread that only free them there are drops, even when > > trying to work with more threads. > > > > When running 1 thread that only read from port (no multi queue) and > > free mbuf in the same thread, there are no dropp with traffic up to 21 > > Gbps 12.4 Mpps. > > When running 6 thread that only read from port (with multi queue) and > > free mbuf in the same threads, there are no dropp with traffic up to > > 21 Gbps 12.4 Mpps. > > > > When running 1 to 6 thread that only read from port and pass them to > > another 6 thread that only read from ring and free mbuf, there are > > dropp in nic (imissed counter) with traffic over to 10 Gbps 5.2 > > Mpps.(Here receive thread were pinned to cpu 1-6 and additional thread > > from 7-12 each thread on a single cpu) Each receive thread send to one > thread that free the buffer. > > > > Configurations: > > > > We use rings of size 32768 between the threads. Ring are initialized > > with SP/SC, Write are done with bulk of 512 with rte_ring_enqueue_burst. > > Port is initialized with rte_eth_rx_queue_setup nb_rx_desc=8192 > > rte_eth_rxconf - rx_conf.rx_thresh.pthresh = DPDK_NIC_RX_PTHRESH; > > //ring prefetch threshold > > rx_conf.rx_thresh.hthresh = > > DPDK_NIC_RX_HTHRESH; //ring host threshold > > rx_conf.rx_thresh.wthresh = > > DPDK_NIC_RX_WTHRESH; //ring writeback threshold > > rx_conf.rx_free_thresh = > > DPDK_NIC_RX_FREE_THRESH; rss - > > > ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP; > > > > > > We tried to work with and without hyperthreading. > > > > **************************************** > > > > Network devices using kernel driver > > =================================== > > 0000:37:00.0 'MT27800 Family [ConnectX-5] 1017' if=ens2f0 > > drv=mlx5_core unused=igb_uio > > 0000:37:00.1 'MT27800 Family [ConnectX-5] 1017' if=ens2f1 > > drv=mlx5_core unused=igb_uio > > > > **************************************** > > > > ethtool -i ens2f0 > > driver: mlx5_core > > version: 5.3-1.0.0 > > firmware-version: 16.30.1004 (HPE0000000009) > > expansion-rom-version: > > bus-info: 0000:37:00.0 > > supports-statistics: yes > > supports-test: yes > > supports-eeprom-access: no > > supports-register-dump: no > > supports-priv-flags: yes > > > > **************************************** > > > > uname -a > > Linux localhost.localdomain 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 > > 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux > > > > **************************************** > > > > lscpu | grep -e Socket -e Core -e Thread > > Thread(s) per core: 1 > > Core(s) per socket: 24 > > Socket(s): 2 > > > > **************************************** > > cat /sys/devices/system/node/node0/cpulist > > 0-23 > > **************************************** > > From /proc/cpuinfo > > > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 85 > > model name : Intel(R) Xeon(R) Gold 5220R CPU @ 2.20GHz > > stepping : 7 > > microcode : 0x5003003 > > cpu MHz : 2200.000 > > > > **************************************** > > > > python /home/cpu_layout.py > > ========================================================== > > ============ > > Core and Socket Information (as reported by '/sys/devices/system/cpu') > > ========================================================== > > ============ > > > > cores = [0, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 16, 17, 18, 19, > > 20, 21, 25, 26, 27, 28, 29, 24] sockets = [0, 1] > > > > Socket 0 Socket 1 > > -------- -------- > > Core 0 [0] [24] > > Core 1 [1] [25] > > Core 2 [2] [26] > > Core 3 [3] [27] > > Core 4 [4] [28] > > Core 5 [5] [29] > > Core 6 [6] [30] > > Core 8 [7] > > Core 9 [8] [31] > > Core 10 [9] [32] > > Core 11 [10] [33] > > Core 12 [11] [34] > > Core 13 [12] [35] > > Core 16 [13] [36] > > Core 17 [14] [37] > > Core 18 [15] [38] > > Core 19 [16] [39] > > Core 20 [17] [40] > > Core 21 [18] [41] > > Core 25 [19] [43] > > Core 26 [20] [44] > > Core 27 [21] [45] > > Core 28 [22] [46] > > Core 29 [23] [47] > > Core 24 [42] >