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 B38C0A0350 for ; Thu, 23 Dec 2021 20:50:13 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 43E2140DDA; Thu, 23 Dec 2021 20:50:13 +0100 (CET) Received: from vadc01-egs01.gd-ms.com (vadc01-egs01.gd-ms.com [137.100.132.43]) by mails.dpdk.org (Postfix) with ESMTP id D0DB64068C for ; Thu, 23 Dec 2021 20:50:11 +0100 (CET) X-IronPort-AV: E=Sophos;i="5.88,230,1635220800"; d="scan'208,217";a="16901094" Received: from unknown (HELO eadc-e-fmsprd01.eadc-e.gd-ais.com) ([10.96.30.97]) by vadc01-egs01.gd-ms.com with ESMTP; 23 Dec 2021 14:50:11 -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 12E53A6803D for ; Thu, 23 Dec 2021 19:50:11 +0000 (UTC) Received: from VADC-MCA01.GD-MS.US (10.132.100.42) by VADC-MMB01.GD-MS.US (10.132.100.61) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Thu, 23 Dec 2021 14:50:10 -0500 Received: from USG02-BN3-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.26 via Frontend Transport; Thu, 23 Dec 2021 14:50:10 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=loXOz8AG/D30XaNqKcCjxxaEwcoyt4qLlrWu4GrwuEh24c0CGWAP77+ETceQqkZLnD9Y8fsRBV23akeAGstr1oPi8sk9QIJmfBSnSVybXS7Etmlnl4bssC3mmDUJIRiUoEIYYQmPhKgF1ILM/TNdRm2AoojrMt/065mKjovVP+e62qQz/Cg34UqwLBoL/Th3IpDTNDVxilUcO4mmGpLkiGz9qaRHbJES/mg28OJMVTDn1BbjE8aSX1GD/WcFcQI5VPsMob34i7LCC61DD8GPCDqB4tt332Ohbm6YDl50izS+7qSooFbbbtATb0r3r99p7NWpnvt7+pTe8KXygs2fyw== 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=D0i2OQOZRcRtNTBkOnBmfXRVlyXPdVXscEi2vBy8+WU=; b=XjMZg/BMI20cQ9AajCe8KdAdUZorjAwXeYM0cUaNJOpcAzFSn8CF8QIEZlqXTfyALOS57mcseIySOEWI1NKiDZsOGUJ+GVPcyFHrnKX/qmrWZ030bixRGGqnYojM4jeqrt/9mZconVEZ+2oomPD8deQLZhfybKOeXsVvcwSRjHWdWTXg5jEVUFdM4cAxmhfWHR5OZnwBFza0LWGbYU6wLJTCbuw6CnXvwYCfPZepEqdRGzUekwKJ0h1FlIk3AYUC6KtYlRdr5sE+7aqTEwdur2hjf9QSRWGny+lUB0f0ZIkOQ9691dCTy/sAgxjPedpUkSXq3jmCxl+CleSTkN4Utw== 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 PH1P110MB1773.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:175::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.18; Thu, 23 Dec 2021 19:50:08 +0000 Received: from PH1P110MB1067.NAMP110.PROD.OUTLOOK.COM ([fe80::d031:cabc:1718:98a8]) by PH1P110MB1067.NAMP110.PROD.OUTLOOK.COM ([fe80::d031:cabc:1718:98a8%6]) with mapi id 15.20.4823.019; Thu, 23 Dec 2021 19:50:08 +0000 From: "Ramin.Taraz@gd-ms.com" To: "users@dpdk.org" Subject: Accessing packet data from different lcores Thread-Topic: Accessing packet data from different lcores Thread-Index: Adf4M/aQ5lRFwqHrQDGrtYbnuDVinw== Date: Thu, 23 Dec 2021 19:50:08 +0000 Message-ID: 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: 9138b421-2062-4599-5165-08d9c64d6cb8 x-ms-traffictypediagnostic: PH1P110MB1773: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3TJ8lPWf6AwBLrvclICaKSvWkbe5rzLLIv3YFQomC33Z/aggEbWDDt7hVUkQBQOuamCjSZGqgDB+w2NsQ58gUGhWDLuHm810JdyuJTnQV7xxCBwDvxk01BDi1VYKbm83z/DVrhsq4OKcPzJjFdPU2k1i1GRqe1xttN2qeEqIqKaLOxIkk0eketYZKdg4/S6XP+WzyKS5jRHTM1quD7gER9XnZafdjPU94aw75kZO9QhcnQ9MgSIrzDk8+OdBPgQsLhJX/I0Sj1XHR+TfD6O17B1Cdl4pgj1QKIR/rzsuieAPrs5MZ+AQEJnfmdjOvgZSEIudGjcPBqO5MKhd8QKtXJV0Z1V0hnYkOWl0u7I25uaLQAH0SDYDhjO8ka8oXftoLKpkdK4tAOwjLWv19R1UocHSOFGvgnmbTmCzRj+vcRn624uuasr0clTJ7w/NUa5nMLbIODiXnJz4q3B4bHFpRJmkO4u/ihElfu0r5P1aRx1vu0+Yky0vDhdc4XgtA8c506QWu09+7vP+kYpzDnEu+xhS/vt8q0KFuXV5QcdIiIcpEiTZMyn7kI4turTztAX04aHA4G94ORGCPHalegGs+SoAAsIeHAchNGdULT0XaCj/Eon0SCFgzPHMZxAtRxJq 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:(366004)(6916009)(186003)(8936002)(64756008)(38100700002)(5660300002)(8676002)(55016003)(76116006)(52536014)(83380400001)(71200400001)(7696005)(2906002)(6506007)(86362001)(33656002)(122000001)(66556008)(498600001)(26005)(82960400001)(66446008)(66946007)(66476007)(9686003)(38070700005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: NueKhbVfkneBhOWoAsTH687xb5D1HmK2bV7icmJKjPo/k/jweZapenCo8auRozzCZXhYVjxBNWGjSl0uHejS4XPc0ehFCJPF8OUBHgZY0mN3JENNqq4xHRRQmUrb8w5IiRWJupROzEinuAFY8AKJCw== Content-Type: multipart/alternative; boundary="_000_PH1P110MB1067954AE2B768692505F3FAAE7E9PH1P110MB1067NAMP_" 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: 9138b421-2062-4599-5165-08d9c64d6cb8 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2021 19:50:08.7271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7c5a26cf-ddf0-400c-9703-4070b4e3a54d X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH1P110MB1773 X-OriginatorOrg: gd-ms.com X-TM-SNTS-SMTP: E62C6FB5FAA6E2371D447229A904682D7041B08044B2B0FD3E6AC2695A8AADF12000: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 --_000_PH1P110MB1067954AE2B768692505F3FAAE7E9PH1P110MB1067NAMP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all. Newbie question here. 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 an= d 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. --_000_PH1P110MB1067954AE2B768692505F3FAAE7E9PH1P110MB1067NAMP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all.

Newbie question here.

 

I have been playing with dpdk 21.11 for a week or tw= o and run into something that has me scratching my head a bit.

 

I’m looking at packet_reorder example.  I= ’m running this sample with 3 cores: 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 p= uts them in a rx_to_workers ring

Worker thread reads from the rx_to_workers ring, cha= nges the port number and queues to workers_to_tx ring

Tx thread reads from workers_to_tx ring and calls rt= e_eth_tx_buffer

 

 

What I like to do is access the packet content in th= e worker thread and print out a few bytes from it.

 

What I’m finding is that mbuf_addr value, for = the same mbuf, read from RX thread is different than if read in the Worker = or TX thread.

 

For example, when printing out the address of mbuf, = and mbuf_addr values, in 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 diffe= rent.   The packet content is obviously (?) different if read in = RX, vs if read in Worker or TX thread.

 

Is this what is supposed to happen?

 

Basically: how do I get access to the actual etherne= t packet, for reading or modifying, on different lcores; in this case the w= orker thread.

--_000_PH1P110MB1067954AE2B768692505F3FAAE7E9PH1P110MB1067NAMP_--