From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by dpdk.org (Postfix) with ESMTP id 3B2638E93 for ; Wed, 4 Nov 2015 19:56:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6545; q=dns/txt; s=iport; t=1446663404; x=1447873004; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5UvldcMKhmwuu5l3xg57vWcaQb6Dz+y8/q6+tmkvXvo=; b=DsITnelt4usP+m/gGCWrdRX1t7UbCyoSuaq6BLRMpIFgrz/AHKG1S7+3 HmhUhhivQVHl1N6LPY/4i8/0IU4FmmgX31y5uzh/se6m90zvQsvHwa1kt 1aJoW707maKAOZJaTJs+VxbMo2lf2bjecefF27BZgZHCwzwud/I9aGxvj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaAgBYVDpW/5ldJa1egm5NgUIGvUMBDYFehhICgUM4FAEBAQEBAQF/C4Q1AQEBBHkQAgEIEQMBAigHMhQJCAIEDgWILsInAQEBAQEBAQECAQEBAQEBAQEBGotShHuEPQWNVIUTg2EBiAyFFoFajVCJJYNxAR8BAUKEBHKELYEHAQEB X-IronPort-AV: E=Sophos;i="5.20,244,1444694400"; d="scan'208,217";a="41827107" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 04 Nov 2015 18:56:43 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tA4IugGh031055 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Nov 2015 18:56:43 GMT Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 12:56:42 -0600 Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1104.000; Wed, 4 Nov 2015 12:56:42 -0600 From: "shesha Sreenivasamurthy (shesha)" To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] Reshuffling of rte_mbuf structure. Thread-Index: AQHRE5bISS1IQdF67k2r5hvr+GvFxJ6G/a2AgAJVlQD//505AIAAh1wA//+4BACAAI+LgIAAGR6AgAJD2wA= Date: Wed, 4 Nov 2015 18:56:42 +0000 Message-ID: References: <2014794.RrzFoKiHXW@xps13> <20151103002117.GA3665@mhcomputing.net> In-Reply-To: <20151103002117.GA3665@mhcomputing.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.248.245] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Reshuffling of rte_mbuf structure. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 18:56:44 -0000 Is there a way where we can just define the fields that ought to be there i= n the mbuf structure, but the position and size is implementation dependent= ? The application can provide "mbuf_impl.h" that contains mbuf_rte fields = in the order that seems appropriate to application. -- - Thanks char * (*shesha) (uint64_t cache, uint8_t F00D) { return 0x0000C0DE; } From: Matthew Hall > Date: Monday, November 2, 2015 at 4:21 PM To: Thomas Monjalon > Cc: Cisco Employee >, Arnon Warsh= avsky >, "dev@dpdk.org" > Subject: Re: [dpdk-dev] Reshuffling of rte_mbuf structure. On Mon, Nov 02, 2015 at 11:51:23PM +0100, Thomas Monjalon wrote: But it is simpler to say that having an API depending of some options is a "no-design" which could seriously slow down the DPDK adoption. What about something similar to how Java JNI works? It needed to support multiple Java JRE / JDK brands, implementations etc. Upon initialization, a function pointer array is created, and specific slots are filled with point= ers to the real implementation of some native API functions you can call from inside your library to perform operations. In the DPDK case, we need flexible data instead of flexible function implementations. To do this there would be some pointer slots in the mbuf that are are fille= d with pointers to metadata for required DPDK features. The data could be pla= ced in the following cachelines, using some reserved tailroom between the mbuf control block and the packet data block. Then the prefetch could be set up = to prefetch only the used parts of the tailroom at any given point, to prevent unwanted slowdowns. Matthew.