RE: [RFC] EAL: legacy memory fixed address translations

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Dmitry Kozlyuk [mailto:dmitry.kozliuk@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.