[dpdk-dev] [PATCH v2] app/testpmd: fix RSS by setting mq_mode
14/01/2014 11:57, Daniel Kan : > On Jan 14, 2014, at 9:42 AM, Maxime Leroy wrote: > > An other issue about not enabling RSS with 1 queue, when you use the > > command show_rss_key in the testpmd, this one will display that the RSS > > is enabled. (because rss_hf != 0; see port_rss_hash_conf_show function in > > app/test-pmd/config.c) > > PS. I don?t see port_rss_hash_conf_show in config.c, at not in 1.5.1 branch. > Which branch is this in? Maxime is talking about a local development branch. The function port_rss_hash_conf_show() is in a patch which should be ready for the next version. By the way, your fix will be integrated in version 1.5.2. Daniel, thanks to provide a new version of your patch which allow RSS debugging with only 1 queue. -- Thomas
[dpdk-dev] [PATCH v2] app/testpmd: fix RSS by setting mq_mode
Hello, Thanks for your patch fixing the regression introduced by my commit (igb/ixgbe: ETH_MQ_RX_NONE should disable RSS). I have one comment about your fix. I don't think there are any reasons to not enable RSS with only one RX queue in testpmd. RSS is mainly used in testpmd to spread traffic on the different rx queues. But you can use RSS with one rx queue for debbugging purpose. For example, you can use the rxonly forward engine of the testpmd to display the RSS hash. (see pkt_burst_receive in app/test-pmd/rxonly.c) An other issue about not enabling RSS with 1 queue, when you use the command show_rss_key in the testpmd, this one will display that the RSS is enabled. (because rss_hf != 0; see port_rss_hash_conf_show function in app/test-pmd/config.c) Do you agree with my analyze ? Thanks. -- Maxime Leroy
[dpdk-dev] Any benefit of using DPDK's makefiles instead of using your own and linking against DPDK library
Hi, Considering the fact that there are many developers using c++, I totally persuade/agree with the addition of c++ functionality, and thanks to Thomas's guidelines it won't create any overhead in usage. All the Best, --Hamid On 1/14/14, Thomas Monjalon wrote: > Hello Venky, > > 14/01/2014 14:22, Venkatesan, Venky: >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon >> > 14/01/2014 08:02, Daniel Kan: >> > > I already have existing makefiles for my current application. I would >> > > like to integrate dpdk into the application. ?m wondering if there >> > > is >> > > any benefit to use dpdk?s makefiles instead of using your own >> > > makefile >> > > and linking against the library (e.g. libintel_dpdk.a). Thanks. >> > >> > DPDK makefiles have 2 benefits: >> > - provide a framework >> > - automatically set CFLAGS and LDFLAGS according to your configuration >> > >> > If you don't need a framework, I think it's better to extract >> > compilation >> > flags with something like pkg-config. >> > http://freedesktop.org/wiki/Software/pkg-config >> > A patch for a such feature would be welcome :) >> >> One other thing to think about - as we add more functionality into DPDK >> (e.g. new libraries for other packet functions), we integrate them into >> the DPDK framework. If you extract compilation flags and setup your own >> makefile, you would have to do this re-integration every time you want to >> pick up a new release. The same applies to newer files added etc. etc. >> That is the downside. > > I disagree. > If the Makefile of the application, use a DPDK script or pkg-config to read > > the flags from a generated file, the integration is done only once. > This guide explains the logic and how to implement it: > http://people.freedesktop.org/~dbn/pkg-config-guide.html > > -- > Thomas >
[dpdk-dev] Any benefit of using DPDK's makefiles instead of using your own and linking against DPDK library
Hello Venky, 14/01/2014 14:22, Venkatesan, Venky: > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > 14/01/2014 08:02, Daniel Kan: > > > I already have existing makefiles for my current application. I would > > > like to integrate dpdk into the application. ?m wondering if there is > > > any benefit to use dpdk?s makefiles instead of using your own makefile > > > and linking against the library (e.g. libintel_dpdk.a). Thanks. > > > > DPDK makefiles have 2 benefits: > > - provide a framework > > - automatically set CFLAGS and LDFLAGS according to your configuration > > > > If you don't need a framework, I think it's better to extract compilation > > flags with something like pkg-config. > > http://freedesktop.org/wiki/Software/pkg-config > > A patch for a such feature would be welcome :) > > One other thing to think about - as we add more functionality into DPDK > (e.g. new libraries for other packet functions), we integrate them into > the DPDK framework. If you extract compilation flags and setup your own > makefile, you would have to do this re-integration every time you want to > pick up a new release. The same applies to newer files added etc. etc. > That is the downside. I disagree. If the Makefile of the application, use a DPDK script or pkg-config to read the flags from a generated file, the integration is done only once. This guide explains the logic and how to implement it: http://people.freedesktop.org/~dbn/pkg-config-guide.html -- Thomas
[dpdk-dev] Any benefit of using DPDK's makefiles instead of using your own and linking against DPDK library
I think in general, developers are pretty particular about their makefiles and build framework. This is especially true if you have an existing application; migrating it to use dpdk?s build framework is rather cumbersome and likely a non-starter for bigger complex projects. Hence, separating application build from dpdk build will be very useful in many situations. The main trick is to extract the appropriate compilation flags that can be readily consumed by the application build system. As an application developer, nothing is simper than just having some header files, a library file, and some necessary compilation flags. If tools like pkg-config or others can facilitate that process, then we could consider it. But even a simple script that can be give me flags that I can provide to my own build system would already suffice. On a similar note, is there any particular reason why many macros such as RTE_MACHINE_XXX are passed as flags to the compiler instead of being defined in rte_config.h? Thanks Dan On Jan 14, 2014, at 5:55 AM, Thomas Monjalon wrote: > Hello Venky, > > 14/01/2014 14:22, Venkatesan, Venky: >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon >>> 14/01/2014 08:02, Daniel Kan: I already have existing makefiles for my current application. I would like to integrate dpdk into the application. ?m wondering if there is any benefit to use dpdk?s makefiles instead of using your own makefile and linking against the library (e.g. libintel_dpdk.a). Thanks. >>> >>> DPDK makefiles have 2 benefits: >>> - provide a framework >>> - automatically set CFLAGS and LDFLAGS according to your configuration >>> >>> If you don't need a framework, I think it's better to extract compilation >>> flags with something like pkg-config. >>> http://freedesktop.org/wiki/Software/pkg-config >>> A patch for a such feature would be welcome :) >> >> One other thing to think about - as we add more functionality into DPDK >> (e.g. new libraries for other packet functions), we integrate them into >> the DPDK framework. If you extract compilation flags and setup your own >> makefile, you would have to do this re-integration every time you want to >> pick up a new release. The same applies to newer files added etc. etc. >> That is the downside. > > I disagree. > If the Makefile of the application, use a DPDK script or pkg-config to read > the flags from a generated file, the integration is done only once. > This guide explains the logic and how to implement it: > http://people.freedesktop.org/~dbn/pkg-config-guide.html > > -- > Thomas
