Skip to content
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

dpdk installation error #6

Closed
choleraehyq opened this issue May 14, 2017 · 3 comments
Closed

dpdk installation error #6

choleraehyq opened this issue May 14, 2017 · 3 comments

Comments

@choleraehyq
Copy link

choleraehyq commented May 14, 2017

Error occured when I was compiling dpdk using dpdk/tools/dpdk-setup.sh, both with x86_64-native-linuxapp-gcc and x86_64-native-linuxapp-clang.

  CC [M]  /home/cholerae/cxcode/f-stack/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.o
/home/cholerae/cxcode/f-stack/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c: In function ‘igb_kni_probe’:
/home/cholerae/cxcode/f-stack/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c:2475:30: error: ‘%d’ directive output may be truncated writing between 1 and 5 bytes into a region of size between 0 and 11 [-Werror=format-truncation=]
        "%d.%d, 0x%08x, %d.%d.%d",
                              ^~
/home/cholerae/cxcode/f-stack/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c:2475:8: note: directive argument in the range [0, 65535]
        "%d.%d, 0x%08x, %d.%d.%d",
        ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/cholerae/cxcode/f-stack/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/igb_main.c:2473:4: note: ‘snprintf’ output between 23 and 43 bytes into a destination of size 32
    snprintf(adapter->fw_version,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        sizeof(adapter->fw_version),
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        "%d.%d, 0x%08x, %d.%d.%d",
        ~~~~~~~~~~~~~~~~~~~~~~~~~~
        fw.eep_major, fw.eep_minor, fw.etrack_id,
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        fw.or_major, fw.or_build, fw.or_patch);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

[cholerae@x240s tools]$ gcc --version
gcc (GCC) 7.1.1 20170503 (Red Hat 7.1.1-1)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[cholerae@x240s tools]$ clang --version
clang version 3.9.1 (tags/RELEASE_391/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

[cholerae@x240s tools]$ uname -a
Linux x240s 4.11.0-2.fc26.x86_64 #1 SMP Tue May 9 15:24:49 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
@choleraehyq
Copy link
Author

I can successfully compile DPDK 17.05, but I don't know which version of DPDK does f-stack use.

@choleraehyq
Copy link
Author

choleraehyq commented May 14, 2017

I've updated DPDK to 17.05, and fixed for some compatible issues. DPDK and f-stack can be successfully compiled, but redis is still broken.

[cholerae@x240s redis-3.2.8]$ make
cd src && make all
make[1]: Entering directory '/data/f-stack/app/redis-3.2.8/src'
sh: ./mkreleasehdr.sh: Permission denied
    CC adlist.o
    CC quicklist.o
    CC ae.o
In file included from ae_ff_kqueue.c:37:0,
                 from ae.c:50:
/data/f-stack/lib/ff_api.h:103:57: warning: ‘struct timespec’ declared inside parameter list will not be visible outside of this definition or declaration
     struct kevent *eventlist, int nevents, const struct timespec *timeout);
                                                         ^~~~~~~~
In file included from ae.c:50:0:
ae_ff_kqueue.c: In function ‘aeApiPoll’:
ae_ff_kqueue.c:116:25: error: storage size of ‘timeout’ isn’t known
         struct timespec timeout;
                         ^~~~~~~
ae_ff_kqueue.c:116:25: warning: unused variable ‘timeout’ [-Wunused-variable]
make[1]: *** [Makefile:229: ae.o] Error 1
make[1]: Leaving directory '/data/f-stack/app/redis-3.2.8/src'
make: *** [Makefile:6: all] Error 2

I think the reason is that in linux the header containing struct timespec is time.h, but in freebsd is sys/time.h. In redis compilation we haven't overriden the include root to freebsd root. So struct timespec haven't been imported into ae_ff_kqueue.c.

@whl739
Copy link
Member

whl739 commented May 15, 2017

The version of dpdk that f-stack use is 16.07. And we didn't test it with gcc 5+.
The redis error is that we push the codes to github with permission loss.

@whl739 whl739 closed this as completed in bf96e9e May 15, 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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants