<div dir="ltr"><div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default">Thanks Ashwin for the explanation. </div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default"><i>On AQ Init, the context is first allocated in the cache.</i> -> Does the hardware take care of it? Before writing to memory, it writes to NDC first?</div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default"><br></div></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-family:verdana,sans-serif">Thanks</span></div><div><span style="font-family:verdana,sans-serif">Amiya</span><br></div></div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 16 Sept 2026 at 21:08, Ashwin Sekhar <<a href="mailto:asekhar@marvell.com">asekhar@marvell.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Amiya,<br>
<br>
NDC is a cache that NPA uses to cache frequently accessed contexts and stack pages. All accesses to contexts/stack pages go via this cache only. There is NO direct access to backing memory in NPA operations.<br>
<br>
On AQ Init, the context is first allocated in the cache. Whenever NPA must access this context (for subsequent alloc/frees or AQ reads/writes), it will read/write directly from the cache. The context/stack pages never gets evicted out of the cache (unless there are more contexts/stack pages active at the same time than the NDC can hold).<br>
<br>
Doing an NDC sync will write back the dirty entries in the cache to the backing memory. This does not affect the normal operation of NPA in anyway. Even after you do a sync, the entries remain in the cache and further NPA operations still read/write from the cache. The backing memory is NEVER accessed directly.<br>
<br>
Why we need it at teardown is to avoid corruption. We free stack pages when we destroy the pool. If there are stale entries for these stack pages remaining in the cache, then at a later point of time, these entries can become candidates for eviction and can cause writes to memory which was already freed causing corruption/translation faults etc.<br>
<br>
>> how it's a side effect of IOVA as PA<br>
IOVA as PA is NOT a supported mode. We have not studied what kind of errors will pop up in this mode. Explaining the side effects in this mode will require deeper study which we don't think is necessary for an unsupported mode. <br>
<br>
Thanks<br>
Ashwin  <br>
<br>
</blockquote></div>