-
Notifications
You must be signed in to change notification settings - Fork 878
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ff_dpdk_init函数的代码重复问题 #4
Comments
写错了,应该是ff_global_cfg.dpdk.proc_id< 0 |
ghost
mentioned this issue
Jun 19, 2017
tanjianfeng
added a commit
to tanjianfeng/f-stack
that referenced
this issue
Dec 7, 2020
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf. freebsd mbufs are metadata used in freebsd stack, and their data pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have their own chain, like this: bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3 \ \ \ dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3 Considering the map relationship, - m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole chain of mbufs. - m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the specified mbuf segment. The current implementation in f-stack uses rte_pktmbuf_free() for m_free(). This leads to mbufs, which are still in use, be freed unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length, bsd will invoke m_free() to free the specified segment, however, the whole mbuf chain is freed by calling rte_pktmbuf_free(). #0 rte_pktmbuf_free (m=0x22006fb480) F-Stack#1 in ff_dpdk_pktmbuf_free (m=0x22006fb480) F-Stack#2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0) F-Stack#3 in mb_free_ext (m=0x7ffff7f82800) F-Stack#4 in m_free (m=0x7ffff7f82800) F-Stack#5 in sbcompress (sb=, m=0x7ffff7f82800, n=) F-Stack#6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0) The fix is straightforward. Use the correct API for segment free. Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com> Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
tanjianfeng
added a commit
to tanjianfeng/f-stack
that referenced
this issue
Dec 7, 2020
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf. freebsd mbufs are metadata used in freebsd stack, and their data pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have their own chain, like this: bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3 \ \ \ dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3 Considering the map relationship, - m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole chain of mbufs. - m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the specified mbuf segment. The current implementation in f-stack uses rte_pktmbuf_free() for m_free(). This leads to mbufs, which are still in use, be freed unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length, bsd will invoke m_free() to free the specified segment, however, the whole mbuf chain is freed by calling rte_pktmbuf_free(). #0 rte_pktmbuf_free (m=0x22006fb480) F-Stack#1 in ff_dpdk_pktmbuf_free (m=0x22006fb480) F-Stack#2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0) F-Stack#3 in mb_free_ext (m=0x7ffff7f82800) F-Stack#4 in m_free (m=0x7ffff7f82800) F-Stack#5 in sbcompress (sb=, m=0x7ffff7f82800, n=) F-Stack#6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0) The fix is straightforward. Use the correct API for segment free. Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com> Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
tanjianfeng
added a commit
to tanjianfeng/f-stack
that referenced
this issue
Dec 21, 2020
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf. freebsd mbufs are metadata used in freebsd stack, and their data pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have their own chain, like this: bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3 \ \ \ dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3 Considering the map relationship, - m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole chain of mbufs. - m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the specified mbuf segment. The current implementation in f-stack uses rte_pktmbuf_free() for m_free(). This leads to mbufs, which are still in use, be freed unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length, bsd will invoke m_free() to free the specified segment, however, the whole mbuf chain is freed by calling rte_pktmbuf_free(). #0 rte_pktmbuf_free (m=0x22006fb480) F-Stack#1 in ff_dpdk_pktmbuf_free (m=0x22006fb480) F-Stack#2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0) F-Stack#3 in mb_free_ext (m=0x7ffff7f82800) F-Stack#4 in m_free (m=0x7ffff7f82800) F-Stack#5 in sbcompress (sb=, m=0x7ffff7f82800, n=) F-Stack#6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0) The fix is straightforward. Use the correct API for segment free. Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com> Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
jfb8856606
pushed a commit
that referenced
this issue
Mar 6, 2021
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf. freebsd mbufs are metadata used in freebsd stack, and their data pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have their own chain, like this: bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3 \ \ \ dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3 Considering the map relationship, - m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole chain of mbufs. - m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the specified mbuf segment. The current implementation in f-stack uses rte_pktmbuf_free() for m_free(). This leads to mbufs, which are still in use, be freed unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length, bsd will invoke m_free() to free the specified segment, however, the whole mbuf chain is freed by calling rte_pktmbuf_free(). #0 rte_pktmbuf_free (m=0x22006fb480) #1 in ff_dpdk_pktmbuf_free (m=0x22006fb480) #2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0) #3 in mb_free_ext (m=0x7ffff7f82800) #4 in m_free (m=0x7ffff7f82800) #5 in sbcompress (sb=, m=0x7ffff7f82800, n=) #6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0) The fix is straightforward. Use the correct API for segment free. Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com> Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
jfb8856606
pushed a commit
that referenced
this issue
Mar 6, 2021
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf. freebsd mbufs are metadata used in freebsd stack, and their data pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have their own chain, like this: bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3 \ \ \ dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3 Considering the map relationship, - m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole chain of mbufs. - m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the specified mbuf segment. The current implementation in f-stack uses rte_pktmbuf_free() for m_free(). This leads to mbufs, which are still in use, be freed unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length, bsd will invoke m_free() to free the specified segment, however, the whole mbuf chain is freed by calling rte_pktmbuf_free(). #0 rte_pktmbuf_free (m=0x22006fb480) #1 in ff_dpdk_pktmbuf_free (m=0x22006fb480) #2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0) #3 in mb_free_ext (m=0x7ffff7f82800) #4 in m_free (m=0x7ffff7f82800) #5 in sbcompress (sb=, m=0x7ffff7f82800, n=) #6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0) The fix is straightforward. Use the correct API for segment free. Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com> Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
jfb8856606
pushed a commit
that referenced
this issue
Mar 6, 2021
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf. freebsd mbufs are metadata used in freebsd stack, and their data pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have their own chain, like this: bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3 \ \ \ dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3 Considering the map relationship, - m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole chain of mbufs. - m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the specified mbuf segment. The current implementation in f-stack uses rte_pktmbuf_free() for m_free(). This leads to mbufs, which are still in use, be freed unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length, bsd will invoke m_free() to free the specified segment, however, the whole mbuf chain is freed by calling rte_pktmbuf_free(). #0 rte_pktmbuf_free (m=0x22006fb480) #1 in ff_dpdk_pktmbuf_free (m=0x22006fb480) #2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0) #3 in mb_free_ext (m=0x7ffff7f82800) #4 in m_free (m=0x7ffff7f82800) #5 in sbcompress (sb=, m=0x7ffff7f82800, n=) #6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0) The fix is straightforward. Use the correct API for segment free. Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com> Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
jfb8856606
pushed a commit
that referenced
this issue
Jul 5, 2022
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf. freebsd mbufs are metadata used in freebsd stack, and their data pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have their own chain, like this: bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3 \ \ \ dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3 Considering the map relationship, - m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole chain of mbufs. - m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the specified mbuf segment. The current implementation in f-stack uses rte_pktmbuf_free() for m_free(). This leads to mbufs, which are still in use, be freed unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length, bsd will invoke m_free() to free the specified segment, however, the whole mbuf chain is freed by calling rte_pktmbuf_free(). #0 rte_pktmbuf_free (m=0x22006fb480) #1 in ff_dpdk_pktmbuf_free (m=0x22006fb480) #2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0) #3 in mb_free_ext (m=0x7ffff7f82800) #4 in m_free (m=0x7ffff7f82800) #5 in sbcompress (sb=, m=0x7ffff7f82800, n=) #6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0) The fix is straightforward. Use the correct API for segment free. Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com> Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
jfb8856606
pushed a commit
that referenced
this issue
Sep 2, 2022
Two kinds of mbuf are used in f-stack: freebsd mbuf and dpdk mbuf. freebsd mbufs are metadata used in freebsd stack, and their data pointers (m_data) point to dpdk mbuf's data (buf_addr). And they have their own chain, like this: bsd_mbuf1 -> bsd_mbuf2 -> bsd_mbuf3 \ \ \ dpdk_mbuf1 -> dpdk_mbuf2 -> dpdk_mbuf3 Considering the map relationship, - m_freem() is corresponding to rte_pktmbuf_free(), is to free the whole chain of mbufs. - m_free() is corresponding to rte_pktmbuf_free_seg(), is to free the specified mbuf segment. The current implementation in f-stack uses rte_pktmbuf_free() for m_free(). This leads to mbufs, which are still in use, be freed unexpectedly. For example, if the bsd_mbuf1 is trimed into zero length, bsd will invoke m_free() to free the specified segment, however, the whole mbuf chain is freed by calling rte_pktmbuf_free(). #0 rte_pktmbuf_free (m=0x22006fb480) #1 in ff_dpdk_pktmbuf_free (m=0x22006fb480) #2 in ff_mbuf_ext_free (m=0x7ffff7f82800, arg1=0x22006fb480, arg2=0x0) #3 in mb_free_ext (m=0x7ffff7f82800) #4 in m_free (m=0x7ffff7f82800) #5 in sbcompress (sb=, m=0x7ffff7f82800, n=) #6 in sbappendstream_locked (sb=, m=0x7ffff7f82800, flags=0) The fix is straightforward. Use the correct API for segment free. Reported-by: Yong-Hao Zou <yonghaoz1994@gmail.com> Signed-off-by: Jianfeng Tan <henry.tjf@antgroup.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
int
ff_dpdk_init(int argc, char **argv)
{
if (ff_global_cfg.dpdk.nb_procs < 1 ||
ff_global_cfg.dpdk.nb_procs > RTE_MAX_LCORE ||
ff_global_cfg.dpdk.proc_id >= ff_global_cfg.dpdk.nb_procs ||
ff_global_cfg.dpdk.nb_procs < 0) {
....
ff_global_cfg.dpdk.nb_procs < 1
ff_global_cfg.dpdk.nb_procs < 0
这个比较是不是重复了? 怎么考虑的?
The text was updated successfully, but these errors were encountered: