[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
2014-10-02 13:04, Matthew Hall: > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote: > > Just out of curiosity, whats the impetus behind a single shared library > > here? > > Is it just to ease application linking operations? If so, it almost seems > > to me > > that we should abandon the individual linking method and just use this as > > the > > default output (and do simmilarly for the static linking build) > > Not clear if you wrote "single shared library" on purpose instead of "single > static library". But for me the objective of COMBINE_LIBS usage would be > getting a "single static library" for my app, which just works, and > eliminates > need of start-group, end-group, weird library ordering issues, etc. I'm not > interested personally in a "shared library" because it'd run slower. > > Personally my preference would be to do both the single libs and multiple > libs > in static format by default. Disk space is cheap, let's maximize user freedom > and flexibility. But shared lib, since it performs less well, should be > discouraged by default, although allowed if needed... some people prefer it > because it's easier to patch security vulns if you can replace a buggy > library > for all the code on a system. We need to simplify build options. So I'm fine to remove COMBINE_LIBS option to always enable it. About making only one single static library, I think it's a good idea if it brings a real code simplification. So the conclusion is to nack this patchset in favor of above changes. Sergio, comments? -- Thomas
[dpdk-dev] Endless errors when starting multiple dpdk applications
Hi, I am trying to run multiple dpdk forwarding applications on VMs (KVM). The settings are as followings Dpdk version: master PF1 (port 2 of an Intel I350-T4 NIC) has two VFs: VF1(pci: :01:01.0), VF2 (pci: :01:02.0) PF2 (port 3 of an Intel I350-T4NIC ) has two VFs: VF3 (pci: :01:03.0), VF4 (pci: :01:04.0) The VFs are started by: sudo insmod igb.ko max_vfs=0,2,2,0 VMDQ=0,4,4,0 Dpdk-fwd-app-1 runs on the VM between VF1 and VF4 like this: sudo ./dpdk-app --syslog syslog -c 0x2 -n 2 -m 32 --use-device 01:01.0,01:04.0 --file-prefix 11 -- -q 4 If I only start single application, the packets are successfully forwarded. However when I start the second dpdk application: Dpdk-fwd-app-2 between VF2 and VF3 like this: sudo ./dpdk-app --syslog syslog -c 0x4 -n 2 -m 32 --use-device 01:02.0,01:03.0 --file-prefix 22 -- -q 4 Then endless error messages are printed out: -- .. CPU-2: CMTL: put_msg: tx buffer is full! CPU-2: CMTL: shmem_dc_transmit: Tx queue is full,dropping message! CPU-2: CMTL: Force disconnect! Error: user_called:1 ecode:0xf001 extra:0x .. -- I tried to change the parameters for: -c, -n, -q, -m. Still see the errors. Has any of you seen similar things before? Is this caused by any missing configurations? (Such as specifying separate TX/RX queues for different VFs, how to do this?) Thanks a lot. Best regards, Huimin She
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
On Fri, Oct 03, 2014 at 09:15:20AM +0200, Thomas Monjalon wrote: > 2014-10-02 13:04, Matthew Hall: > > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote: > > > Just out of curiosity, whats the impetus behind a single shared library > > > here? > > > Is it just to ease application linking operations? If so, it almost > > > seems to me > > > that we should abandon the individual linking method and just use this as > > > the > > > default output (and do simmilarly for the static linking build) > > > > Not clear if you wrote "single shared library" on purpose instead of > > "single > > static library". But for me the objective of COMBINE_LIBS usage would be > > getting a "single static library" for my app, which just works, and > > eliminates > > need of start-group, end-group, weird library ordering issues, etc. I'm not > > interested personally in a "shared library" because it'd run slower. > > > > Personally my preference would be to do both the single libs and multiple > > libs > > in static format by default. Disk space is cheap, let's maximize user > > freedom > > and flexibility. But shared lib, since it performs less well, should be > > discouraged by default, although allowed if needed... some people prefer it > > because it's easier to patch security vulns if you can replace a buggy > > library > > for all the code on a system. > > We need to simplify build options. So I'm fine to remove COMBINE_LIBS option > to always enable it. > About making only one single static library, I think it's a good idea if > it brings a real code simplification. > > So the conclusion is to nack this patchset in favor of above changes. > Sergio, comments? > Frankly I did not think of users linking against single and combine lib for different apps. I think If the goal is to simplify code then we should just provide one build option, either single or combine. Personally, I do not have a preference. So just to be clear, we would remove COMBINE_LIBS to always make a single combine lib or to create both single and combine? For the later option, would we be linking apps against single or combine libraries? Sergio > -- > Thomas
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
2014-10-03 09:10, Sergio Gonzalez Monroy: > On Fri, Oct 03, 2014 at 09:15:20AM +0200, Thomas Monjalon wrote: > > 2014-10-02 13:04, Matthew Hall: > > > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote: > > > > Just out of curiosity, whats the impetus behind a single shared library > > > > here? > > > > Is it just to ease application linking operations? If so, it almost > > > > seems to me > > > > that we should abandon the individual linking method and just use this > > > > as the > > > > default output (and do simmilarly for the static linking build) > > > > > > Not clear if you wrote "single shared library" on purpose instead of > > > "single > > > static library". But for me the objective of COMBINE_LIBS usage would be > > > getting a "single static library" for my app, which just works, and > > > eliminates > > > need of start-group, end-group, weird library ordering issues, etc. I'm > > > not > > > interested personally in a "shared library" because it'd run slower. > > > > > > Personally my preference would be to do both the single libs and multiple > > > libs > > > in static format by default. Disk space is cheap, let's maximize user > > > freedom > > > and flexibility. But shared lib, since it performs less well, should be > > > discouraged by default, although allowed if needed... some people prefer > > > it > > > because it's easier to patch security vulns if you can replace a buggy > > > library > > > for all the code on a system. > > > > We need to simplify build options. So I'm fine to remove COMBINE_LIBS option > > to always enable it. > > About making only one single static library, I think it's a good idea if > > it brings a real code simplification. > > > > So the conclusion is to nack this patchset in favor of above changes. > > Sergio, comments? > > > > Frankly I did not think of users linking against single and combine lib for > different apps. > I think If the goal is to simplify code then we should just provide one build > option, either single or combine. Personally, I do not have a preference. > > So just to be clear, we would remove COMBINE_LIBS to always make a single > combine > lib or to create both single and combine? > For the later option, would we be linking apps against single or combine > libraries? The proposal is to always build single (combined) lib AND to build separated libs in case of shared libraries. For static library: only one single (combined) static library. -- Thomas
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
On Thu, Oct 02, 2014 at 04:24:51PM -0400, Neil Horman wrote: > On Thu, Oct 02, 2014 at 01:04:20PM -0700, Matthew Hall wrote: > > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote: > > > Just out of curiosity, whats the impetus behind a single shared library > > > here? > > > Is it just to ease application linking operations? If so, it almost > > > seems to me > > > that we should abandon the individual linking method and just use this as > > > the > > > default output (and do simmilarly for the static linking build) > > > > > > Neil > > > > Not clear if you wrote "single shared library" on purpose instead of > > "single > > static library". But for me the objective of COMBINE_LIBS usage would be > > getting a "single static library" for my app, which just works, and > > eliminates > > need of start-group, end-group, weird library ordering issues, etc. I'm not > > interested personally in a "shared library" because it'd run slower. > > > Actually I do need to revise my question, thank you. you're right, doing a > single archive for static builds makes the most sense, because you wind up > with > a static binary anyway, and as such, theres really no need for multiple dpdk > archives. We should just create a single dpdk.a file and be done with it. > > The shared libraries are a different story. While at first it made sense to > me > to merge them all, it actually doesn't because PMD's might be built > independently and shipped separate from the core library. Sorry Neil, could you elaborate a bit on why it would not make sense to have a single/combined shared library? Sergio > > > Personally my preference would be to do both the single libs and multiple > > libs > > in static format by default. Disk space is cheap, let's maximize user > > freedom > > and flexibility. But shared lib, since it performs less well, should be > > discouraged by default, although allowed if needed... some people prefer it > > because it's easier to patch security vulns if you can replace a buggy > > library > > for all the code on a system. > > > This seems somewhat irrelevant to the patch. The default configuration is > already the way you want it to be, shared library performance is actually very > close to static performance, and yes, people can choose how they want to > build. > Not sure what point your trying to make here. > Neil > > > Matthew. > >
[dpdk-dev] [PATCH] Fix linking errors when CONFIG_RTE_BUILD_SHARED_LIB is enabled
On Thu, Oct 02, 2014 at 06:05:09PM +0900, Tetsuya Mukawa wrote: > (2014/10/02 17:53), Sergio Gonzalez Monroy wrote: > > On Thu, Oct 02, 2014 at 05:28:04PM +0900, Tetsuya Mukawa wrote: > >> (2014/10/02 17:12), Sergio Gonzalez Monroy wrote: > >>> On Thu, Oct 02, 2014 at 11:48:37AM +0900, Tetsuya Mukawa wrote: > >>> > $ gcc -m64 -pthread -fPIC -march=native -DRTE_MACHINE_CPUFLAG_SSE > -DRTE_MACHINE_CPUFLAG_SSE2 -DRTE_MACHINE_CPUFLAG_SSE3 > -DRTE_MACHINE_CPUFLAG_SSSE3 -DRTE_MACHINE_CPUFLAG_SSE4_1 > -DRTE_MACHINE_CPUFLAG_SSE4_2 -DRTE_MACHINE_CPUFLAG_AES > -DRTE_MACHINE_CPUFLAG_PCLMULQDQ -DRTE_MACHINE_CPUFLAG_AVX > -DRTE_MACHINE_CPUFLAG_F16C > -DRTE_COMPILE_TIME_CPUFLAGS=RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2,RTE_CPUFLAG_SSE3,RTE_CPUFLAG_SSSE3,RTE_CPUFLAG_SSE4_1,RTE_CPUFLAG_SSE4_2,RTE_CPUFLAG_AES,RTE_CPUFLAG_PCLMULQDQ,RTE_CPUFLAG_AVX,RTE_CPUFLAG_F16C > -I/home/mukawa/tmp/dpdk/x86_64-native-linuxapp-gcc/include -include > /home/mukawa/tmp/dpdk/x86_64-native-linuxapp-gcc/include/rte_config.h > -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes > -Wmissing-declarations -Wold-style-definition -Wpointer-arith > -Wcast-align -Wnested-externs -Wcast-qual -Wformat-nonliteral > -Wformat-security -Wundef -Wwrite-strings -Wl,-Map=testacl.map,--cref > -o testacl main.o -Wl,-export-dynamic > -L/home/mukawa/tmp/dpdk/x86_64-native-linuxapp-gcc/lib > -L/home/mukawa/tmp/dpdk/x86_64-native-linuxapp-gcc/lib > -Wl,--whole-archive -Wl,-lrte_distributor -Wl,-lrte_kni > -Wl,-lrte_pipeline -Wl,-lrte_table -Wl,-lrte_port -Wl,-lrte_timer > -Wl,-lrte_hash -Wl,-lrte_lpm -Wl,-lrte_power -Wl,-lrte_acl > -Wl,-lrte_meter -Wl,-lrte_sched -Wl,-lm -Wl,-lrt -Wl,--start-group > -Wl,-lrte_kvargs -Wl,-lrte_mbuf -Wl,-lrte_ip_frag -Wl,-lethdev > -Wl,-lrte_malloc -Wl,-lrte_mempool -Wl,-lrte_ring -Wl,-lrte_eal > -Wl,-lrte_cmdline -Wl,-lrte_cfgfile -Wl,-lrte_pmd_bond -Wl,-lrt > -Wl,-lm -Wl,-lgcc_s -Wl,-ldl -Wl,--end-group -Wl,--no-whole-archive > /home/mukawa/tmp/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.so: > undefined reference to `rte_mempool_lookup' > /home/mukawa/tmp/dpdk/x86_64-native-linuxapp-gcc/lib/librte_eal.so: > undefined reference to `rte_mempool_create' collect2: error: ld > returned 1 exit status > >>> Hi Tetsuya, > >>> > >>> Would you mind posting the output of the last command adding the option > >>> '-v'? > >> Sure, here is. > >> > >> $ gcc -m64 -pthread -fPIC -march=native -DRTE_MACHINE_CPUFLAG_SSE > >> -DRTE_MACHINE_CPUFLAG_SSE2 -DRTE_MACHINE_CPUFLAG_SSE3 > >> -DRTE_MACHINE_CPUFLAG_SSSE3 -DRTE_MACHINE_CPUFLAG_SSE4_1 > >> -DRTE_MACHINE_CPUFLAG_SSE4_2 -DRTE_MACHINE_CPUFLAG_AES > >> -DRTE_MACHINE_CPUFLAG_PCLMULQDQ -DRTE_MACHINE_CPUFLAG_AVX > >> -DRTE_MACHINE_CPUFLAG_F16C > >> -DRTE_COMPILE_TIME_CPUFLAGS=RTE_CPUFLAG_SSE,RTE_CPUFLAG_SSE2,RTE_CPUFLAG_SSE3,RTE_CPUFLAG_SSSE3,RTE_CPUFLAG_SSE4_1,RTE_CPUFLAG_SSE4_2,RTE_CPUFLAG_AES,RTE_CPUFLAG_PCLMULQDQ,RTE_CPUFLAG_AVX,RTE_CPUFLAG_F16C > >> > >> -I/home/mukawa/tmp/dpdk/x86_64-native-linuxapp-gcc/include -include > >> /home/mukawa/tmp/dpdk/x86_64-native-linuxapp-gcc/include/rte_config.h -W > >> -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes > >> -Wmissing-declarations -Wold-style-definition -Wpointer-arith > >> -Wcast-align -Wnested-externs -Wcast-qual -Wformat-nonliteral > >> -Wformat-security -Wundef -Wwrite-strings -Wl,-Map=testacl.map,--cref > >> -o testacl main.o -Wl,-export-dynamic > >> -L/home/mukawa/tmp/dpdk/x86_64-native-linuxapp-gcc/lib > >> -L/home/mukawa/tmp/dpdk/x86_64-native-linuxapp-gcc/lib > >> -Wl,--whole-archive -Wl,-lrte_distributor -Wl,-lrte_kni > >> -Wl,-lrte_pipeline -Wl,-lrte_table -Wl,-lrte_port -Wl,-lrte_timer > >> -Wl,-lrte_hash -Wl,-lrte_lpm -Wl,-lrte_power -Wl,-lrte_acl > >> -Wl,-lrte_meter -Wl,-lrte_sched -Wl,-lm -Wl,-lrt -Wl,--start-group > >> -Wl,-lrte_kvargs -Wl,-lrte_mbuf -Wl,-lrte_ip_frag -Wl,-lethdev > >> -Wl,-lrte_malloc -Wl,-lrte_mempool -Wl,-lrte_ring -Wl,-lrte_eal > >> -Wl,-lrte_cmdline -Wl,-lrte_cfgfile -Wl,-lrte_pmd_bond -Wl,-lrt -Wl,-lm > >> -Wl,-lgcc_s -Wl,-ldl -Wl,--end-group -Wl,--no-whole-archive -v > >> Using built-in specs. > >> COLLECT_GCC=gcc > >> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper > >> Target: x86_64-linux-gnu > >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu > >> 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs > >> --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr > >> --program-suffix=-4.8 --enable-shared --enable-linker-build-id > >> --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > >> --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib > >> --enable-nls --with-sysroot=/ --enable-clocale=gnu > >> --enable-libstdcxx-debug --enable-libstdcxx-time=yes > >> --enable-gnu-unique-object --disable-libmudflap --enable-plugin > >> --with-system-zlib --disable-browser
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
On Fri, Oct 03, 2014 at 11:31:10AM +0100, Sergio Gonzalez Monroy wrote: > On Thu, Oct 02, 2014 at 04:24:51PM -0400, Neil Horman wrote: > > On Thu, Oct 02, 2014 at 01:04:20PM -0700, Matthew Hall wrote: > > > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote: > > > > Just out of curiosity, whats the impetus behind a single shared library > > > > here? > > > > Is it just to ease application linking operations? If so, it almost > > > > seems to me > > > > that we should abandon the individual linking method and just use this > > > > as the > > > > default output (and do simmilarly for the static linking build) > > > > > > > > Neil > > > > > > Not clear if you wrote "single shared library" on purpose instead of > > > "single > > > static library". But for me the objective of COMBINE_LIBS usage would be > > > getting a "single static library" for my app, which just works, and > > > eliminates > > > need of start-group, end-group, weird library ordering issues, etc. I'm > > > not > > > interested personally in a "shared library" because it'd run slower. > > > > > Actually I do need to revise my question, thank you. you're right, doing a > > single archive for static builds makes the most sense, because you wind up > > with > > a static binary anyway, and as such, theres really no need for multiple dpdk > > archives. We should just create a single dpdk.a file and be done with it. > > > > The shared libraries are a different story. While at first it made sense > > to me > > to merge them all, it actually doesn't because PMD's might be built > > independently and shipped separate from the core library. > > Sorry Neil, could you elaborate a bit on why it would not make sense to have > a > single/combined shared library? > > Sergio > Sorry, I wasn't trying to assert that it doesn't make sense to have a single shared library, but rather I was trying to assert that we should only _ever_ build a single shared library. I assert this because to create a single shared library destroys part of the advantage that DSO's have. Namely that they allow for selective hardware enablement in the field. I.e. you can ship your pmd's pacakged separately from your core, and not have to update your application (and pull them in via the -d option on the command line). If the dpdk builds everything as a single binary, then you may end up needing to pull in pmds that you don't yet need to support. In short, my initial idea was dumb :) Neil > > > > > Personally my preference would be to do both the single libs and multiple > > > libs > > > in static format by default. Disk space is cheap, let's maximize user > > > freedom > > > and flexibility. But shared lib, since it performs less well, should be > > > discouraged by default, although allowed if needed... some people prefer > > > it > > > because it's easier to patch security vulns if you can replace a buggy > > > library > > > for all the code on a system. > > > > > This seems somewhat irrelevant to the patch. The default configuration is > > already the way you want it to be, shared library performance is actually > > very > > close to static performance, and yes, people can choose how they want to > > build. > > Not sure what point your trying to make here. > > Neil > > > > > Matthew. > > > >
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
On Fri, Oct 03, 2014 at 10:27:30AM +0200, Thomas Monjalon wrote: > 2014-10-03 09:10, Sergio Gonzalez Monroy: > > On Fri, Oct 03, 2014 at 09:15:20AM +0200, Thomas Monjalon wrote: > > > 2014-10-02 13:04, Matthew Hall: > > > > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote: > > > > > Just out of curiosity, whats the impetus behind a single shared > > > > > library here? > > > > > Is it just to ease application linking operations? If so, it almost > > > > > seems to me > > > > > that we should abandon the individual linking method and just use > > > > > this as the > > > > > default output (and do simmilarly for the static linking build) > > > > > > > > Not clear if you wrote "single shared library" on purpose instead of > > > > "single > > > > static library". But for me the objective of COMBINE_LIBS usage would > > > > be > > > > getting a "single static library" for my app, which just works, and > > > > eliminates > > > > need of start-group, end-group, weird library ordering issues, etc. I'm > > > > not > > > > interested personally in a "shared library" because it'd run slower. > > > > > > > > Personally my preference would be to do both the single libs and > > > > multiple libs > > > > in static format by default. Disk space is cheap, let's maximize user > > > > freedom > > > > and flexibility. But shared lib, since it performs less well, should be > > > > discouraged by default, although allowed if needed... some people > > > > prefer it > > > > because it's easier to patch security vulns if you can replace a buggy > > > > library > > > > for all the code on a system. > > > > > > We need to simplify build options. So I'm fine to remove COMBINE_LIBS > > > option > > > to always enable it. > > > About making only one single static library, I think it's a good idea if > > > it brings a real code simplification. > > > > > > So the conclusion is to nack this patchset in favor of above changes. > > > Sergio, comments? > > > > > > > Frankly I did not think of users linking against single and combine lib for > > different apps. > > I think If the goal is to simplify code then we should just provide one > > build > > option, either single or combine. Personally, I do not have a preference. > > > > So just to be clear, we would remove COMBINE_LIBS to always make a single > > combine > > lib or to create both single and combine? > > For the later option, would we be linking apps against single or combine > > libraries? > > The proposal is to always build single (combined) lib AND to build separated > libs in case of shared libraries. > For static library: only one single (combined) static library. > This makes good sense to me. A single archive is just easier in the static case, since the resulting binary will strip out unused code anyway, and multiple libraries are needed in the shared case so that we don't wind up having to load more code than is needed at run time. Neil > -- > Thomas >
[dpdk-dev] [PATCH 0/7] Patches to split architecture specific operations from DPDK
Hello Chao,
On Fri, Sep 26, 2014 at 11:33 AM, Chao Zhu wrote:
> The set of patches split x86 architecture specific operations from DPDK
> and put them to the
> arch directories of i686 and x86_64 architecture. This will make the
> adpotion of DPDK much easier
> on other computer architecture. For a new architecture, just add an
> architecture specific
> directory and necessary building configuration files, then DPDK can
> support it.
>
>
Here is a different approach for the headers splitting.
If we are going to support multiple architectures, the best would be to
have a specific header for each arch which implements a common API (no need
for any _arch suffix).
These headers would be located in lib/librte_eal/common/include/arch/$arch/
rather than lib/librte_eal/common/include/$arch/arch/ (which looks odd to
me).
Makefiles can add some -I for dpdk to build itself (and we can remove those
symlinks from the makefiles).
Makefiles only install the specific headers in RTE_SDK/include for use by
applications.
For common code and documentation, we can add a "generic" directory in
lib/librte_eal/common/include (or "arch-generic", or "shared" ... any
better idea ?).
DPDK makefiles installs the generic headers in RTE_SDK/include/generic.
arch headers (like rte_atomic.h) include the generic one
().
These generic headers can be implemented using compiler intrinsics when
possible.
They also include the doxygen stuff in a single place.
This would look like something like this, for rte_atomic.h :
- in DPDK sources
$ ls lib/librte_eal/common/include/*/rte_atomic.h
lib/librte_eal/common/include/i686/rte_atomic.h
lib/librte_eal/common/include/x86_64/rte_atomic.h
lib/librte_eal/common/include/generic/rte_atomic.h
- in installed RTE_SDK
$ ls RTE_SDK/include/{,*/}rte_atomic.h
RTE_SDK/include/rte_atomic.h
RTE_SDK/include/generic/rte_atomic.h
Comments ?
I am only focusing on the first patchset at the moment, but if we can find
consensus here, a respin of the two patchsets would be great.
Thanks.
--
David Marchand
[dpdk-dev] [PATCH 0/7] Patches to split architecture specific operations from DPDK
On Fri, Oct 03, 2014 at 03:21:53PM +0200, David Marchand wrote:
> Hello Chao,
>
> On Fri, Sep 26, 2014 at 11:33 AM, Chao Zhu wrote:
>
> > The set of patches split x86 architecture specific operations from DPDK
> > and put them to the
> > arch directories of i686 and x86_64 architecture. This will make the
> > adpotion of DPDK much easier
> > on other computer architecture. For a new architecture, just add an
> > architecture specific
> > directory and necessary building configuration files, then DPDK can
> > support it.
> >
> >
> Here is a different approach for the headers splitting.
>
> If we are going to support multiple architectures, the best would be to
> have a specific header for each arch which implements a common API (no need
> for any _arch suffix).
> These headers would be located in lib/librte_eal/common/include/arch/$arch/
> rather than lib/librte_eal/common/include/$arch/arch/ (which looks odd to
> me).
> Makefiles can add some -I for dpdk to build itself (and we can remove those
> symlinks from the makefiles).
> Makefiles only install the specific headers in RTE_SDK/include for use by
> applications.
>
> For common code and documentation, we can add a "generic" directory in
> lib/librte_eal/common/include (or "arch-generic", or "shared" ... any
> better idea ?).
> DPDK makefiles installs the generic headers in RTE_SDK/include/generic.
> arch headers (like rte_atomic.h) include the generic one
> ().
>
> These generic headers can be implemented using compiler intrinsics when
> possible.
> They also include the doxygen stuff in a single place.
>
>
> This would look like something like this, for rte_atomic.h :
> - in DPDK sources
> $ ls lib/librte_eal/common/include/*/rte_atomic.h
> lib/librte_eal/common/include/i686/rte_atomic.h
> lib/librte_eal/common/include/x86_64/rte_atomic.h
> lib/librte_eal/common/include/generic/rte_atomic.h
>
> - in installed RTE_SDK
> $ ls RTE_SDK/include/{,*/}rte_atomic.h
> RTE_SDK/include/rte_atomic.h
> RTE_SDK/include/generic/rte_atomic.h
>
> Comments ?
>
>
> I am only focusing on the first patchset at the moment, but if we can find
> consensus here, a respin of the two patchsets would be great.
>
> Thanks.
>
> --
> David Marchand
I would have no objection to such a scheme. However, I'm not seeing much
advantage over the existing way of doing things. I think I'd rather see the
proposed patch sets merged first and then any additional cleanup done,
rather than holding up a worthwhile submission for a bit of tidy-up.
/Bruce
[dpdk-dev] [PATCH 0/3] Adjust mbuf flag definitions
This patchset does some cleanup work on the mbuf flag definitions. It is based off the ideas discussed in the previous RFC patch. [Ref: http://thread.gmane.org/gmane.comp.networking.dpdk.devel/6155] Summary of changes: * Adjust TX flags to start at bit 55 in flags field and work downwards, leaving bits 56 upward reserved for generic mbuf flags, i.e. non-offload flags. * Update the existing RX flags to be in a similar format to the newly redefined TX flags for clarity. * Finally we add a comment for the ctrl mbuf flag to ensure all flags are properly documented. Bruce Richardson (3): mbuf: move TX flags to group them near end of field mbuf: RX flag format update mbuf: add comment for ctrl mbuf flag lib/librte_mbuf/rte_mbuf.h | 65 +- 1 file changed, 36 insertions(+), 29 deletions(-) -- 1.9.3
[dpdk-dev] [PATCH 3/3] mbuf: add comment for ctrl mbuf flag
Add in a doxygen comment for the ctrl mbuf flag definition.
Signed-off-by: Bruce Richardson
---
lib/librte_mbuf/rte_mbuf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index a4487bb..8581e15 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -115,7 +115,7 @@ extern "C" {
#define PKT_TX_IEEE1588_TMST (1ULL << 51) /**< TX IEEE1588 packet to
timestamp. */
/* Use final bit of flags to indicate a control mbuf */
-#define CTRL_MBUF_FLAG (1ULL << 63)
+#define CTRL_MBUF_FLAG (1ULL << 63) /**< Mbuf contains control data */
/**
* Bit Mask to indicate what bits required for building TX context
--
1.9.3
[dpdk-dev] [PATCH 1/3] mbuf: move TX flags to group them near end of field
This patch takes the existing TX flags defined for the mbuf and shifts
each uniquely defined one left so that additional RX flags can be
defined without having RX and TX flags mixed together. Under the new
scheme, RX flags start at bit 0 and work left, TX flags start at bit 55
and work right, and bits 56-63 are reserved for generic mbuf use, not
for offloads.
Signed-off-by: Bruce Richardson
---
lib/librte_mbuf/rte_mbuf.h | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 1c6e115..7aa507e 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -68,6 +68,12 @@ extern "C" {
/*
* Packet Offload Features Flags. It also carry packet type information.
* Critical resources. Both rx/tx shared these bits. Be cautious on any change
+ *
+ * - RX flags start at bit position zero, and get added to the left of previous
+ * flags.
+ * - The most-significant 8 bits are reserved for generic mbuf flags
+ * - TX flags therefore start at bit position 55 (i.e. 63-8), and new flags get
+ * added to the right of the previously defined flags
*/
#define PKT_RX_VLAN_PKT 0x0001 /**< RX packet is a 802.1q VLAN packet. */
#define PKT_RX_RSS_HASH 0x0002 /**< RX packet with RSS hash result. */
@@ -86,26 +92,27 @@ extern "C" {
#define PKT_RX_IEEE1588_PTP 0x0200 /**< RX IEEE1588 L2 Ethernet PT Packet. */
#define PKT_RX_IEEE1588_TMST 0x0400 /**< RX IEEE1588 L2/L4 timestamped
packet.*/
-#define PKT_TX_VLAN_PKT 0x0800 /**< TX packet is a 802.1q VLAN packet. */
-#define PKT_TX_IP_CKSUM 0x1000 /**< IP cksum of TX pkt. computed by NIC.
*/
-#define PKT_TX_IPV4_CSUM 0x1000 /**< Alias of PKT_TX_IP_CKSUM. */
+#define PKT_TX_VLAN_PKT (1ULL << 55) /**< TX packet is a 802.1q VLAN
packet. */
+#define PKT_TX_IP_CKSUM (1ULL << 54) /**< IP cksum of TX pkt. computed by
NIC. */
+#define PKT_TX_IPV4_CSUM PKT_TX_IP_CKSUM /**< Alias of PKT_TX_IP_CKSUM. */
#define PKT_TX_IPV4 PKT_RX_IPV4_HDR /**< IPv4 with no IP checksum
offload. */
#define PKT_TX_IPV6 PKT_RX_IPV6_HDR /**< IPv6 packet */
/*
- * Bit 14~13 used for L4 packet type with checksum enabled.
+ * Bits 52+53 used for L4 packet type with checksum enabled.
* 00: Reserved
* 01: TCP checksum
* 10: SCTP checksum
* 11: UDP checksum
*/
-#define PKT_TX_L4_MASK 0x6000 /**< Mask bits for L4 checksum offload
request. */
-#define PKT_TX_L4_NO_CKSUM 0x /**< Disable L4 cksum of TX pkt. */
-#define PKT_TX_TCP_CKSUM 0x2000 /**< TCP cksum of TX pkt. computed by NIC.
*/
-#define PKT_TX_SCTP_CKSUM0x4000 /**< SCTP cksum of TX pkt. computed by
NIC. */
-#define PKT_TX_UDP_CKSUM 0x6000 /**< UDP cksum of TX pkt. computed by NIC.
*/
-/* Bit 15 */
-#define PKT_TX_IEEE1588_TMST 0x8000 /**< TX IEEE1588 packet to timestamp. */
+#define PKT_TX_L4_NO_CKSUM (0ULL << 52) /**< Disable L4 cksum of TX pkt. */
+#define PKT_TX_TCP_CKSUM (1ULL << 52) /**< TCP cksum of TX pkt. computed
by NIC. */
+#define PKT_TX_SCTP_CKSUM(2ULL << 52) /**< SCTP cksum of TX pkt. computed
by NIC. */
+#define PKT_TX_UDP_CKSUM (3ULL << 52) /**< UDP cksum of TX pkt. computed
by NIC. */
+#define PKT_TX_L4_MASK (3ULL << 52) /**< Mask for L4 cksum offload
request. */
+
+/* Bit 51 - IEEE1588*/
+#define PKT_TX_IEEE1588_TMST (1ULL << 51) /**< TX IEEE1588 packet to
timestamp. */
/* Use final bit of flags to indicate a control mbuf */
#define CTRL_MBUF_FLAG (1ULL << 63)
--
1.9.3
[dpdk-dev] [PATCH 2/3] mbuf: RX flag format update
Update the format of the RX flags to match that of the TX flags. In
general the flags are now specified as "1ULL << X", with a few
exceptions.
Signed-off-by: Bruce Richardson
---
lib/librte_mbuf/rte_mbuf.h | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 7aa507e..a4487bb 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -75,22 +75,22 @@ extern "C" {
* - TX flags therefore start at bit position 55 (i.e. 63-8), and new flags get
* added to the right of the previously defined flags
*/
-#define PKT_RX_VLAN_PKT 0x0001 /**< RX packet is a 802.1q VLAN packet. */
-#define PKT_RX_RSS_HASH 0x0002 /**< RX packet with RSS hash result. */
-#define PKT_RX_FDIR 0x0004 /**< RX packet with FDIR infos. */
-#define PKT_RX_L4_CKSUM_BAD 0x0008 /**< L4 cksum of RX pkt. is not OK. */
-#define PKT_RX_IP_CKSUM_BAD 0x0010 /**< IP cksum of RX pkt. is not OK. */
-#define PKT_RX_EIP_CKSUM_BAD 0x /**< External IP header checksum error. */
-#define PKT_RX_OVERSIZE 0x /**< Num of desc of an RX pkt oversize. */
-#define PKT_RX_HBUF_OVERFLOW 0x /**< Header buffer overflow. */
-#define PKT_RX_RECIP_ERR 0x /**< Hardware processing error. */
-#define PKT_RX_MAC_ERR 0x /**< MAC error. */
-#define PKT_RX_IPV4_HDR 0x0020 /**< RX packet with IPv4 header. */
-#define PKT_RX_IPV4_HDR_EXT 0x0040 /**< RX packet with extended IPv4 header.
*/
-#define PKT_RX_IPV6_HDR 0x0080 /**< RX packet with IPv6 header. */
-#define PKT_RX_IPV6_HDR_EXT 0x0100 /**< RX packet with extended IPv6 header.
*/
-#define PKT_RX_IEEE1588_PTP 0x0200 /**< RX IEEE1588 L2 Ethernet PT Packet. */
-#define PKT_RX_IEEE1588_TMST 0x0400 /**< RX IEEE1588 L2/L4 timestamped
packet.*/
+#define PKT_RX_VLAN_PKT (1ULL << 0) /**< RX packet is a 802.1q VLAN
packet. */
+#define PKT_RX_RSS_HASH (1ULL << 1) /**< RX packet with RSS hash result.
*/
+#define PKT_RX_FDIR (1ULL << 2) /**< RX packet with FDIR infos. */
+#define PKT_RX_L4_CKSUM_BAD (1ULL << 3) /**< L4 cksum of RX pkt. is not OK.
*/
+#define PKT_RX_IP_CKSUM_BAD (1ULL << 4) /**< IP cksum of RX pkt. is not OK.
*/
+#define PKT_RX_EIP_CKSUM_BAD (0ULL << 0) /**< External IP header checksum
error. */
+#define PKT_RX_OVERSIZE (0ULL << 0) /**< Num of desc of an RX pkt
oversize. */
+#define PKT_RX_HBUF_OVERFLOW (0ULL << 0) /**< Header buffer overflow. */
+#define PKT_RX_RECIP_ERR (0ULL << 0) /**< Hardware processing error. */
+#define PKT_RX_MAC_ERR (0ULL << 0) /**< MAC error. */
+#define PKT_RX_IPV4_HDR (1ULL << 5) /**< RX packet with IPv4 header. */
+#define PKT_RX_IPV4_HDR_EXT (1ULL << 6) /**< RX packet with extended IPv4
header. */
+#define PKT_RX_IPV6_HDR (1ULL << 7) /**< RX packet with IPv6 header. */
+#define PKT_RX_IPV6_HDR_EXT (1ULL << 8) /**< RX packet with extended IPv6
header. */
+#define PKT_RX_IEEE1588_PTP (1ULL << 9) /**< RX IEEE1588 L2 Ethernet PT
Packet. */
+#define PKT_RX_IEEE1588_TMST (1ULL << 10) /**< RX IEEE1588 L2/L4 timestamped
packet.*/
#define PKT_TX_VLAN_PKT (1ULL << 55) /**< TX packet is a 802.1q VLAN
packet. */
#define PKT_TX_IP_CKSUM (1ULL << 54) /**< IP cksum of TX pkt. computed by
NIC. */
--
1.9.3
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
On Fri, Oct 03, 2014 at 09:15:20AM +0200, Thomas Monjalon wrote: > We need to simplify build options. So I'm fine to remove COMBINE_LIBS option > to always enable it. > About making only one single static library, I think it's a good idea if > it brings a real code simplification. > > So the conclusion is to nack this patchset in favor of above changes. > Sergio, comments? It works for me... I love COMBINE_LIBS... but it won't be necessarily backward compatible with people already linking against existing DPDK. Hence why I proposed just always building the per-feature static libs and always building the combined lib rather than forcing people to do one or the other. Also different people might have different configs where they link in greater or fewer or different PMD's or features in different configs of their build... they might be annoyed if their separate libs disappear. Matthew.
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
On Fri, Oct 03, 2014 at 10:27:30AM +0200, Thomas Monjalon wrote: > The proposal is to always build single (combined) lib AND to build separated > libs in case of shared libraries. > For static library: only one single (combined) static library. In the static case, this won't be backward compatible for people with existing linking, and won't allow people to pick which PMD's to activate without recompiling DPDK. If you're OK with that then I don't have an issue. But some others may not like it. Matthew.
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
On Fri, Oct 03, 2014 at 07:32:34AM -0400, Neil Horman wrote: > This makes good sense to me. A single archive is just easier in the static > case, since the resulting binary will strip out unused code anyway, and > multiple > libraries are needed in the shared case so that we don't wind up having to > load > more code than is needed at run time. > > Neil This assertion is not true. Because the DPDK doesn't work if you don't specify the whole-archive link option. Which explicitly prevents stripping out any "unused code". Otherwise your PMD's will refuse to initialize. This along with backward compatibility is why I was advising to build the full static library and the sublibraries so it will just work for everybody by default. Matthew.
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
On Fri, Oct 03, 2014 at 11:17:13AM -0700, Matthew Hall wrote: > On Fri, Oct 03, 2014 at 07:32:34AM -0400, Neil Horman wrote: > > This makes good sense to me. A single archive is just easier in the static > > > > case, since the resulting binary will strip out unused code anyway, and > > multiple > > libraries are needed in the shared case so that we don't wind up having to > > load > > more code than is needed at run time. > > > > Neil > > This assertion is not true. Because the DPDK doesn't work if you don't > specify > the whole-archive link option. Which explicitly prevents stripping out any > "unused code". Otherwise your PMD's will refuse to initialize. > I'm not asserting that you remove the --whole-archive option, only that the we assemble all objects into a single archive during the SDK build. Its just a convienience, because the application binary result will be the same, regardless of weather you link several small archives, or a single large one (because of the aforementioned --whole-archive option). The only remaining issue is events where an application doesn't need (for example) the acl library, or other optional library. With a single archive, you get everything you build even if you don't need it. But presumably if you're building a static binary, you're likely building the dpdk as well and can configure optional libraries out of the build. Separate libraries are more a need for downstream distributors/packagers, who use dynamic shared objects anyway. > This along with backward compatibility is why I was advising to build the > full > static library and the sublibraries so it will just work for everybody by > default. > Backward compatibilty? the DPDK doesn't yet provide run time compatibility between releases (something I've been trying to change). Nobody provides compile time compatibility. To do so would require fixing API's permenently. Neil
[dpdk-dev] Clang reporting a problem when adding another member initialization.
I run into a problem with Clang report problem when I tried to add another
member to the static initializer of the following in file ixgbe_rxtx_vec.c
int
ixgbe_rxq_vec_setup(struct igb_rx_queue *rxq)
{
static struct rte_mbuf mb_def = {
.nb_segs = 1,
.data_off = RTE_PKTMBUF_HEADROOM,
.reserved2 = 0x,
#ifdef RTE_MBUF_REFCNT
{ .refcnt = 1, }
#endif
};
== Build lib/librte_pmd_ixgbe
CC ixgbe_rxtx_vec.o
/home/keithw/projects/dpdk-code/dpdk/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:739:5:
error: designator in initializer for scalar type 'uint16_t' (aka 'unsigned
short')
{ .refcnt = 1, }
^~~
1 error generated.
I moved the ?,? in the { } to outside and still the same problem.
int
ixgbe_rxq_vec_setup(struct igb_rx_queue *rxq)
{
static struct rte_mbuf mb_def = {
.nb_segs = 1,
.data_off = RTE_PKTMBUF_HEADROOM,
.reserverd2 = (uint16_t)0x,
#ifdef RTE_MBUF_REFCNT
{ .refcnt = 1 },
#endif
};
== Build lib/librte_pmd_ixgbe
CC ixgbe_rxtx_vec.o
/home/keithw/projects/dpdk-code/dpdk/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:739:5:
error: designator in initializer for scalar type 'uint16_t' (aka 'unsigned
short')
{ .refcnt = 1 },
^~~
1 error generated.
Without adding the ?.reserved2 = 0x,? it builds.
int
ixgbe_rxq_vec_setup(struct igb_rx_queue *rxq)
{
static struct rte_mbuf mb_def = {
.nb_segs = 1,
.data_off = RTE_PKTMBUF_HEADROOM,
.reserverd2 = (uint16_t)0x,
#ifdef RTE_MBUF_REFCNT
.refcnt = 1,
#endif
};
Then I removed the {} and it now builds. Is this a result of the changes to the
mbuf structure and Clang being picky?
Should I submit a patch to remove the ?{ }? values?
Keith Wiles, Principal Technologist with CTO office, Wind River mobile
972-213-5533
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
On Fri, Oct 03, 2014 at 03:15:46PM -0400, Neil Horman wrote: > With a single archive, you get everything you build even if you don't need > it. Right, I was trying to avoid that for people who specifically didn't want it, if there are any... I'm not one of them. > But presumably if you're building a static binary, you're > likely building the dpdk as well and can configure optional libraries out of > the > build. Separate libraries are more a need for downstream > distributors/packagers, who use dynamic shared objects anyway. Yeah, I was thinking it'd be nice if the downstream packagers could get a global '.a' and per-sublib '.a' as well. So that one dpdk package could be used by a client app which wanted everything, or only wanted portions. > Backward compatibilty? the DPDK doesn't yet provide run time compatibility > between releases (something I've been trying to change). Nobody provides > compile time compatibility. To do so would require fixing API's permenently. Agreed. I was just advocating to avoid worsening the already existent issues. ;) Matthew.
[dpdk-dev] [PATCH] Remove n_orig from __mempool_get_bulk() routine, cleanup comment.
Cleanup the code some to remove n_orig variable that was not required.
Update the comments to __mempool_get_bulk to state the correct return value.
Signed-off-by: Keith Wiles
---
lib/librte_mempool/rte_mempool.h | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 95f19f9..597cf4f 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -937,7 +937,7 @@ rte_mempool_put(struct rte_mempool *mp, void *obj)
* @param is_mc
* Mono-consumer (0) or multi-consumers (1).
* @return
- * - >=0: Success; number of objects supplied.
+ * - 0: Success; number of objects requested.
* - <0: Error; code of ring dequeue function.
*/
static inline int __attribute__((always_inline))
@@ -945,9 +945,6 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
unsigned n, int is_mc)
{
int ret;
-#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
- unsigned n_orig = n;
-#endif
#if RTE_MEMPOOL_CACHE_MAX_SIZE > 0
struct rte_mempool_cache *cache;
uint32_t index, len;
@@ -988,7 +985,7 @@ __mempool_get_bulk(struct rte_mempool *mp, void **obj_table,
cache->len -= n;
- __MEMPOOL_STAT_ADD(mp, get_success, n_orig);
+ __MEMPOOL_STAT_ADD(mp, get_success, n);
return 0;
@@ -1002,9 +999,9 @@ ring_dequeue:
ret = rte_ring_sc_dequeue_bulk(mp->ring, obj_table, n);
if (ret < 0)
- __MEMPOOL_STAT_ADD(mp, get_fail, n_orig);
+ __MEMPOOL_STAT_ADD(mp, get_fail, n);
else
- __MEMPOOL_STAT_ADD(mp, get_success, n_orig);
+ __MEMPOOL_STAT_ADD(mp, get_success, n);
return ret;
}
--
2.1.0
Keith Wiles, Principal Technologist with CTO office, Wind River mobile
972-213-5533
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
On Fri, 3 Oct 2014 07:28:33 -0400 Neil Horman wrote: > I.e. you can ship your pmd's > pacakged separately from your core I was hoping only the application API would be "stable" As we know from Linux kernel, internal API's will never remain stable.
[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
On Fri, Oct 03, 2014 at 04:52:40PM -0700, Stephen Hemminger wrote: > On Fri, 3 Oct 2014 07:28:33 -0400 > Neil Horman wrote: > > > I.e. you can ship your pmd's > > pacakged separately from your core > > I was hoping only the application API would be "stable" > As we know from Linux kernel, internal API's will never remain stable. > None of the API's are stable. My only hope with the ABI series I've posted is to keep the interfaces stable for a release beyond the next time they change, so that application developers aren't consistently caught off guard if they don't synchronize with the DPDK release schedule. I know the kernel API's are constantly changing, but this isn't the kernel, its a user space library. Theres nothing that prevents a third party from writing a pmd to interface to the ethdev library, which is no different from any other user space library. If the DPDK wants to get packaged like other libraries in distributions, it needs to provide stability assurances like other libraries. Neil
