没有找到ff_api.h！编译报错 #2
Comments
ghost
mentioned this issue
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
In file included from src/core/nginx.c:8:0:
src/core/ngx_config.h:47:20: fatal error: ff_api.h: No such file or directory
#include "ff_api.h"
^
compilation terminated.
In file included from src/core/ngx_log.c:8:0:
src/core/ngx_config.h:47:20: fatal error: ff_api.h: No such file or directory
#include "ff_api.h"
^
compilation terminated.
make[1]: *** [objs/src/core/ngx_log.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [objs/src/core/nginx.o] Error 1
make[1]: Leaving directory `/data/f-stack/app/nginx-1.11.10'
make: *** [build] Error 2
The text was updated successfully, but these errors were encountered: