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 E21BAA0032 for ; Mon, 18 Jul 2022 15:44:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7BBA640698; Mon, 18 Jul 2022 15:44:56 +0200 (CEST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2066.outbound.protection.outlook.com [40.107.94.66]) by mails.dpdk.org (Postfix) with ESMTP id CF83340041 for ; Mon, 18 Jul 2022 15:44:53 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VVxRyzmn1KpJ8BB89bPTLGl8cyjEb9b62OdVeYHa95DhiyBAUVEnfDHJuJyaVOM7LU3oFuXI23FgeB5tSoRebodm2VsBonTVWY3kZczRT1PHWgTLauqgWUjH2RNvBt/BmAc817beKtE5deg34lafR82WlUpkqXLKyS2v7fIt48SWO3hqyq3kIome4EropgKpv6nFoyE0Fl2+jMr6bhegI6zzFAZHnO8pMjL1CjQMGXn06jgfQ3NN26cQv3XfxCKOwhL6lbncIEk43/GB/+oDdyvD1UDnbLRt4uaskQuvkCHSJiWJB+mT3WxAJKGbyA2YjTMpadYRv1fBkthHgGzvAQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9JnB5F5erYUiITC+rn8qN79Z+HF5/5595oZ74lvEHp4=; b=oZVzpQzeWd2sxc85Vqw4U+BE+xtoSeIdi2qSRXYrvi0tKEubK0GiuLGXbTCW2fn2idvkyIsqdk3yEr8c5QkHoSike4/nn80ZJ2hFHBQtXEU7m6lRe6hUsLlIbWNf7djAExhUA002g/vUleb/ou8IRAQqrhsC01EnO2p4K/VtEApxnomh9ew0kucIt4pKulnxFq7f9+i6RkDdjgiNu6S5dgfkS4UMFsXTJyXYWaJG9sjmpG1bByuefhIFl2P4O+Sxk+717rDmN3p0C6LboXM0wT+2/Z23rJutBbvbgmWUpOh3ArsIYf8/4caz9Aux+UGI6n5suRK1gXA3tz+Bq5IiyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9JnB5F5erYUiITC+rn8qN79Z+HF5/5595oZ74lvEHp4=; b=Po6jI9Nna8zrKBUQLgJix5DsEHZKSLORXkGBPY3C9IGCn1QnKjA8ppVCgTKysN+moCHYnkw5bvK3O+ekuu0dNjjxtPCDYQZPIjmMHYO34O87aF6oSZIE+jU7l13RPLMT3VNdOUJMo7ah7hCAFVAgn3E29v0Gijfzz7CnTW8/w74= Received: from MN2PR12MB3085.namprd12.prod.outlook.com (2603:10b6:208:c5::29) by DM5PR1201MB0123.namprd12.prod.outlook.com (2603:10b6:4:50::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5438.22; Mon, 18 Jul 2022 13:44:51 +0000 Received: from MN2PR12MB3085.namprd12.prod.outlook.com ([fe80::40f6:2711:14a1:ff16]) by MN2PR12MB3085.namprd12.prod.outlook.com ([fe80::40f6:2711:14a1:ff16%6]) with mapi id 15.20.5438.023; Mon, 18 Jul 2022 13:44:51 +0000 From: "Varghese, Vipin" To: Usman Tanveer CC: "users@dpdk.org" Subject: RE: Packet Accumulation in RX and TX in bnx2x (Usman Tanveer) Thread-Topic: Packet Accumulation in RX and TX in bnx2x (Usman Tanveer) Thread-Index: AdiY1jZ6khpevQwwSmCFnMz7cQ4o/QBumh0AAAbiCdA= Date: Mon, 18 Jul 2022 13:44:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_d4243a53-6221-4f75-8154-e4b33a5707a1_Enabled=true; MSIP_Label_d4243a53-6221-4f75-8154-e4b33a5707a1_SetDate=2022-07-18T13:42:05Z; MSIP_Label_d4243a53-6221-4f75-8154-e4b33a5707a1_Method=Privileged; MSIP_Label_d4243a53-6221-4f75-8154-e4b33a5707a1_Name=Public-AIP 2.0; MSIP_Label_d4243a53-6221-4f75-8154-e4b33a5707a1_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d; MSIP_Label_d4243a53-6221-4f75-8154-e4b33a5707a1_ActionId=b8c7bdb0-3090-4f9e-aa26-7ae622323ded; MSIP_Label_d4243a53-6221-4f75-8154-e4b33a5707a1_ContentBits=1 msip_label_d4243a53-6221-4f75-8154-e4b33a5707a1_enabled: true msip_label_d4243a53-6221-4f75-8154-e4b33a5707a1_setdate: 2022-07-18T13:44:47Z msip_label_d4243a53-6221-4f75-8154-e4b33a5707a1_method: Privileged msip_label_d4243a53-6221-4f75-8154-e4b33a5707a1_name: Public-AIP 2.0 msip_label_d4243a53-6221-4f75-8154-e4b33a5707a1_siteid: 3dd8961f-e488-4e60-8e11-a82d994e183d msip_label_d4243a53-6221-4f75-8154-e4b33a5707a1_actionid: 124ffa62-2b90-4e20-9e16-f51624402bdc msip_label_d4243a53-6221-4f75-8154-e4b33a5707a1_contentbits: 0 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0f7b3014-c289-47f8-84cc-08da68c3b047 x-ms-traffictypediagnostic: DM5PR1201MB0123:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0R/Kn1EHqppiFQIGMOgVgJkD8C6klVKmX1Hrxv0rix+eNxXEbw5Zb0z9Tum8/ooyHSOdECHLTufA+mATYpyegTIftrrCHZ+6HxW111n6jrsZYCrH4CEdR5DaxvHjsh5G12IHoy0iTdfx6hLq6wX5KFjgzAz9MVrNiTJbGFtS5j3HJYYR53qP8NnnZIYLOmPs0bk5r+2bTBKBhBPtqu9fxyETlNX2YNI9Vfpbrg6pfM9oP8IoQ9c0mb8EauYuDJ7Z2hMpWA7PRafjVnvTrUhZW5ZPlL4GCQiszxWKBUkX0XDJLtQk06XPdVLfv8teBbLv1bqC3CHzzB2S1U1bSQaGO5uVdkGA782CNwCjJ7Lt5DeRt7fUxMRarT4biSLW223seC4S+cpV5zeaeEihgwjaaC9AYL6PmI1393XFbXMFsmbh6SPa0dRu6L5+h2G0rSNcb2/1TopZH1hFjmKasnh79bM+RDdmb6NxF6E/TMdGo9CCHkVhp+DIW4noHp3jctKUFycsgkmcGcohMunOZH0FpDoo4Fp3M8uTfnhyZUsR30x2DtwkLT5nowAkWiAeuSXlt2j4U14mhaWA4LtGmeB2C4iYGnRAyMm6BMRi/TPI5jOpGQ8xVn+omP1O0j/cImLokFNDY/pxdez1dnHJgtrt2LNZVmcv5IotQ250HvwVTcDnxTFD0Gw2oEzB/PysGhInuAQjSunrBIR++UEBWfq2mBcIqLSeRhX25cQ/XTvIlF/YPM1MSAhax1aCR0M2zPymzB6ExAwTtEhOWz9enUNyTPvynacL5Du0zY2wCEw/f9CFgI0ofy+NGo90lqwrBSiM966z5Nhhz5mi85xMMs/9js+OIzfVtlkw3+4NwbpiG6Q= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR12MB3085.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(366004)(39860400002)(136003)(346002)(376002)(396003)(53546011)(55236004)(966005)(478600001)(8676002)(6506007)(9686003)(41300700001)(6916009)(86362001)(26005)(7696005)(316002)(45080400002)(71200400001)(122000001)(38070700005)(66556008)(166002)(38100700002)(66946007)(186003)(66446008)(83380400001)(33656002)(2906002)(5660300002)(55016003)(76116006)(8936002)(4326008)(66476007)(64756008)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?7DilPYpXf6nscTeDhMvRHOlKTRMxkLvZliQhVsDl3n6IKQFH4V/JBcQllSRK?= =?us-ascii?Q?HZ1aOANUuUC2LFjEHW1GZmNxRHwcAeBX6v91qPLBNEy8jPRMbLsC19Q8AMij?= =?us-ascii?Q?di/Rzxe5CdafvD9zXnZpTZhdjTqQ/eCFiy/++/xggrEY0bcxFomidxpbcmLm?= =?us-ascii?Q?GLEIPsTaQTDlq8oC2n3AVLZVb9LG5aWioF3MRjYh5E6NsCC+MJdzM3nVHtGq?= =?us-ascii?Q?6+tGxUEMmmKXoN7VtWSUsKcfnD7rfXFiq8n3Zepf0la2L4Fc5ivSvTFMp9PS?= =?us-ascii?Q?a80Eq+lOT0qQuxwHjncDVJxK0oEfVyLc4GJQleUx+I5FWmcYxlJGuyj37aUa?= =?us-ascii?Q?RV/xomu+IDIZ1g2yrWrPqyB4/7v31B4+glPpPxtm29OlePCM4PlkR0tahO00?= =?us-ascii?Q?W4lKL68ALrw2BkGu9R91Zrf5wjL9PhwPjK5QY6E1zQ6mp3Xg82HlPXz+xDb+?= =?us-ascii?Q?6I94ymLew7NfA+iaSsAHaxeN/beQxCpuC2PRG7FwGv4gdcyGXQQXglKyYKnW?= =?us-ascii?Q?hQja6J1yxuZbbvOICIgHtbdJikQQ7vjhf2JvVVwmMRMp0fh/glJhjMA1jA+p?= =?us-ascii?Q?bYXp5pF8MyHwVzMpv6RVAxBwfZBhq07SycGOTc+wxs6EN7LuzPo/t/NemtM4?= =?us-ascii?Q?cIOGgtY+ifemH0FiZvWwr45zAJ5nu6tw3louP4N0Gq39bzxW7i5ZR7EnuPBR?= =?us-ascii?Q?i+E6hG94aQi+nzRo9MQpWmw0E0H9gvQmrdyLn8dNYNoNuZXgfZgAX+6/5k9F?= =?us-ascii?Q?iaeVqAu+Vcc2ZNeyV5sVP6gTtHvVElsxbvuBUEBHq+y52d5xT+q6DgSeCkMA?= =?us-ascii?Q?Hyxlmuoue0XcJzprzSQacSGWvfjmtNEMMtiV340PwkR75UZkdx3S6FmoiJOZ?= =?us-ascii?Q?jiaFU2Z5CBu5ClykaA3oO7FpLKcLe51iQv/FC7ZARyS7i32joeVSj9yWtS0k?= =?us-ascii?Q?B5s3DLzCGTbzqHIWo62C0e8QLwDRbRAcTvGbc/ZN8yDtLT4ybZxcNFLlrkvV?= =?us-ascii?Q?xMCMV/pkHSdfUcT7uX/wkAZfaVxY2gtA2VHFJernu06te1+flX1s4EnOeW1T?= =?us-ascii?Q?suBeDYB+DLcPlpQW9cyBK42YrnrXNDn0o0d+f554A/SV87bdTV2HfV+8HOaA?= =?us-ascii?Q?HgKl2MVYSXyD9DqG+I0GSz/mIfBQEev6xNIKFE87v7AjOqvR/7DkgvDnvfjS?= =?us-ascii?Q?i4cP7wZa/Luuq7Or876qmpGWAzxF8BnqEGMkypTEnekheY0I49UhwONfTy0E?= =?us-ascii?Q?6Po0wfyBA9AcN6HcwU01jlQ0bCWraMS9PgaieDN6GmSZVjIkVg5g/13EKLh2?= =?us-ascii?Q?HaehGDjHMby8fZJmxcXymMFEJwLCbU0BRyJERsgEV+YQkD0AlLC+lmrOGXPR?= =?us-ascii?Q?VynshucUY4rS5QI9D3ngoSZZGACrF0crlTXoI7AqZ/XVe6QFYBevNq9+u82J?= =?us-ascii?Q?H+x1Ap2ZXGMOcPm23uZvpc3WV7bTRXNLGSrY60KuwRHfgsnEc1NsYTL7KHhw?= =?us-ascii?Q?CdxAYGgZs4waUlBYvlmpDeBOCn/014ZdBH92Q/kABLCltqT6O5k1MhoaViT1?= =?us-ascii?Q?guuG2jTnUKx93ccAbrGPsW1I7Z02xcEUavbcgGod?= Content-Type: multipart/alternative; boundary="_000_MN2PR12MB30851B6884D49BF184EC7420828C9MN2PR12MB3085namp_" MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB3085.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f7b3014-c289-47f8-84cc-08da68c3b047 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2022 13:44:51.1110 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GHIeFofV9G8Y4WuDSFYVTd5LbAP00evHruHq2hseNGTqXW1knygnJrjlmsDlweIi8PSoKTIoHFLdpV95cGoUAw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1201MB0123 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --_000_MN2PR12MB30851B6884D49BF184EC7420828C9MN2PR12MB3085namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Public] As pointed out application vice skeleton is better than l2fwd as it uses tx= _burst over tx_buffer. With respect to NIC you will need to investigate how= the PMD driver supports low latency (1 RX burst) and which firmware to use= . Note: 1. Based on my internal testing done I do find tx_buffer vs tx_buffer diffe= rent. 2. Intel E810 does support low_latency mode via PMD args From: Usman Tanveer Sent: Monday, July 18, 2022 3:55 PM To: Varghese, Vipin Cc: users@dpdk.org Subject: Re: Packet Accumulation in RX and TX in bnx2x (Usman Tanveer) [CAUTION: External Email] DPDK example L@FWD uses TX_BUFFER, which internally accumulates `n` packets= then send to device to amortize the cost. So my suggestion is not to use D= PDK L2fwd for latency test. Instead make use of DPDK example SKELETON which= directly uses `tx_burst`. I have tried SKELETON with BURST_SIZE =3D 1, it also shows the same behavio= r i.e. packets are being accumulated. On Sat, Jul 16, 2022 at 10:39 AM Varghese, Vipin > wrote: [AMD Official Use Only - General] DPDK example L@FWD uses TX_BUFFER, which internally accumulates `n` packets= then send to device to amortize the cost. So my suggestion is not to use D= PDK L2fwd for latency test. Instead make use of DPDK example SKELETON which= directly uses `tx_burst`. > -----Original Message----- > From: users-request@dpdk.org > > Sent: Friday, July 15, 2022 3:30 PM > To: users@dpdk.org > Subject: users Digest, Vol 347, Issue 13 > > [CAUTION: External Email] > > Send users mailing list submissions to > users@dpdk.org > > To subscribe or unsubscribe via the World Wide Web, visit > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmails= .dp > dk.org%2Flistinfo%2Fusers&data=3D05%7C01%7Cvipin.v= arghese%40amd.co > m%7Cbe1da1e5c9884d626f9f08da6648ca0f%7C3dd8961fe4884e608e11a82d99 > 4e183d%7C0%7C0%7C637934760074138757%7CUnknown%7CTWFpbGZsb3d8e > yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > 7C3000%7C%7C%7C&sdata=3DmF6VDr1GkGr3L13V7aplaxY58dHXpvdxcmqjj > a%2Ba3kQ%3D&reserved=3D0 > or, via email, send a message with subject or body 'help' to > users-request@dpdk.org > > You can reach the person managing the list at > users-owner@dpdk.org > > When replying, please edit your Subject line so it is more specific than = "Re: > Contents of users digest..." > > > Today's Topics: > > 1. Packet Accumulation in RX and TX in bnx2x (Usman Tanveer) > 2. mlx5: Keeping packets with invalid CRC/FCS (Pfau, Johannes (ITIV)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 14 Jul 2022 16:39:54 +0500 > From: Usman Tanveer > > To: users@dpdk.org > Cc: shshaikh@marvell.com, rmody@marvell.com<= mailto:rmody@marvell.com> > Subject: Packet Accumulation in RX and TX in bnx2x > Message-ID: > 77rDV+n6crq14T=3Dp1h31Q@mail.gmail.com> > Content-Type: text/plain; charset=3D"utf-8" > > Hi, > > I have a *BroadCom NetXtreme II BCM57810 10 Gigabit *with a *bnx2x* > driver. > I was trying to measure the performance of the network card. I'm running > DPDK-L2FWD application to receive and send packets with MAX_PKT_BURST =3D > 1. > but I noticed that packets are being accumulated somewhere in bnx2x_rxtx. > There is some sort of batching/buffering happening in rxtx. So, the laten= cy of > the packets is increasing as they have to wait. > The first packet of the batch is received with the minimum latency and > incoming packets are received with the accumulated latency of the previou= s > packets. After a specific number of packets (6-7 packets), the same patte= rn > repeats i.e. a packet arrives with the minimum latency and incoming packe= ts > with accumulated latency until the specific number of packets arrives. I'= ve > copied the latency measured for some contiguous packets. > > I tried to explore bnx2x_recv_pkts() and bnx2x_xmit_pkts() in bnx2x_rxtx.= c, but > didn't get any clue why the packets were being accumulated. > > Sequence Latency (microseconds) > 4825105 9.37207 > 4825106 10.72168 > 4825107 15.06543 > 4825108 19.394043 > 4825109 22.665039 > 4825110 26.979004 > 4825111 8.74707 > 4825112 11.145996 > 4825113 14.439941 > 4825114 18.701172 > 4825115 23.082031 > 4825116 27.402832 > 4825117 9.164062 > 4825118 11.623047 > 4825119 15.944824 > 4825120 19.066406 > 4825121 23.589355 > 4825122 27.909668 > 4825123 9.701172 > 4825124 11.13916 > 4825125 15.489746 > 4825126 19.780762 > 4825127 23.111816 > 4825128 27.403809 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > dk.org%2Farchives%2Fusers%2Fattachments%2F20220714%2F6= 887b7b4%2Fatt > achment- > 0001.htm&data=3D05%7C01%7Cvipin.varghese%40amd.com%7Cbe1da1e5c > 9884d626f9f08da6648ca0f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C > 0%7C637934760074138757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C > %7C&sdata=3DICLtgULJ6%2BTmatMiSECKtf0HTESOyd25TOzkygF%2FUsA%3D > &reserved=3D0> > > ------------------------------ > > Message: 2 > Date: Thu, 14 Jul 2022 13:52:14 +0000 > From: "Pfau, Johannes (ITIV)" > > To: "users@dpdk.org" > > Subject: mlx5: Keeping packets with invalid CRC/FCS > Message-ID: > > Content-Type: text/plain; charset=3D"iso-8859-1" > > Hi all, > > We're currently developing a low-cost DAQ system to record high-bandwidth > data from FPGA systems. We're using DPDK with Mellanox Connect-X5 cards, > the drivers and DPDK installed from the standard RHEL 8 repositories. We > capture raw ethernet (no L3) on 1:1 links to the FPGA devices to avoid al= l > possible overhead. So far this setup works great, we can handle 100 Gbit/= s of > traffic even on a single core, but we can also distribute packets to mult= iple > cores depending on the ether type if required. > > To save a few more bits in the transmission, we'd like to avoid encoding = packet > counters into the data stream. In that case we have to make sure we never > miss any packets in recording though, even if the FCS is invalid. > There are two aspects involved, leading to two questions: > > First, we need to store the CRC as well so that we can detect the invalid= packets > later on in offline processing. Using RTE_ETH_RX_OFFLOAD_KEEP_CRC is > working fine, but it first confused me a lot: Both rte_pktmbuf_pkt_len an= d > rte_pktmbuf_data_len still report the length without CRC. If I just read = 4 bytes > more than announced in these functions, I can read the correct CRC. Is it > intentional that the 4 CRC bytes are not included in these counts? > > Second, and this is a larger issue: We also need to receive packets with = invalid > FCS. We don't really have a an idea how to actually inject packets with i= nvalid > FCS for testing, but from the documentation I assume the mlx5 driver in d= efault > setup would drop invalid packets? There was an mailing list discussing th= is for > intel NICS > (https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmail= s.dp > dk.org%2Farchives%2Fusers%2F2021- > June%2F005651.html&data=3D05%7C01%7Cvipin.varghese%40amd.com%7C > be1da1e5c9884d626f9f08da6648ca0f%7C3dd8961fe4884e608e11a82d994e183 > d%7C0%7C0%7C637934760074138757%7CUnknown%7CTWFpbGZsb3d8eyJWIjo > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 > %7C%7C%7C&sdata=3DcEDhuhV4g0v%2FueSMO7IL9BJBJwz8SFu0KWp5%2BT > Iycbw%3D&reserved=3D0), but I couldn't find anything for mlx5. Does > anybody know if the mlx5 driver also offers an option to keep invalid pac= kets? > > Best regards, > Johannes > > -- > Karlsruhe Institute of Technology (KIT) > Institut f?r Technik der Informationsverarbeitung (ITIV) > > M.Sc. Johannes Pfau > Research Associate > > Engesserstr. 5 > Building 30.10, Room 218.1 > 76131 Karlsruhe, Germany > > Phone: +49 721 608-41939 > E-mail: johannes.pfau@kit.edu > > > Registered office: > Kaiserstra?e 12, 76131 Karlsruhe, Germany > > > KIT ? The Research University in the Helmholtz Association > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 6301 bytes > Desc: not available > URL: > > dk.org%2Farchives%2Fusers%2Fattachments%2F20220714= %2Fd44db3e4%2Fatt > achment- > 0001.bin&data=3D05%7C01%7Cvipin.varghese%40amd.com%7Cbe1da1e5c9 > 884d626f9f08da6648ca0f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0 > %7C637934760074138757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7 > C&sdata=3DijZq%2FPvpK3lxu98pYyBLMUKberQqOz%2FPtBCZ7NJg9m8%3D& > amp;reserved=3D0> > > End of users Digest, Vol 347, Issue 13 > ************************************** --_000_MN2PR12MB30851B6884D49BF184EC7420828C9MN2PR12MB3085namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Public]

 

