<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><span class="gmail-im" style="color:rgb(0,0,0);background-color:rgb(238,238,238)">> NPA_POOL_ERR_INT_RANGE fires spuriously between <span class="gmail-il">pool</span> creation<br>
> (ptr_start/ptr_end default to 0/~0) and the actual <span class="gmail-il">range</span> install<br>
> via roc_npa_pool_op_range_set().  <br></span><span style="color:rgb(0,0,0);background-color:rgb(238,238,238)">>>ERR_INT_RANGE is not supposed to fire spuriously. Did you root cause why this is happening ?</span></i></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">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. When the MMIO data path (aura_op_free) reads pool context, it goes through NDC which can still have stale zeros from a previous init/teardown cycle — including ptr_end=0. Against that stale range [0, 0], any buffer IOVA triggers RANGE.<br><br></div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default">The NDC sync patch [<a href="https://patches.dpdk.org/project/dpdk/patch/20260909192323.26886-1-amiyaranjan.mohakud@gmail.com/">https://patches.dpdk.org/project/dpdk/patch/20260909192323.26886-1-amiyaranjan.mohakud@gmail.com/</a>] addresses this root cause by invalidating NDC after AQ INIT. This RANGE patch adds defense-in-depth: mask RANGE during the init→range_set window and re-enable only after the real range is installed. </div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default">I also acknowledge that this fix is no longer required if we force-sync the NDC as in <a href="https://patches.dpdk.org/project/dpdk/patch/20260909192323.26886-1-amiyaranjan.mohakud@gmail.com/">https://patches.dpdk.org/project/dpdk/patch/20260909192323.26886-1-amiyaranjan.mohakud@gmail.com/</a>. We can drop this patch completely.</div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default"><br></div><span style="background-color:rgb(238,238,238)"><i><span class="gmail-im" style="color:rgb(0,0,0);font-family:trebuchet ms,sans-serif">> On CN10K this drains the <span class="gmail-il">pool</span><br>
> stack and makes the <span class="gmail-il">pool</span> unusable.<br></span><span style="color:rgb(0,0,0);font-family:trebuchet ms,sans-serif"><span class="gmail_default">>></span></span><span style="color:rgb(0,0,0);font-family:trebuchet ms,sans-serif">Didn't quite understand this part. Could you please elaborate.</span></i></span></div><div><br></div><div><span style="color:rgb(103,78,167);font-family:trebuchet ms,sans-serif"><span class="gmail_default">Sorry for my p</span>oor wording<span class="gmail_default">s.</span> on my part. The pool stack does not get drained — it<span class="gmail_default" style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)"> </span>never gets populated.<span class="gmail_default" style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)"></span>During cnxk_mempool_populate(), each<span class="gmail_default" style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)"> </span>roc_npa_aura_op_free() call silently drops the buffer (NPA sees<span class="gmail_default" style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)"> </span>stale context with ena=0 or ptr_end=0 via NDC). After populate<span class="gmail_default" style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)"> </span>completes, the pool has 0 available buffers despite no error being<span class="gmail_default" style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)"> </span><span class="gmail_default" style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)">r</span>eturned. Subsequent roc_npa_aura_op_alloc() returns NULL, causing<span class="gmail_default" style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)"> </span>port start failures.</span></div><div><br></div><div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default">All this will be taken care of via NDC sync. So it's safe to drop this patch.</div><br></div><div><div style="font-family:trebuchet ms,sans-serif;color:rgb(103,78,167)" class="gmail_default">I initially made this fix and later fixed the NDC sync issue, so somehow, I forgot to  mark this patch as dropped.</div><br></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 Tue, 15 Sept 2026 at 12:09, Ashwin Sekhar T K <<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>
> NPA_POOL_ERR_INT_RANGE fires spuriously between pool creation<br>
> (ptr_start/ptr_end default to 0/~0) and the actual range install<br>
> via roc_npa_pool_op_range_set().  <br>
ERR_INT_RANGE is not supposed to fire spuriously. Did you root cause why this is happening ?<br>
<br>
<br>
> On CN10K this drains the pool<br>
> stack and makes the pool unusable.<br>
Didn't quite understand this part. Could you please elaborate.<br>
<br>
Thanks<br>
Ashwin<br>
<br>
<br>
</blockquote></div>