<div dir="ltr"><div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default">Hi Ashwin</div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default"><br></div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default"><i style="color:rgb(0,0,0)">The AQ INIT does not bypass NDC. May I know how you arrived at this conclusion?</i></div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default"><span style="color:rgb(0,0,0)"><i>
Even your other NDC sync patch is not required. The only time NDC sync
is required is at teardown time because at this point, we free the stack
memory. So, after this, NPA should not evict any stale stack pages back
to memory (which is already freed).</i></span></div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default"><span class="gmail-im"><br></span><i>>> </i>I don't see any ndc_sync calls during pool_init, So the NDC is not updated at pool_init time, whereas it's getting called for all termination paths. Could you explain how this is taken care of then without an ndc sync? I need to test without NDC sync changes multiple times and confirm. BUt if you could explain how it'll work without NDC sync or how it's a side effect of IOVA as PA, it would be great.</div><br clear="all"></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 11:13, Amiya Ranjan Mohakud <<a href="mailto:amiyaranjan.mohakud@gmail.com">amiyaranjan.mohakud@gmail.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"><div dir="ltr"><div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default">Hi Ashwin - I have raised a ticket <a href="https://bugs.dpdk.org/show_bug.cgi?id=2031" target="_blank">https://bugs.dpdk.org/show_bug.cgi?id=2031</a> with details. Pls check if it helps.</div><br clear="all"></div><div><div dir="ltr" class="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"><div dir="ltr" class="gmail_attr">On Wed, 16 Sept 2026 at 10:10, Ashwin Sekhar T K <<a href="mailto:asekhar@marvell.com" target="_blank">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>
> Yes — the root cause is NDC staleness. The AQ INIT writes pool context (including ptr_start=0, ptr_end=~0) directly to RAM, bypassing NDC.<br>
The AQ INIT does not bypass NDC. May I know how you arrived at this conclusion?<br>
Even your other NDC sync patch is not required. The only time NDC sync is required is at teardown time because at this point, we free the stack memory. So, after this, NPA should not evict any stale stack pages back to memory (which is already freed).<br>
<br>
> Sorry for my poor wordings. on my part. The pool stack does not get drained — it never gets populated.During cnxk_mempool_populate(), each roc_npa_aura_op_free() call silently drops the buffer (NPA sees stale context with ena=0 or ptr_end=0 via NDC). After populate completes, the pool has 0 <br>
> available buffers despite no error being returned. Subsequent roc_npa_aura_op_alloc() returns NULL, causing port start failures.<br>
It will not silently drop. You should be getting AURA DISABLED interrupts.<br>
<br>
Could you please explain the exact use case and issue that you are facing?<br>
<br>
Thanks<br>
Ashwin<br>
<br>
</blockquote></div>
</blockquote></div>