On 7/10/2019 9:40 PM, yoursunny wrote: > Hi Ferruh > > I've uploaded my test case to Bug 183. > You can determine whether it is a bug that should be covered by this > patch, or it should be handled separately.
Thanks for clarification, your use case is about indirect mbufs, I can see why it is not working from your explanation in the bug report. I think previously when all mbufs were coming from same physically continuous memory, indirect mbufs should work. Right now I don't know how to support them. This defect fixes an issue for multi segment packages, caused by wrong address calculation for next segments. So I am for continuing with this patch, independent from indirect mbufs issue. Do you have any other issue, except than the indirect mbuf issue, if you have other KNI use cases? > > Yours, Junxiao > > On Wed, Jul 10, 2019 at 4:11 PM Ferruh Yigit <ferruh.yi...@intel.com> wrote: >> >> On 7/2/2019 9:07 PM, Junxiao Shi wrote: >>> I am battling a related problem as reported on >>> https://bugs.dpdk.org/show_bug.cgi?id=183 and this patch seems >>> relevant, so I applied this patch on >>> 196a46fab6eeb3ce2039e3bcaca80f8ba43ffc8d >>> >>> However, this patch does not work for me: >>> with CONFIG_RTE_LIBRTE_MBUF_DEBUG enabled, kni_free_mbufs's invocation of >>> rte_pktmbuf_free throws "bad mbuf pool" error. >>> >>> While all mbufs and segments in kni->rx_q now have physical addresses, >>> the mbufs and segments placed back to kni->free_q still have >>> (mis-)calculated >>> virtual address. The pa2va function is not working properly. >>> >>> Consequently, userspace side is passing wrong pointer to rte_pktmbuf_free, >>> so that application crashes with CONFIG_RTE_LIBRTE_MBUF_DEBUG enabled. >>> >> >> Hi Junxiao, >> >> I don't see any issue in the code, and as far as I tested not seeing any >> issue. >> >> Can you please provide more information how to reproduce the issue, is it >> only >> enabling "CONFIG_RTE_LIBRTE_MBUF_DEBUG" config? >> >> Thanks, >> ferruh
