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 7AD90A00C4; Thu, 28 Jul 2022 13:29:24 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 71BA642B8E; Thu, 28 Jul 2022 13:29:24 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 0D1B042B8A for ; Thu, 28 Jul 2022 13:29:23 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RFC] EAL: legacy memory fixed address translations Date: Thu, 28 Jul 2022 13:29:21 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87202@smartserver.smartshare.dk> In-Reply-To: <20220728102537.48ff6e5f@sovereign> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC] EAL: legacy memory fixed address translations Thread-Index: AdiiU0AXdJ29olMOTHWLSh9Hb9o5sgAHgq5Q References: <256b5409-ddaf-d7cc-00c1-273ca76dbf71@xsightlabs.com> <6aaa04d8-2ac5-ced6-ec25-d42bc52a3e2f@xsightlabs.com> <20220726225910.26159820@sovereign> <20220727233644.21f0b2a3@sovereign> <20220728102537.48ff6e5f@sovereign> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Dmitry Kozlyuk" , "Don Wallwork" Cc: , "Bruce Richardson" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Dmitry Kozlyuk [mailto:dmitry.kozliuk@gmail.com] > Sent: Thursday, 28 July 2022 09.26 >=20 > 2022-07-27 17:43 (UTC-0400), Don Wallwork: > > On 7/27/2022 4:36 PM, Dmitry Kozlyuk wrote: > > > I now understand more about_why_ you want this feature > > > but became less confident_what_ do you're proposing specifically. > > > > Let me try to give a trivial example of how it would work > > to make sure we're on the same page and then we can get > > back to details.. >=20 > Thanks you, Don. > Now it's perfectly clear what EAL should do and we can discuss API. I think this RFC is an excellent proposal! Long term, I also hope that it can lead to the removal of the = mbuf->buf_iova field, making it available for other purposes - e.g. = moving the mbuf->next field up here, so rte_pktmbuf_free(), = rte_pktmbuf_prefree_seg() and other functions don't have to touch the = mbuf's second cache line anymore. >=20 > [...] > > So in this example, we have a fixed offset of 9G to translate > > between VA to PA or vice versa.This works whether the huge > > pages happen to be allocated statically (legacy mode) or > > dynamically. >=20 > True! >=20 > One special case is external memory (rte_extmem_*) > which has user-controlled VA and IOVA. > If all non-external memory is mapped within one VA region, > it is possible to detect that an address is in external memory, > although it's an extra check. I wish the support for external memory and other semi-exotic features = (incl. segmented mbufs) could be removed at build time! The decision to = change DPDK from a development kit to a library is making DPDK = unnecessarily bloated for development of embedded applications.