> From: Dmitry Kozlyuk [mailto:dmitry.kozl...@gmail.com] > Sent: Thursday, 28 July 2022 09.26 > > 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.. > > 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. > > [...] > > 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. > > True! > > 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.
