Re: [dpdk-users] [dpdk-dev] DPDK PDUMP Issue
Hi Dikshant, Summarizing the contents from earlier mails below 1. Issue-1 shared with PDUMP not working with testpmd - solution shared and suggested what needs to be added to fix the same. 2. Issue-2 shared for custom Makefile for application not working - pointed out possible cause and missing order of libraries in CFLAGS and LDFLAGS. Suggested to use an existing working DPDK/example content for custom Makefile. Please note I do not have the project or Makefile for use case to try it locally, hence please try ``` 5. Unable to find `-Wl,-lpcap` passed for `-Wl,-lrte_pmd_pcap -Wl,-lrte_pdump` Hint: I normally take up sample like example/l2fwd and work towards to removing unwanted libraries while keeping the content and format intact for my custom makefile. ``` Snipped > > Hi Vipin, > > Here is full log with include option and build with make -n option from master > makefile as well: > > make[2]: Entering directory > `/mnt/data/dchitkara/PHY5G/Prototype/NR_5G_SIM/Tests/COMMON/PACKE > T_GENERATOR' > echo ./packet_generator.cc -msse4.1 -I../../../COMMON/Sys_API/Math_API/ - > I../../../COMMON/Sys_API/Math_API/ - > I../../../COMMON/Sys_API/Module_API/- > I../../../COMMON/Sys_API/common_intel/ > echo packet_generator.o > test -d || mkdir -p > g++ -msse4.1 -I../../../COMMON/Sys_API/Math_API/ - > I../../../COMMON/Sys_API/Math_API/ - > I../../../COMMON/Sys_API/Module_API -I./ - > DTIME_DATE=\"DATE:29/07/20_TIME:09:57:19\" - > DMOD_NAME=\"PACKET_GENERATOR_TEST_MOD\" -DARCH_X86 - > I/mnt/data/dchitkara/DPDK_2020_01_30_x86/x86_64-native-linux-icc/include > -I -DAS_INFRA_NULL=0 -DEMULATOR_MODE -DINTEL -std=c++11 -D_4x4_ -O3 > -g -DDEBUG -fPIC -c ./packet_generator.cc > echo > /usr/local/include:/opt/intel/system_studio_2019/compilers_and_libraries_20 > 19.2.187/linux/pstl/include:/opt/intel/system_studio_2019/compilers_and_lib > raries_2019.2.187/linux/tbb/include:/opt/intel/system_studio_2019/compiler > s_and_libraries_2019.2.187/linux/tbb/include:/opt/intel/system_studio_2019 > /compilers_and_libraries_2019.2.187/linux/ipp/include:/opt/intel/system_stu > dio_2019/compilers_and_libraries_2019.2.187/linux/mkl/include:/opt/intel/s > ystem_studio_2019/compilers_and_libraries_2019.2.187/linux/ipp/include:/o > pt/intel/system_studio_2019/compilers_and_libraries_2019.2.187/linux/mkl/i > nclude:/opt/intel/system_studio_2019/compilers_and_libraries_2019.2.187/li > nux/pstl/include:/opt/intel/system_studio_2019/compilers_and_libraries_201 > 9.2.187/linux/tbb/include:/opt/intel/system_studio_2019/compilers_and_libr > aries_2019.2.187/linux/tbb/include:/opt/intel/system_studio_2019/compilers > _and_libraries_2019.2.187/linux/daal/include > echo packet_generator.o > test -d ../../../COMMON/../bin || mkdir -p ../../../COMMON/../bin > g++ -shared -Wl,--export-dynamic packet_generator.o > g++ -L/mnt/data/dchitkara/DPDK_2020_01_30_x86/x86_64-native-linux-icc/li > g++ b -Wl,--whole-archive -Wl,-lrte_mempool_ring -Wl,-lrte_member > g++ -Wl,-lrte_eventdev -Wl,-lpcap -Wl,-lrte_pmd_pcap -Wl,-lrte_pdump > g++ -Wl,-lrte_bus_vmbus -Wl,-lrte_pci -Wl,-lrte_bus_pci > g++ -Wl,-lrte_bus_vdev -Wl,-lrte_net -Wl,-lrte_distributor > g++ -Wl,-lrte_reorder -Wl,-lrte_kni -Wl,-lrte_pipeline -Wl,-lrte_table > g++ -Wl,-lrte_port -Wl,-lrte_timer -Wl,-lrte_hash -Wl,-lrte_jobstats > g++ -Wl,-lrte_lpm -Wl,-lrte_power -Wl,-lrte_acl -Wl,-lrte_meter > g++ -Wl,-lrte_sched -Wl,-lm -Wl,-lrt -Wl,-lrte_vhost -Wl,--start-group > g++ -Wl,-lrte_kvargs -Wl,-lrte_mbuf -Wl,-lrte_ip_frag -Wl,-lrte_ethdev > g++ -Wl,-lrte_cryptodev -Wl,-lrte_mempool -Wl,-lrte_ring -Wl,-lrte_eal > g++ -Wl,-lrte_cmdline -Wl,-lrte_cfgfile -Wl,-lrte_pmd_bond > g++ -Wl,-lrte_pmd_vmxnet3_uio -Wl,-lrte_pmd_virtio -Wl,-lrte_pmd_cxgbe > g++ -Wl,-lrte_pmd_enic -Wl,-lrte_pmd_i40e -Wl,-lrte_pmd_fm10k > g++ -Wl,-lrte_pmd_ixgbe -Wl,-lrte_pmd_e1000 -Wl,-lrte_pmd_ring > g++ -Wl,-lrte_pmd_af_packet -Wl,-lrte_pmd_null -Wl,-lrt -Wl,-lm -Wl,-ldl > g++ -Wl,--end-group -Wl,--no-whole-archive -o > g++ ../../../COMMON/../bin/PACKET_GENERATOR_TEST_MOD.so > make[2]: Leaving directory > `/mnt/data/dchitkara/PHY5G/Prototype/NR_5G_SIM/Tests/COMMON/PACKE > T_GENERATOR' > > Please have a note that module we are running is just one part of our CPP > project treated as a separate test module. snipped > > Hi Dikshant, > > Looks like the custom Makefile log is quite different in passing DPDK CFLAGS > and LDFLAGS. Also here are couple of surprises for me > > 1. Unable to find `make -n` logs > > 2. presence of g++ is present in each line > > 3. unable to find include option > > 4. request was to run `make -n` and cross the relevant libraries are bound > within the `-Wl,--whole-archive` and `-Wl,--no-whole-archive `. > > 5. Unable to find `-Wl,-lpcap` passed for `-Wl,-lrte_pmd_pcap -Wl,- > lrte_pdump` > > Hint: I normally take up sample like example/l2fwd and work towards to > removing unwanted libraries while keeping the content and format intact for > my custom makefile. > snipped
Re: [dpdk-users] COUNT action not supported on mlx5
Hi Asaf,
I want to filter some L7 protocols.
Example use cases could be to send all TLS handshakes to a certain queue,
or drop all DNS queries, and I do not want to rely on port numbers to do so.
>From my understanding, the RAW item type does not support ranges in the
specification (I wish it did), but having RAW available will help simulate
some protocols.
Gerry
On Wed, Jul 29, 2020 at 8:26 AM Asaf Penso wrote:
> Hello Gerry,
>
> Regarding your question about RAW. Can you specify your use case?
> In high level planning we'll consider supporting it in 21.02.
>
> Regards,
> Asaf Penso
>
> -Original Message-
> From: users On Behalf Of Erez Ferber
> Sent: Monday, July 27, 2020 9:25 PM
> To: Gerry Wan
> Cc: users@dpdk.org
> Subject: Re: [dpdk-users] COUNT action not supported on mlx5
>
> Hi,
>
> One possible condition to get -ENOTSUP is if DevX is disabled on the NIC,
> Have you verified DevX is enabled ?
> Please check here :
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.dpdk.org%2Fguides%2Fnics%2Fmlx5.htmldata=02%7C01%7Casafp%40mellanox.com%7C038afadf61c844e6506808d8325a5eed%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C637314711005622085sdata=B0O%2FBe6TlY%2BCRDPXcAFyAaBS701iLV5BO%2B6kcqCs4b0%3Dreserved=0
> ---
> enable DevX (required by Direct Rules and other features):
> UCTX_EN=1
> ---
>
> With higher log verbosity, you could check in the application
> initialization if mlx5 PMD returns"DevX is supported" to make sure.
>
> Regards,
> Erez
>
> On Mon, 27 Jul 2020 at 21:12, Gerry Wan wrote:
>
> > Hello,
> >
> > I'm trying to query per-flow statistics using
> > RTE_FLOW_ACTION_TYPE_COUNT on a Mellanox ConnectX-5 port. I tried
> > extending the flow_filtering sample application with:
> >
> > struct rte_flow_query_count count = {
> > .reset = 1,
> > .hits_set = 1,
> > .bytes_set = 1,
> > .hits = 0,
> > .bytes = 0,
> > };
> >
> > // set attr, pattern, etc.
> >
> > action[0].type = RTE_FLOW_ACTION_TYPE_COUNT; action[0].conf =
> > action[1].type = RTE_FLOW_ACTION_TYPE_QUEUE; action[1].conf =
> > action[2].type = RTE_FLOW_ACTION_TYPE_END;
> >
> > The call to rte_flow_validate() returns with -ENOTSUP, saying the flow
> > cannot be created because the count action is not supported. However,
> > mlx5 documentation
> > (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc
> > .dpdk.org%2Fguides%2Fnics%2Fmlx5.html%23statisticsdata=02%7C01%7C
> > asafp%40mellanox.com%7C038afadf61c844e6506808d8325a5eed%7Ca652971c7d2e
> > 4d9ba6a4d149256f461b%7C0%7C1%7C637314711005622085sdata=pQ7pRgytQB
> > %2F1IUGV2SZR5IrGNMZyMdseuECjIw7uuOE%3Dreserved=0)
> > states that it does indeed support attaching count actions. Without
> > the count action the flow rule configuration works fine.
> >
> > I am using DPDK-20.05 and MLNX_OFED_LINUX-5.0-2.1.8.0, with a
> > ConnectX-5 Virtual Function (could the VF be the issue?). What can be
> > the cause of this?
> >
> > On a related note, is there any plan for mlx5 to support
> > RTE_FLOW_ITEM_TYPE_RAW?
> >
> > Thanks,
> >
>
Re: [dpdk-users] [dpdk-dev] Queue Management Support in DPDK
On Thu, 30 Jul 2020 00:07:29 +0530 Archit Pandey wrote: > Hello everyone, > > We have been using DPDK's QoS framework over the last year and found > that rte_sched and the provided qos_sched app work great for QoS. > > However, when we ventured into trying to add CoDel (to replace RED) as > a dropper to the framework, we faced several challenges due to how > tightly rte_sched and rte_red were coupled together. As we had no > success with rte_sched, we would like to propose a new framework for > queue management in DPDK. > > Goals we have in mind for the framework: > - Act as an abstraction for queue management algorithms (AQMs) such as > CoDel, PiE and RED. > - Make it easy for new algorithms to be added. > > We’d appreciate feedback on whether such a framework would be welcomed > in the community, or what else could be done for adding queue > management support. > > Sincerely, > Archit Pandey. rte_sched is not a generic AQM mechanism. You will have to write a new replacement for rte_sched if you want something else. I would recommend starting with Cake. It is latest and most complete and the developers are active and friendly.
[dpdk-users] Queue Management Support in DPDK
Hello everyone, We have been using DPDK's QoS framework over the last year and found that rte_sched and the provided qos_sched app work great for QoS. However, when we ventured into trying to add CoDel (to replace RED) as a dropper to the framework, we faced several challenges due to how tightly rte_sched and rte_red were coupled together. As we had no success with rte_sched, we would like to propose a new framework for queue management in DPDK. Goals we have in mind for the framework: - Act as an abstraction for queue management algorithms (AQMs) such as CoDel, PiE and RED. - Make it easy for new algorithms to be added. We’d appreciate feedback on whether such a framework would be welcomed in the community, or what else could be done for adding queue management support. Sincerely, Archit Pandey.
Re: [dpdk-users] COUNT action not supported on mlx5
Hello Gerry,
Regarding your question about RAW. Can you specify your use case?
In high level planning we'll consider supporting it in 21.02.
Regards,
Asaf Penso
-Original Message-
From: users On Behalf Of Erez Ferber
Sent: Monday, July 27, 2020 9:25 PM
To: Gerry Wan
Cc: users@dpdk.org
Subject: Re: [dpdk-users] COUNT action not supported on mlx5
Hi,
One possible condition to get -ENOTSUP is if DevX is disabled on the NIC, Have
you verified DevX is enabled ?
Please check here :
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.dpdk.org%2Fguides%2Fnics%2Fmlx5.htmldata=02%7C01%7Casafp%40mellanox.com%7C038afadf61c844e6506808d8325a5eed%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C637314711005622085sdata=B0O%2FBe6TlY%2BCRDPXcAFyAaBS701iLV5BO%2B6kcqCs4b0%3Dreserved=0
---
enable DevX (required by Direct Rules and other features):
UCTX_EN=1
---
With higher log verbosity, you could check in the application initialization if
mlx5 PMD returns"DevX is supported" to make sure.
Regards,
Erez
On Mon, 27 Jul 2020 at 21:12, Gerry Wan wrote:
> Hello,
>
> I'm trying to query per-flow statistics using
> RTE_FLOW_ACTION_TYPE_COUNT on a Mellanox ConnectX-5 port. I tried
> extending the flow_filtering sample application with:
>
> struct rte_flow_query_count count = {
> .reset = 1,
> .hits_set = 1,
> .bytes_set = 1,
> .hits = 0,
> .bytes = 0,
> };
>
> // set attr, pattern, etc.
>
> action[0].type = RTE_FLOW_ACTION_TYPE_COUNT; action[0].conf =
> action[1].type = RTE_FLOW_ACTION_TYPE_QUEUE; action[1].conf =
> action[2].type = RTE_FLOW_ACTION_TYPE_END;
>
> The call to rte_flow_validate() returns with -ENOTSUP, saying the flow
> cannot be created because the count action is not supported. However,
> mlx5 documentation
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc
> .dpdk.org%2Fguides%2Fnics%2Fmlx5.html%23statisticsdata=02%7C01%7C
> asafp%40mellanox.com%7C038afadf61c844e6506808d8325a5eed%7Ca652971c7d2e
> 4d9ba6a4d149256f461b%7C0%7C1%7C637314711005622085sdata=pQ7pRgytQB
> %2F1IUGV2SZR5IrGNMZyMdseuECjIw7uuOE%3Dreserved=0)
> states that it does indeed support attaching count actions. Without
> the count action the flow rule configuration works fine.
>
> I am using DPDK-20.05 and MLNX_OFED_LINUX-5.0-2.1.8.0, with a
> ConnectX-5 Virtual Function (could the VF be the issue?). What can be
> the cause of this?
>
> On a related note, is there any plan for mlx5 to support
> RTE_FLOW_ITEM_TYPE_RAW?
>
> Thanks,
>
Re: [dpdk-users] meson: is there a mechanism for controlling compilation configuration
29/07/2020 09:20, Chengchang Tang: > Hi, > DPDK with 'make' will be deprecated in a future release. I have some > questions about using meson to build DPDK. > > When using the make, we can change the macros in config/common_base to > control the compiling macros. For example, if i want to debug the mbuf, > i can set CONFIG_RTE_LIBRTE_MBUF_DEBUG=y in config/common_base to change > the compiling macros. > > According to my understanding. DPDK meson build dose not generate > rte_config.h based on common_base content during compilation. Is there > any convenient way to modify the compiling macro in meson build. If all > the compilation macros need to be modified using environment variable, > it is inconvenient. Please look at the work done in this series: https://patches.dpdk.org/project/dpdk/list/?series=10930=*
Re: [dpdk-users] meson: is there a mechanism for controlling compilation configuration
> -Original Message- > From: Chengchang Tang > Sent: Wednesday, July 29, 2020 9:36 AM > To: users@dpdk.org > Cc: linux...@huawei.com; users@dpdk.org; Richardson, Bruce > > Subject: Re: [dpdk-users] meson: is there a mechanism for controlling > compilation configuration > > cc'ed bruce > > On 2020/7/29 15:20, Chengchang Tang wrote: > > Hi, > > DPDK with 'make' will be deprecated in a future release. I have some > > questions about using meson to build DPDK. > > > > When using the make, we can change the macros in config/common_base to > > control the compiling macros. For example, if i want to debug the > > mbuf, i can set CONFIG_RTE_LIBRTE_MBUF_DEBUG=y in config/common_base > > to change the compiling macros. > > > > According to my understanding. DPDK meson build dose not generate > > rte_config.h based on common_base content during compilation. Is there > > any convenient way to modify the compiling macro in meson build. If > > all the compilation macros need to be modified using environment > > variable, it is inconvenient. > > The number of build options for make was too large, so the meson build options are deliberately kept small. However, for the case of the debug build options that were previously present, this is currently a gap that is under discussion on the DPDK dev mailing list. The discussion thread can be viewed in the archives, e.g. http://inbox.dpdk.org/dev/20200709134823.9176-1-l.wojciec...@partner.samsung.com/ . Regards, /Bruce
Re: [dpdk-users] [dpdk-dev] DPDK PDUMP Issue
Couple more request,
1. please avoid ` NOT FROM AIRSPAN - Caution - External ` headers & banners.
2. If possible, use `snip` or `snipped` to remove clutter and bring foucs
Snipped
> Hi Dikshant,
>
> Looks like the custom Makefile log is quite different in passing DPDK CFLAGS
> and LDFLAGS. Also here are couple of surprises for me
>
> 1. Unable to find `make -n` logs
>
> 2. presence of g++ is present in each line
>
> 3. unable to find include option
>
> 4. request was to run `make -n` and cross the relevant libraries are bound
> within the `-Wl,--whole-archive` and `-Wl,--no-whole-archive `.
>
> 5. Unable to find `-Wl,-lpcap` passed for `-Wl,-lrte_pmd_pcap -Wl,-
> lrte_pdump`
>
> Hint: I normally take up sample like example/l2fwd and work towards to
> removing unwanted libraries while keeping the content and format intact for
> my custom makefile.
>
snipped
> >
> > Hi Vipin,
> >
> > I tried using `-Wl,--whole-archive` and `-Wl,--no-whole-archive `
> > option with my necessary libraries but it does not seem to help as well.
> >
> > Below is the makefile log for my app:
> >
> > g++ -shared -Wl,--export-dynamic packet_generator.o
> > g++ -L/mnt/data/dchitkara/DPDK_2020_01_30_x86/x86_64-native-linux-icc/
> > g++ li b -Wl,--whole-archive -Wl,-lrte_mempool_ring -Wl,-lrte_member
> > g++ -Wl,-lrte_eventdev -Wl,-lrte_pmd_pcap -Wl,-lrte_pdump
> > g++ -Wl,-lrte_bus_vmbus -Wl,-lrte_pci -Wl,-lrte_bus_pci
> > g++ -Wl,-lrte_bus_vdev -Wl,-lrte_net -Wl,-lrte_distributor
> > g++ -Wl,-lrte_reorder -Wl,-lrte_kni -Wl,-lrte_pipeline -Wl,-lrte_table
> > g++ -Wl,-lrte_port -Wl,-lrte_timer -Wl,-lrte_hash -Wl,-lrte_jobstats
> > g++ -Wl,-lrte_lpm -Wl,-lrte_power -Wl,-lrte_acl -Wl,-lrte_meter
> > g++ -Wl,-lrte_sched -Wl,-lm -Wl,-lrt -Wl,-lrte_vhost -Wl,--start-group
> > g++ -Wl,-lrte_kvargs -Wl,-lrte_mbuf -Wl,-lrte_ip_frag -Wl,-lrte_ethdev
> > g++ -Wl,-lrte_cryptodev -Wl,-lrte_mempool -Wl,-lrte_ring -Wl,-lrte_eal
> > g++ -Wl,-lrte_cmdline -Wl,-lrte_cfgfile -Wl,-lrte_pmd_bond
> > g++ -Wl,-lrte_pmd_vmxnet3_uio -Wl,-lrte_pmd_virtio -Wl,-lrte_pmd_cxgbe
> > g++ -Wl,-lrte_pmd_enic -Wl,-lrte_pmd_i40e -Wl,-lrte_pmd_fm10k
> > g++ -Wl,-lrte_pmd_ixgbe -Wl,-lrte_pmd_e1000 -Wl,-lrte_pmd_ring
> > g++ -Wl,-lrte_pmd_af_packet -Wl,-lrte_pmd_null -Wl,-lrt -Wl,-lm
> > g++ -Wl,-ldl -Wl,--end-group -Wl,--no-whole-archive -o
> > g++ ../../../COMMON/../bin/PACKET_GENERATOR_TEST_MOD.so
> >
> >
snipped
> >
> > > Hi Team,
> > >
> > > With fix suggest in prev mail thread at testpmd side, PDUMP works
> > > with testpmd.
> > >
> > > However when we try to run our own primary app with PDUMP as a
> > > secondary process, PDUMP console comes up, however it does not
> > > capture
> > any packets.
> > >
> > > Changes made at primary app side:
> > > 1. PDUMP initialised just after rte eal init:
> > >
> > > ret_pdump = rte_pdump_init();
> > >if (ret_pdump < 0) {
> > >printf("rte_pdump_init failed\n");
> > >}
> > >else
> > >{
> > >printf("rte_pdump_init success\n");
> > >}
> > >
> > > 2. Makefile modified to add all relevant files to be linked:
> > >
> > > LIB_SO =-L$(DPDK_LIB) -lrte_mbuf -lrte_eal -lnuma -lrte_pmd_pcap -
> > > lrte_pdump -lrte_pmd_i40e -lrte_eal -lrte_ring -lrte_mempool
> > > -lrte_cryptodev -lrte_ethdev -lrte_mbuf -lrte_mempool_ring
> > > -lrte_member -
> > lrte_eventdev -
> > > lrte_bus_vmbus -lrte_pci -lrte_bus_pci -lrte_bus_vdev -lrte_net -
> > > lrte_distributor -lrte_reorder -lrte_kni -lrte_pipeline
> > > -lrte_table -lrte_timer - lrte_hash -lrte_jobstats -lrte_lpm
> > > -lrte_power -lrte_acl -lrte_meter -lrte_sch
> > >
> > > Even tried to link final DPDK lib so as well:
> > > LIB_SO =-L$(DPDK_LIB) -Wl,--whole-archive -ldpdk -Wl,--no-whole-
> archive -
> > > L/usr/lib/x86_64-linux-gnu/ -fPIC
> >
> > Ok, I think I have seen similar outcomes in custom Makefiles. Can you
> > execute with `make -n` with the master Makefile and cross the
> > necessary libraries are in bound between `-Wl,--whole-archive` and
> > `-Wl,--no-whole-archive ` (specically for shared libraries).
> >
> > snipped
Re: [dpdk-users] [dpdk-dev] DPDK PDUMP Issue
Hi Dikshant,
Looks like the custom Makefile log is quite different in passing DPDK CFLAGS
and LDFLAGS. Also here are couple of surprises for me
1. Unable to find `make -n` logs
2. presence of g++ is present in each line
3. unable to find include option
4. request was to run `make -n` and cross the relevant libraries are bound
within the `-Wl,--whole-archive` and `-Wl,--no-whole-archive `.
5. Unable to find `-Wl,-lpcap` passed for `-Wl,-lrte_pmd_pcap -Wl,-lrte_pdump`
Hint: I normally take up sample like example/l2fwd and work towards to removing
unwanted libraries while keeping the content and format intact for my custom
makefile.
> -Original Message-
> From: Dikshant Chitkara
> Sent: Wednesday, July 29, 2020 2:44 PM
> To: Varghese, Vipin ; Stephen Hemminger
>
> Cc: users@dpdk.org; d...@dpdk.org; Amir Ilan ; Veeresh
> Patil
> Subject: RE: [dpdk-dev] DPDK PDUMP Issue
>
> Hi Vipin,
>
> I tried using `-Wl,--whole-archive` and `-Wl,--no-whole-archive ` option with
> my necessary libraries but it does not seem to help as well.
>
> Below is the makefile log for my app:
>
> g++ -shared -Wl,--export-dynamic packet_generator.o
> g++ -L/mnt/data/dchitkara/DPDK_2020_01_30_x86/x86_64-native-linux-icc/li
> g++ b -Wl,--whole-archive -Wl,-lrte_mempool_ring -Wl,-lrte_member
> g++ -Wl,-lrte_eventdev -Wl,-lrte_pmd_pcap -Wl,-lrte_pdump
> g++ -Wl,-lrte_bus_vmbus -Wl,-lrte_pci -Wl,-lrte_bus_pci
> g++ -Wl,-lrte_bus_vdev -Wl,-lrte_net -Wl,-lrte_distributor
> g++ -Wl,-lrte_reorder -Wl,-lrte_kni -Wl,-lrte_pipeline -Wl,-lrte_table
> g++ -Wl,-lrte_port -Wl,-lrte_timer -Wl,-lrte_hash -Wl,-lrte_jobstats
> g++ -Wl,-lrte_lpm -Wl,-lrte_power -Wl,-lrte_acl -Wl,-lrte_meter
> g++ -Wl,-lrte_sched -Wl,-lm -Wl,-lrt -Wl,-lrte_vhost -Wl,--start-group
> g++ -Wl,-lrte_kvargs -Wl,-lrte_mbuf -Wl,-lrte_ip_frag -Wl,-lrte_ethdev
> g++ -Wl,-lrte_cryptodev -Wl,-lrte_mempool -Wl,-lrte_ring -Wl,-lrte_eal
> g++ -Wl,-lrte_cmdline -Wl,-lrte_cfgfile -Wl,-lrte_pmd_bond
> g++ -Wl,-lrte_pmd_vmxnet3_uio -Wl,-lrte_pmd_virtio -Wl,-lrte_pmd_cxgbe
> g++ -Wl,-lrte_pmd_enic -Wl,-lrte_pmd_i40e -Wl,-lrte_pmd_fm10k
> g++ -Wl,-lrte_pmd_ixgbe -Wl,-lrte_pmd_e1000 -Wl,-lrte_pmd_ring
> g++ -Wl,-lrte_pmd_af_packet -Wl,-lrte_pmd_null -Wl,-lrt -Wl,-lm -Wl,-ldl
> g++ -Wl,--end-group -Wl,--no-whole-archive -o
> g++ ../../../COMMON/../bin/PACKET_GENERATOR_TEST_MOD.so
>
>
> Thanks,
> Dikshant
>
> Snipped
>
> > Hi Team,
> >
> > With fix suggest in prev mail thread at testpmd side, PDUMP works with
> > testpmd.
> >
> > However when we try to run our own primary app with PDUMP as a
> > secondary process, PDUMP console comes up, however it does not capture
> any packets.
> >
> > Changes made at primary app side:
> > 1. PDUMP initialised just after rte eal init:
> >
> > ret_pdump = rte_pdump_init();
> >if (ret_pdump < 0) {
> >printf("rte_pdump_init failed\n");
> >}
> >else
> >{
> >printf("rte_pdump_init success\n");
> >}
> >
> > 2. Makefile modified to add all relevant files to be linked:
> >
> > LIB_SO =-L$(DPDK_LIB) -lrte_mbuf -lrte_eal -lnuma -lrte_pmd_pcap -
> > lrte_pdump -lrte_pmd_i40e -lrte_eal -lrte_ring -lrte_mempool
> > -lrte_cryptodev -lrte_ethdev -lrte_mbuf -lrte_mempool_ring -lrte_member -
> lrte_eventdev -
> > lrte_bus_vmbus -lrte_pci -lrte_bus_pci -lrte_bus_vdev -lrte_net -
> > lrte_distributor -lrte_reorder -lrte_kni -lrte_pipeline -lrte_table
> > -lrte_timer - lrte_hash -lrte_jobstats -lrte_lpm -lrte_power
> > -lrte_acl -lrte_meter -lrte_sch
> >
> > Even tried to link final DPDK lib so as well:
> > LIB_SO =-L$(DPDK_LIB) -Wl,--whole-archive -ldpdk -Wl,--no-whole-archive
> > -
> > L/usr/lib/x86_64-linux-gnu/ -fPIC
>
> Ok, I think I have seen similar outcomes in custom Makefiles. Can you execute
> with `make -n` with the master Makefile and cross the necessary libraries are
> in bound between `-Wl,--whole-archive` and `-Wl,--no-whole-archive `
> (specically for shared libraries).
>
> snipped
Re: [dpdk-users] meson: is there a mechanism for controlling compilation configuration
cc'ed bruce On 2020/7/29 15:20, Chengchang Tang wrote: > Hi, > DPDK with 'make' will be deprecated in a future release. I have some > questions about using meson to build DPDK. > > When using the make, we can change the macros in config/common_base to > control the compiling macros. For example, if i want to debug the mbuf, > i can set CONFIG_RTE_LIBRTE_MBUF_DEBUG=y in config/common_base to change > the compiling macros. > > According to my understanding. DPDK meson build dose not generate > rte_config.h based on common_base content during compilation. Is there > any convenient way to modify the compiling macro in meson build. If all > the compilation macros need to be modified using environment variable, > it is inconvenient. > > Thanks, > Chengchang > . > > ___ > Linuxarm mailing list > linux...@huawei.com > http://hulk.huawei.com/mailman/listinfo/linuxarm > > . >
[dpdk-users] meson: is there a mechanism for controlling compilation configuration
Hi, DPDK with 'make' will be deprecated in a future release. I have some questions about using meson to build DPDK. When using the make, we can change the macros in config/common_base to control the compiling macros. For example, if i want to debug the mbuf, i can set CONFIG_RTE_LIBRTE_MBUF_DEBUG=y in config/common_base to change the compiling macros. According to my understanding. DPDK meson build dose not generate rte_config.h based on common_base content during compilation. Is there any convenient way to modify the compiling macro in meson build. If all the compilation macros need to be modified using environment variable, it is inconvenient. Thanks, Chengchang .
