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 22AA0A00C3 for ; Wed, 23 Feb 2022 16:15:55 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A13AC41226; Wed, 23 Feb 2022 16:15:54 +0100 (CET) Received: from vadc01-egs02.gd-ms.com (vadc01-egs02.gd-ms.com [137.100.132.44]) by mails.dpdk.org (Postfix) with ESMTP id 44E15411B2 for ; Wed, 23 Feb 2022 16:15:53 +0100 (CET) X-IronPort-AV: E=Sophos;i="5.88,391,1635220800"; d="scan'208";a="19021698" Received: from unknown (HELO eadc-e-fmsprd01.eadc-e.gd-ais.com) ([10.96.30.97]) by vadc01-egs02.gd-ms.com with ESMTP; 23 Feb 2022 10:15:52 -0500 Received: from VADC-MMB01.GD-MS.US (vadc-mmb01.gd-ms.us [10.132.100.61]) by eadc-e-fmsprd01.eadc-e.gd-ais.com (Postfix) with ESMTP id 0FD4AA6803C for ; Wed, 23 Feb 2022 15:15:52 +0000 (UTC) Received: from vadc-mmbbak01.GD-MS.US (10.132.100.161) by VADC-MMB01.GD-MS.US (10.132.100.61) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Wed, 23 Feb 2022 10:15:45 -0500 Received: from VADC-MCA01.GD-MS.US (10.132.100.42) by vadc-mmbbak01.GD-MS.US (10.132.100.161) with Microsoft SMTP Server (TLS) id 15.0.1497.28; Wed, 23 Feb 2022 10:15:45 -0500 Received: from USG02-CY1-obe.outbound.protection.office365.us (137.100.132.86) by VADC-MCA01.GD-MS.US (10.132.100.78) with Microsoft SMTP Server (TLS) id 15.0.1497.28 via Frontend Transport; Wed, 23 Feb 2022 10:15:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=YxlZTWhPuJvhw5efG8kdTRmT9jev/GsyMSHgKgkTCTOj4/thEErpuY2k3vhqHNIXNwJzzuoFSJ3DZK5iS/nvmXAbqfV8EocRTc9mgjBIiNT3TS4xBX7smG4V6MDnm13SjCwI5VfcLXTzi3YoFe1x6bggZwUej2LfFhnqE2SdwzyjXzQ70nnTq1oouHKIAXGRK3c8tEtKKbgbRxLhRf8s4wi8U35p6wka038bFEtoeMLB3uPFSwQmyo9jZZNCi4p5bf0so9/nAK6dkICoYeq2YJuML3uUFii3sKO36EP3W+qtEcNFv/Qkah19PZJPK7eEk3Hy67D5qzTJLoWR+ygKTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; 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=7gQlbZ3krCq4MOGWikS0S0fVXaeo6ME1qayFR/h6zWA=; b=EfKM1PU40Sho+WDzcNWx8W+wIU1gqi8fNfkyEmu7xI7i+RRtji/N5FQ6XMcZzonpj5WgNlIUFB7TxshtEcKw6GAjsKhnhbJceWUkqo7Cau+HLpRmck8oSG3yd8Ck7H1NMYCROyW9vikUctx4mYjhQ9lGLqkpnUkLq2qbpRdX9XXKXdr5pgmgMxjzTheCk8Um5kRn0SsC45t+qns9bCDhn7GE6J1fsOZt8bPD8xZ2NVPzxbgh1ZFWyp4hTBsilwzSEL0wxm+5OgYpYVml7/nXLxWaxPnhPSdsSA/6Iv3Gy+u6Az2ipev8BPofAvDa2RjSmbtMRq6j1wwF9+F9ug64+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=gd-ms.com; dmarc=pass action=none header.from=gd-ms.com; dkim=pass header.d=gd-ms.com; arc=none Received: from PH1P110MB1067.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:177::6) by PH1P110MB1035.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:177::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22; Wed, 23 Feb 2022 15:15:43 +0000 Received: from PH1P110MB1067.NAMP110.PROD.OUTLOOK.COM ([fe80::4d1b:adab:7697:cd12]) by PH1P110MB1067.NAMP110.PROD.OUTLOOK.COM ([fe80::4d1b:adab:7697:cd12%6]) with mapi id 15.20.4995.026; Wed, 23 Feb 2022 15:15:43 +0000 From: "Ramin.Taraz@gd-ms.com" To: "users@dpdk.org" Subject: RE: [dpdk-users] Accessing packet data from different lcores Thread-Topic: [dpdk-users] Accessing packet data from different lcores Thread-Index: AdgHTW8Nf3bcj8TKR26fuGGzDQLgAQhepIJA Date: Wed, 23 Feb 2022 15:15:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=gd-ms.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 604ef4a2-baa6-4b71-0b01-08d9f6df5c0b x-ms-traffictypediagnostic: PH1P110MB1035:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: N+VqPBduZufpVnLFBbeB1/4ik002GC0MlwHcVZb3bji8dnJollSHxaKGnMY09XfvF9jH4ZHgt2KBnVQwLY01J7b3MZkksgU8h3149LKm/ba+Rp77DTB+ScPfuFnCBPcAmbBMazv/xX4Ppm2rsPLjFGFEy68bqoZ+c71uMFHx7/DL6ofCs7BxAvuAyGl6rgmbMOOYggoznaohtopORVnV0SeCMZ/W4jZmnGjdccnkbhLLv5rIKlyVL8poOgKSCKZcy9GTRAGXkQu8Nv3BD5Z9l2WejOqkDD1APLoJ0jdIhqMEx3UjtMJZodjcnF3MbGiWzuNJavsPRHYKFCEEpNRDiphyqxCldF8539bwR9eniCb+XdBow7eq08QTSvKh9PZsqfAwCnamZb5CxSjbblOM6TeL1f44oKGYzvHNoO28PxyE7nGu6ObH4QCtL9sWUq8pWvrnbJuEs3kzTkNPZB+1s5tPTeffNvpejHogiytzwx993VhI6ItWVJBNBxDYHPfP1jArCorFL7oMjm1Nsw9vqfYx5V1cwJyfSsVvRx/FqENB3BQbUEKbKMge+UbW2efIQiyYSkwkGGx19QssOm+LFRHVnA7h0BspT6vCX3+hGlvqIgIdqSMbRZh/ED812PuR x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH1P110MB1067.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(366004)(83380400001)(82960400001)(122000001)(186003)(8676002)(26005)(55016003)(33656002)(2906002)(498600001)(71200400001)(6506007)(7696005)(38070700005)(38100700002)(52536014)(8936002)(64756008)(5660300002)(66476007)(66556008)(6916009)(66446008)(66946007)(76116006)(9686003)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: 5ju6DOOvIycJAevLACjrw+n4Pe0mnLITHDf2MzPisW4HtbWIGDkAjyLezDVyPAQQtNYrOEEj/lHMcP84waeZXo76Fc0JGpedn4wWfzGV/ioY3CUuOqRarOITlck/QSViCXpBdGZzw/WCacK+E4UZWw== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH1P110MB1067.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 604ef4a2-baa6-4b71-0b01-08d9f6df5c0b X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2022 15:15:43.0598 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7c5a26cf-ddf0-400c-9703-4070b4e3a54d X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH1P110MB1035 X-OriginatorOrg: gd-ms.com X-TM-SNTS-SMTP: 30BD8ADCD7619E6C593F8F3C2427F2285EBC874351171CAB09A6338F11D188F92000:8 X-Content-Scanned: Fidelis Mail 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 Back in December of 2021, I posted a question about accessing the buff_addr= pointer from different cores, which oddly, wasn't working properly. The original question is pasted below. I was specifically using the packet_ordering example, as listed below and r= unning it with --disable-reorder option. The problem of buff_addr having the wrong value in different cores ended up= being the result of a bug in packet_ordering example. The example allows the user to select whether they want to stamp packets wi= th a seq # or not to compare the performance difference. In the case of not stamping with a seq #, the rx_thread doesn't disable sta= mping=20 Rx_thread () { .... /* mark sequence number */ for (i =3D 0; i < nb_rx_pkts; ) { *rte_reorder_seqn(pkts[i++]) =3D seqn++; } ..... } When disordering is disabled, rte_reorder_create isn't called and the varia= ble rte_reorder_seqn_dynfield_offset stays at default value of -1. And eve= ntually *rte_reorder_seqn(pkts[i++]) =3D seqn++; corrupts buff_addr. Proper fix is not stamping the packet with seq # in dpdk-21.11/examples/pac= ket-ordering/main.c:rx_thread if the flag --disable-ordering is set. -------------------------- I have been playing with dpdk 21.11 for a week or two and run into somethin= g that has me scratching my head a bit. I'm looking at packet_reorder example. I'm running this sample with 3 core= s: 1 RX, 1 Worker, and 1 TX. dpdk-packet_ordering -l 0-3 -- -p 3 --disable-reorder In this example: RX thread reads the packets from receive queue and puts them in a rx_to_wor= kers ring Worker thread reads from the rx_to_workers ring, changes the port= number and queues to workers_to_tx ring Tx thread reads from workers_to_tx= ring and calls rte_eth_tx_buffer What I like to do is access the packet content in the worker thread and pri= nt out a few bytes from it. What I'm finding is that mbuf_addr value, for the same mbuf, read from RX t= hread is different than if read in the Worker or TX thread. For example, when printing out the address of mbuf, and mbuf_addr values, i= n the three threads, I get: rx_thread mbuf =3D 100e30000 mbuf_addr =3D 100e30080 worker_thread mbuf =3D 100e30000 mbuf_addr =3D 100000000 tx_thread mbuf =3D 100e30000 mbuf_addr =3D 100000000 So although mbuf is the same, the mbuf_addr is different. The packet cont= ent is obviously (?) different if read in RX, vs if read in Worker or TX th= read. Is this what is supposed to happen? Basically: how do I get access to the actual ethernet packet, for reading o= r modifying, on different lcores; in this case the worker thread.