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 C1531A00C4 for ; Sat, 16 Jul 2022 07:39:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 585A940141; Sat, 16 Jul 2022 07:39:45 +0200 (CEST) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2062.outbound.protection.outlook.com [40.107.102.62]) by mails.dpdk.org (Postfix) with ESMTP id 278B5400D7 for ; Sat, 16 Jul 2022 07:39:43 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GUtjZPUdPqWZYdGw1Oaescu4UYgFMdi/EoO7AjN8nOsiqkI+WCl/0NqPw2kI5zjqQQZuzfc4v0NXHeypcx6uJgHTbp2VhDY58WZRlPFVjHHQ5J2fmBTkC0DjuXrzXE93HViTrS5VVuP5sL7Ob8OPFc4svDke9IbeR5n0VtuC4RHe4gjwoTgGtc+xIkDqVKSVvJfGzJ1DBzzGtY9obGQwWLEuBm5hNT3plwAmpx4OP0WMD904o5aA+lK+0q/A7R2YqA0Y2ynyHx4pZ616xzn6IjYCvRhcjL+XDVwtTOuxU6RxjgT7xs+cyEWhk0YooHinr/Csgjgrgwt+dbTXAOc/sA== 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=zdfcIHZazpgQOk2s1HHYq1+KeNqhwAzxbNLmsD+fkgo=; b=Y+1Xi09CWLeo4t5vfgwb0zQPSTxRnvrpjvOvdM5NMlx7AhqULBUyDuIdEVOvyjYVf+8IwU03QxN9lKgctF7rZJOvKRQk7tUKllMGPqo2Ghkwzk/8W70CZpw6ftkxEDQUtyn8DMx05QzOOEa/1FgfonTGlfqB8Mnzyf3lmJlt/rb4F3tGc04Obtp/+/MQ0N8hGG/2F+vtFntp22fBUOd5X4TYWa+m5A6oM3sbax7KE/DKoLucRjt9x/p5RohBedKmExkJtjMXdCyEr6hazQm/+G36dAzf1HgjNdEU6bpr0y/DH1SRlUOyZA0hProRYtR/DJ+bExZ1wUgSZnqUNsPIMw== 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=zdfcIHZazpgQOk2s1HHYq1+KeNqhwAzxbNLmsD+fkgo=; b=ICMfbtnT5f9Ca9/uRA9uPAptnkX24hAE1UiX63jhlMISwmKaCWYyc76d3R/rpjlywh+BKNBTOPhkXPpeK5qB2htj4oo5TSOnCrGt2odCJK1lAnKNFFOh/vAcfTWRnG39pT9aqI1m2iETOCgXsCYbX5Nb5gdh7HgW9yeSWhxrJv8= Received: from MN2PR12MB3085.namprd12.prod.outlook.com (2603:10b6:208:c5::29) by DM6PR12MB3625.namprd12.prod.outlook.com (2603:10b6:5:116::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5438.14; Sat, 16 Jul 2022 05:39:37 +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.5417.026; Sat, 16 Jul 2022 05:39:37 +0000 From: "Varghese, Vipin" To: "users@dpdk.org" , "usman.tanveer@emumba.com" Subject: 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/Q== Date: Sat, 16 Jul 2022 05:39:37 +0000 Message-ID: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Enabled=true; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_SetDate=2022-07-16T05:39:33Z; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Method=Standard; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_Name=General; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_ActionId=b7c20d41-3e48-4637-8ec9-6816c7dc3005; MSIP_Label_4342314e-0df4-4b58-84bf-38bed6170a0f_ContentBits=1 msip_label_4342314e-0df4-4b58-84bf-38bed6170a0f_enabled: true msip_label_4342314e-0df4-4b58-84bf-38bed6170a0f_setdate: 2022-07-16T05:39:33Z msip_label_4342314e-0df4-4b58-84bf-38bed6170a0f_method: Standard msip_label_4342314e-0df4-4b58-84bf-38bed6170a0f_name: General msip_label_4342314e-0df4-4b58-84bf-38bed6170a0f_siteid: 3dd8961f-e488-4e60-8e11-a82d994e183d msip_label_4342314e-0df4-4b58-84bf-38bed6170a0f_actionid: f7b95ecd-f7f0-4835-acc0-1cb6e77567fe msip_label_4342314e-0df4-4b58-84bf-38bed6170a0f_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: 7c1a6330-6527-4069-62b7-08da66ed926a x-ms-traffictypediagnostic: DM6PR12MB3625:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZhqZ2JB8Nd2W8kkqS9eBkguBrpDE03JBkKSiwduJ2vO6sWLXcVgwxuvXSt8Bub9zqxhHp8/fMgZ+zcEGjZxD+wA7F+6RRYgIdg+F0qXPv+ZKXb51FnWFA8LKPRkKoPs2P+jTgnhOCDpcvtKjiKoarksMGbc3mpX+7p38k/psj6rxteEAi1+aleDEsjZFAkCnoVLqhlSWAdQBKtkjTigp3uOSZHRjzJJ9pTL0Kittwnn2U4KEUzjZQEXS/9h7XUJ2XT2VJPHOIzWocCj6XnaJYwhumAQ/1pQGCi/AkKgCSEVUIldfnBVKMK+7UZDSOJRrJh5alP6k67//jbjY6M6cXnzw48YOsgkB5Gyz8hn8qGIBFgmPWsUpMQaa7MhBLfQ1fsoIHNuoVZ6EHIAHvBpbKZAkBxrjVeLUbltgMxn5UMSBNI9PClFOKhJQU8Nx+upUay8XnKdbomyH60ZmAzSjWu5JIaQqgdbxjn3MZudTSawpy6Tb0muNKnNStiqsUqgmK/B7/aud0dUR+Wnv28VRzMN49OGXIyhR2kRqVsz1PztZ/TIFAltEaQLrxifUxlNC2VygPqKPxOxUdJ2CPMRevi84BofHP8sz/ovUEnrd8Kvoj7/ARiVc5Rdwo1XUbVFRfrpoapWK+WmBAtB9FyFJOAdaYaOQNP0S4PB1feV/tmEyVhtuTOXnXG32SVeNMkR3MkAyoIXmN5XW7X6xj7j2WF43jUTc3ngvcZcli1lkVJbNhJ4vg400G1Ijyc0SX9Xn6u+e9PizHs942QEKVkQYDQZ9ci3AR/J/iUoxBil8vekI73//ccGq6ar6BgpKiEzomeftCNWATddfTs4FvcEqzs6T9iyOUeH6o674ewsoNKA= 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)(136003)(39860400002)(366004)(396003)(376002)(346002)(38100700002)(6506007)(110136005)(2906002)(7696005)(966005)(41300700001)(53546011)(38070700005)(26005)(55236004)(83380400001)(478600001)(66446008)(71200400001)(186003)(52536014)(8676002)(316002)(55016003)(86362001)(76116006)(33656002)(66476007)(66556008)(9686003)(45080400002)(66946007)(64756008)(5660300002)(8936002)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?papiYsbbhDyPuUwJiQvqvUSPd3XMKstGXCJ1WaH478a1LAgF+nGSGQ5Pylzx?= =?us-ascii?Q?k2bmReQkhdhZ1erupKEfpuOspvPZVmEl+1DqAhQW/kwsFrqM9o2QYHnL/pS2?= =?us-ascii?Q?1xjoivQMSPKuF6mXusLC4/5uKivbWWOmn3qhVgasoahBFhRsWS7Y/4/DX4D3?= =?us-ascii?Q?czK0SdcHXYBhlzMFyCnR8PA/ePuKF73d55rUxuJGvc7g6QTBohz6841fR1/l?= =?us-ascii?Q?jEiA7Hz98/MdvCyarVT1dEXxK0R9uFqFmUF1+w/xqw78zmQ3lxTS8JytOEyq?= =?us-ascii?Q?LISAf2rLoOfpJiQEIAa/CG++zAYbQKssUTYo9VpKxSarelbOoK7gOMRKdyMf?= =?us-ascii?Q?2nN8UN41gmy9WvAAQTH8+MlggyjpGlbsNuN3GonkjW1KJFYKQarqqQdvRak+?= =?us-ascii?Q?l9wVEEDoNmb632RcfdBugyTIfpQtZpfJi8Jfg2ihUbg/TlrA5DeKG0nqcL/s?= =?us-ascii?Q?UyhI7dstRVyvzY39/x84XsVUNIvncZryMlmyRzQdvrFI8U8Fl91OlYS2fGnB?= =?us-ascii?Q?/hBssg30u5R8Do7u0L8iyJ9ycidgrZcuDwNWrb24T2bMHEY1svsUxpdomViI?= =?us-ascii?Q?vnWMN4h45AoBZke7LyD2UdMEeixuLPD+WpHzBSzdUrGxEvJgXIENmz10P1y1?= =?us-ascii?Q?X7Uc6bftn8Y+pNGtaAcQSi1YgsREpW/lJkHL0Ov0zqtKnyPOw01s0eEeczw7?= =?us-ascii?Q?LOJQDyqd9gn1B8Tv4EYCeu8ZcL6cZCNdaZEczVUW9xXvgCzQy/9Loxgxcn3Y?= =?us-ascii?Q?nM/KRLnH19f92Tn5wbU477m2gdVQrafQ4IagBHjwK/7dCrsrRlkVs15I3T84?= =?us-ascii?Q?MZG+Lf6HJq48ZfINLSJ5rHEKOow+xwPof5W7dDVQ4yrGdn2Rm475o3mrh0ON?= =?us-ascii?Q?HhV/K/iD+WTka25HMU6zNaOq7B4FU7QeM5tTaINJ62KIaTEfkyOA8JC65kxc?= =?us-ascii?Q?b/qWfNJADzfmQAhciPj9YENL1rmLvO3JyX0m00N540hBa7oAc01hfV9plOaj?= =?us-ascii?Q?AIOvW61ey/ybfifDPJyKvgkngIBlbj0hu9J2KAfveLwCs96FJj/oMIQ1UJbi?= =?us-ascii?Q?Vapi2/edXBF5a2Sp10ni4l2GPzOqzfNEMgi5W+Y95VKB7bEaZS4jETuPxzV/?= =?us-ascii?Q?UMjXicH3DTR3ojsYd/eNkF6YWNKhJZg6pfcVLCU3UZESlBLPjs2xRjHmZ8jA?= =?us-ascii?Q?bWc9vMrzp+nwnW9h1a85U+peVtzbsTWEnBryvG2XQQZEjjxHBrTy4NdCKMWP?= =?us-ascii?Q?Lcs0JFIgb2qiJVqo0rhVNiAVMONhtUEsrIKrFkMaeXeN0DHCsPZysdKFikgd?= =?us-ascii?Q?YtxskKxRGp0asX48A3iQKWGa9kiVQ3ZT4Azv9kwggqUYxm5sc3nCMWty8oPg?= =?us-ascii?Q?V4FRf2tDBdDGGwXY0oyO1V96G67psL0tgU2KBfaXVFB92JZYQKxOONfWkBui?= =?us-ascii?Q?0NOuFdpD7N65QkzrgYUsL+lS6RFqXgoelOSTwSGDfqzxc4JhZ0oqNp0zR/kI?= =?us-ascii?Q?B+Ri6FhWoKlYJLZGI4W5ll6CdelLcSaRLL1Y0mJK5VE4bCAEnr7Yq5TG8W+M?= =?us-ascii?Q?Gnzz1YXA5sCF4w3U3EFlXE2gwB8Nxj1GgY63tT++?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: 7c1a6330-6527-4069-62b7-08da66ed926a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2022 05:39:37.5449 (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: R1ZG1WULLGbx7xrU3r4zBGd26haaHvYStwJylNQiaIme5OtRhi4G4V2ueWP/gsULfjLvBiridje3Lwh37aLOOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3625 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 [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 >=20 > [CAUTION: External Email] >=20 > Send users mailing list submissions to > users@dpdk.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit >=20 > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fmails= .dp > dk.org%2Flistinfo%2Fusers&data=3D05%7C01%7Cvipin.varghese%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 >=20 > You can reach the person managing the list at > users-owner@dpdk.org >=20 > When replying, please edit your Subject line so it is more specific than = "Re: > Contents of users digest..." >=20 >=20 > Today's Topics: >=20 > 1. Packet Accumulation in RX and TX in bnx2x (Usman Tanveer) > 2. mlx5: Keeping packets with invalid CRC/FCS (Pfau, Johannes (ITIV)) >=20 >=20 > ---------------------------------------------------------------------- >=20 > 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 > 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" >=20 > Hi, >=20 > 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. >=20 > 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. >=20 > 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%2F6887b7b4%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> >=20 > ------------------------------ >=20 > 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" >=20 > Hi all, >=20 > 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. >=20 > 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: >=20 > 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? >=20 > 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? >=20 > Best regards, > Johannes >=20 > -- > Karlsruhe Institute of Technology (KIT) > Institut f?r Technik der Informationsverarbeitung (ITIV) >=20 > M.Sc. Johannes Pfau > Research Associate >=20 > Engesserstr. 5 > Building 30.10, Room 218.1 > 76131 Karlsruhe, Germany >=20 > Phone: +49 721 608-41939 > E-mail: johannes.pfau@kit.edu >=20 >=20 > Registered office: > Kaiserstra?e 12, 76131 Karlsruhe, Germany >=20 >=20 > KIT ? The Research University in the Helmholtz Association >=20 > -------------- 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> >=20 > End of users Digest, Vol 347, Issue 13 > **************************************