From: Don Wallwork <donw@xsightlabs.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
"Dmitry Kozlyuk" <dmitry.kozliuk@gmail.com>
Cc: dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [RFC] EAL: legacy memory fixed address translations
Date: Thu, 28 Jul 2022 10:46:21 -0400 [thread overview]
Message-ID: <7a030fd7-65ab-787d-60df-1eae8d5b6f06@xsightlabs.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87202@smartserver.smartshare.dk>
On 7/28/2022 7:29 AM, Morten Brørup wrote:
>>> 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!
Thanks Morten and Dmitry. Great to hear that. When we have a
patch ready, will post on the list.
>
> 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.
>
Yes, it does seem possible that this could be done once the fixed
translation logic is in place.
next prev parent reply other threads:[~2022-07-28 14:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-26 18:18 RFC: EAL " Don Wallwork
2022-07-26 18:33 ` [RFC] EAL: " Don Wallwork
2022-07-26 19:59 ` Dmitry Kozlyuk
2022-07-27 17:20 ` Don Wallwork
2022-07-27 19:12 ` Stephen Hemminger
2022-07-27 19:27 ` Don Wallwork
2022-07-27 20:36 ` Dmitry Kozlyuk
2022-07-27 21:43 ` Don Wallwork
2022-07-28 7:25 ` Dmitry Kozlyuk
2022-07-28 11:29 ` Morten Brørup
2022-07-28 14:46 ` Don Wallwork [this message]
2022-07-28 15:41 ` Don Wallwork
2022-07-28 16:33 ` Dmitry Kozlyuk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7a030fd7-65ab-787d-60df-1eae8d5b6f06@xsightlabs.com \
--to=donw@xsightlabs.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=mb@smartsharesystems.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).