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>
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>
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>
And if you want to use kni, you should do one of two action:
1. `insmod rte_kni.ko carrier=on` while init dpdk running environment.
2. or run `echo 1 > /sys/class/net/veth0/carrier` after enable veth0 up.
Refer #401, but this is not the real reason of #401, it is the DPDK's ENA driver can't work correctly in multi-processes.
And if you want to use kni, you should do one of two action:
1. `insmod rte_kni.ko carrier=on` while init dpdk running environment.
2. or run `echo 1 > /sys/class/net/veth0/carrier` after enable veth0 up.
Refer #401, but this is not the real reason of #401, it is the DPDK's ENA driver can't work correctly in multi-processes.
It should be default while handling large concurrent requests, otherwise
it will reduce the throughput.
But if there are only a little, you can set it to less than 100, even to
0, to reduce the delay of the connection.
It should be default while handling large concurrent requests, otherwise
it will reduce the throughput.
But if there are only a little, you can set it to less than 100, even to
0, to reduce the delay of the connection.