As pointed out application vice skeleton is better t= han l2fwd as it uses tx_burst over tx_buffer. With respect to NIC you will = need to investigate how the PMD driver supports low latency (1 RX burst) an= d which firmware to use.

 

Note:

1. Based on my internal testing done I do find tx_bu= ffer vs tx_buffer different.

2. Intel E810 does support low_latency mode via PMD = args

 

From: Usman Tanveer <usman.tanveer@emumba.= com>
Sent: Monday, July 18, 2022 3:55 PM
To: Varghese, Vipin <Vipin.Varghese@amd.com>
Cc: users@dpdk.org
Subject: Re: Packet Accumulation in RX and TX in bnx2x (Usman Tanvee= r)

 

[CAUTION: External Email]

DPDK example L@FWD uses TX_BUFFER, which internally = accumulates `n` packets then send to device to amortize the cost. So my sug= gestion is not to use DPDK L2fwd for latency test. Instead make use of DPDK= example SKELETON which directly uses `tx_burst`.

 

I have tried SKELETON with BURST_SIZE =3D 1, it also= shows the same behavior i.e. packets are being accumulated.

 

On Sat, Jul 16, 2022 at 10:39 AM Varghese, Vipin <= ;Vipin.Varghese@amd.com> w= rote:

[AMD Official Use Only - General]

DPDK example L@FWD uses TX_BUFFER, which internally accumulates `n` packets= then send to device to amortize the cost. So my suggestion is not to use D= PDK L2fwd for latency test. Instead make use of DPDK example SKELETON which= directly uses `tx_burst`.

> -----Original Message-----
> From: user= s-request@dpdk.org <users-request@dpdk.org>
> Sent: Friday, July 15, 2022 3:30 PM
> To: users@dpdk.org=
> Subject: users Digest, Vol 347, Issue 13
>
> [CAUTION: External Email]
>
> Send users mailing list submissions to
>         users@dpdk.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmails.d= p
> dk.org%2Flistinfo%2Fusers&amp;data=3D05%7C01%7Cvipin.varghese%40amd.co
> m%7Cbe1da1e5c9884d626f9f08da6648ca0f%7C3dd8961fe4884e608e11a82d99
> 4e183d%7C0%7C0%7C637934760074138757%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C3000%7C%7C%7C&amp;sdata=3DmF6VDr1GkGr3L13V7aplaxY58dHXpvdxcmqjj<= br> > a%2Ba3kQ%3D&amp;reserved=3D0
> or, via email, send a message with subject or body 'help' to
>         users-request@dpdk.org
>
> You can reach the person managing the list at
>         users-owner@dpdk.org
>
> When replying, please edit your Subject line so it is more specific th= an "Re:
> Contents of users digest..."
>
>
> Today's Topics:
>
>    1. Packet Accumulation in RX and TX in bnx2x (Usman Tanve= er)
>    2. mlx5: Keeping packets with invalid CRC/FCS (Pfau, Joha= nnes (ITIV))
>
>
> ----------------------------------------------------------------------=
>
> Message: 1
> Date: Thu, 14 Jul 2022 16:39:54 +0500
> From: Usman Tanveer <usman.tanveer@emumba.com>
> To: users@dpdk.org=
> Cc: shshaikh= @marvell.com, rmody@marvell.com
> Subject: Packet Accumulation in RX and TX in bnx2x
> Message-ID:
>         <CAH_O0bwKXL9pSq6k_dFS=3D-JsF1u_-<= br> > 77rDV+n6crq14T=3Dp1h31Q@mail.gmail.com>
> Content-Type: text/plain; charset=3D"utf-8"
>
> Hi,
>
> I have a *BroadCom NetXtreme II BCM57810 10 Gigabit *with a *bnx2x* > driver.
> I was trying to measure the performance of the network card. I'm runni= ng
> DPDK-L2FWD application to receive and send packets with MAX_PKT_BURST = =3D
> 1.
> but I noticed that packets are being accumulated somewhere in bnx2x_rx= tx.
> There is some sort of batching/buffering happening in rxtx. So, the la= tency of
> the packets is increasing as they have to wait.
> The first packet of the batch is received with the minimum latency and=
> incoming packets are received with the accumulated latency of the prev= ious
> packets. After a specific number of packets (6-7 packets), the same pa= ttern
> repeats i.e. a packet arrives with the minimum latency and incoming pa= ckets
> with accumulated latency until the specific number of packets arrives.= I've
> copied the latency measured for some contiguous packets.
>
> I tried to explore bnx2x_recv_pkts() and bnx2x_xmit_pkts() in bnx2x_rx= tx.c, but
> didn't get any clue why the packets were being accumulated.
>
> Sequence Latency (microseconds)
> 4825105 9.37207
> 4825106 10.72168
> 4825107 15.06543
> 4825108 19.394043
> 4825109 22.665039
> 4825110 26.979004
> 4825111 8.74707
> 4825112 11.145996
> 4825113 14.439941
> 4825114 18.701172
> 4825115 23.082031
> 4825116 27.402832
> 4825117 9.164062
> 4825118 11.623047
> 4825119 15.944824
> 4825120 19.066406
> 4825121 23.589355
> 4825122 27.909668
> 4825123 9.701172
> 4825124 11.13916
> 4825125 15.489746
> 4825126 19.780762
> 4825127 23.111816
> 4825128 27.403809
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <ht= tps://nam11.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fmails.dp
> dk.org%2Farchives%2Fusers%2Fattachments%2F20220714%2F6887b7b4%2Fatt
> achment-
> 0001.htm&amp;data=3D05%7C01%7Cvipin.varghese%40amd.com%7Cbe1da1e5c
> 9884d626f9f08da6648ca0f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C
> 0%7C637934760074138757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&amp;sdata=3DICLtgULJ6%2BTmatMiSECKtf0HTESOyd25TOzkygF%2FUsA%3D=
> &amp;reserved=3D0>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 14 Jul 2022 13:52:14 +0000
> From: "Pfau, Johannes (ITIV)" <johannes.pfau@kit.edu>
> To: "users@dp= dk.org" <us= ers@dpdk.org>
> Subject: mlx5: Keeping packets with invalid CRC/FCS
> Message-ID: <e0aacbdee7fa427ea2bf22dcb4f24c09@kit.edu> > Content-Type: text/plain; charset=3D"iso-8859-1"
>
> Hi all,
>
> We're currently developing a low-cost DAQ system to record high-bandwi= dth
> data from FPGA systems. We're using DPDK with Mellanox Connect-X5 card= s,
> the drivers and DPDK installed from the standard RHEL 8 repositories. = We
> capture raw ethernet (no L3) on 1:1 links to the FPGA devices to avoid= all
> possible overhead. So far this setup works great, we can handle 100 Gb= it/s of
> traffic even on a single core, but we can also distribute packets to m= ultiple
> cores depending on the ether type if required.
>
> To save a few more bits in the transmission, we'd like to avoid encodi= ng packet
> counters into the data stream. In that case we have to make sure we ne= ver
> miss any packets in recording though, even if the FCS is invalid.
> There are two aspects involved, leading to two questions:
>
> First, we need to store the CRC as well so that we can detect the inva= lid packets
> later on in offline processing. Using RTE_ETH_RX_OFFLOAD_KEEP_CRC is > working fine, but it first confused me a lot: Both rte_pktmbuf_pkt_len= and
> rte_pktmbuf_data_len still report the length without CRC. If I just re= ad 4 bytes
> more than announced in these functions, I can read the correct CRC. Is= it
> intentional that the 4 CRC bytes are not included in these counts?
>
> Second, and this is a larger issue: We also need to receive packets wi= th invalid
> FCS. We don't really have a an idea how to actually inject packets wit= h invalid
> FCS for testing, but from the documentation I assume the mlx5 driver i= n default
> setup would drop invalid packets? There was an mailing list discussing= this for
> intel NICS
> (http= s://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmails.dp
> dk.org%2Farchives%2Fusers%2F2021-
> June%2F005651.html&amp;data=3D05%7C01%7Cvipin.varghese%40amd.com%7C
> be1da1e5c9884d626f9f08da6648ca0f%7C3dd8961fe4884e608e11a82d994e183
> d%7C0%7C0%7C637934760074138757%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&amp;sdata=3DcEDhuhV4g0v%2FueSMO7IL9BJBJwz8SFu0KWp5%2BT > Iycbw%3D&amp;reserved=3D0), but I couldn't find anything for mlx5.= Does
> anybody know if the mlx5 driver also offers an option to keep invalid = packets?
>
> Best regards,
> Johannes
>
> --
> Karlsruhe Institute of Technology (KIT)
> Institut f?r Technik der Informationsverarbeitung (ITIV)
>
> M.Sc. Johannes Pfau
> Research Associate
>
> Engesserstr. 5
> Building 30.10, Room 218.1
> 76131 Karlsruhe, Germany
>
> Phone: +49 721 608-41939
> E-mail: joh= annes.pfau@kit.edu
>
>
> Registered office:
> Kaiserstra?e 12, 76131 Karlsruhe, Germany
>
>
> KIT ? The Research University in the Helmholtz Association
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 6301 bytes
> Desc: not available
> URL:
> <ht= tps://nam11.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fmails.dp
> dk.org%2Farchives%2Fusers%2Fattachments%2F20220714%2Fd44db3e4%2Fatt
> achment-
> 0001.bin&amp;data=3D05%7C01%7Cvipin.varghese%40amd.com%7Cbe1da1e5c9
> 884d626f9f08da6648ca0f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0
> %7C637934760074138757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> C&amp;sdata=3DijZq%2FPvpK3lxu98pYyBLMUKberQqOz%2FPtBCZ7NJg9m8%3D&a= mp;
> amp;reserved=3D0>
>
> End of users Digest, Vol 347, Issue 13
> **************************************

--_000_MN2PR12MB30851B6884D49BF184EC7420828C9MN2PR12MB3085namp_--