[dpdk-dev] How to set RTE_MACHINE on DPDK 1.7.0 correctly?
Hi, I am trying to compile the test-pmd app on an Intel Core i7 targeted to run on Intel Atom target. When I run test pmd binary on the target machine, it fails to start with: ERROR: This system does not support "AVX". Please check that RTE_MACHINE is set correctly. This is how I am building dpdk: RTE_MAHCHINE=atm export RTE_MACHINE make install T=x86_64-native-linuxapp-gcc Since this didn't work, I copied cp config/defconfig_x86_64-native-linuxapp-gcc to config/defconfig_x86_64-atm-linuxapp-gcc and changed: CONFIG_RTE_MACHINE="atm" Followed by build: make install T=x86_64-atm-linuxapp-gcc This failed when compiling: == Build lib/librte_pmd_ixgbe . . CC ixgbe_rxtx_vec.o In file included from /home/sp/dpdk/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:41:0: /usr/lib/gcc/x86_64-linux-gnu/4.6/include/nmmintrin.h:31:3: error: #error "SSE4.2 instruction set not enabled" /home/sp/dpdk/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c: In function 'ixgbe_recv_pkts_vec' Any help is appreciated. Thanks. Suryanathan
[dpdk-dev] Fortville threshold register values
Hi, The l3fwd sample app contains the default values for the Intel(R) 82599 10 GbE controller's RX and TX Prefetch, Host, and Write-back registers; said values are used in the application to configure physical ports for optimal performance. What values could be used to configure the physical ports of a Fortville controller in a DPDK application for optimal performance? Many thanks, Mark -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] Performance - linking against DPDK shared vs static libraries
-Original Message- From: Antti Kantee [mailto:po...@fixup.fi] Sent: Wednesday, July 23, 2014 5:37 PM To: Kavanagh, Mark B; dev at dpdk.org Subject: Re: [dpdk-dev] Performance - linking against DPDK shared vs static libraries On 23/07/14 15:58, Kavanagh, Mark B wrote: >> Hi, >> >> I build a switching application, which links against DPDK shared libraries; >> when I run the application, I see throughput of X. I then build the >> application again, except this time I link against DPDK shared libraries, >> having modified the application's build parameters appropriately. In this >> case, I see a performance drop of around .04%, which given the high >> throughput of the application is significant. >> >> Is such performance degradation to be expected when using DPDK shared >> libraries, and if not, are there any best-known methods for preventing >> performance degradation, assuming that I may be constrained to using shared >> libraries going forward? >Do you mean .04% or 4%? I would be more inclined to believe the latter. >Shared libraries are inherently slower due to indirection from PIC, and being >required to use them seems like a silly constraint in the context of >high-performance computing. > - antti It's actually the former, and I agree with your assertion regarding the constraint! I take it from your response then that the performance drop when using shared libraries is expected behavior? -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] Inter-VM communication packet flow
DPDK-dev,
[dpdk-dev] How to set RTE_MACHINE on DPDK 1.7.0 correctly?
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Suryanathan P > Sent: Wednesday, July 23, 2014 10:28 AM > To: dev at dpdk.org > Subject: [dpdk-dev] How to set RTE_MACHINE on DPDK 1.7.0 correctly? > > Hi, > > I am trying to compile the test-pmd app on an Intel Core i7 targeted to run > on Intel Atom target. > > When I run test pmd binary on the target machine, it fails to start with: > > ERROR: This system does not support "AVX". > Please check that RTE_MACHINE is set correctly. > > This is how I am building dpdk: > > RTE_MAHCHINE=atm > export RTE_MACHINE > > make install T=x86_64-native-linuxapp-gcc > > Since this didn't work, I copied > > cp config/defconfig_x86_64-native-linuxapp-gcc to > config/defconfig_x86_64-atm-linuxapp-gcc > > and changed: > > CONFIG_RTE_MACHINE="atm" > > Followed by build: > make install T=x86_64-atm-linuxapp-gcc > > This failed when compiling: > == Build lib/librte_pmd_ixgbe > . > . > CC ixgbe_rxtx_vec.o > In file included from > /home/sp/dpdk/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c:41:0: > /usr/lib/gcc/x86_64-linux-gnu/4.6/include/nmmintrin.h:31:3: error: #error > "SSE4.2 instruction set not enabled" > /home/sp/dpdk/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c: In function > 'ixgbe_recv_pkts_vec' > > Any help is appreciated. > > Thanks. > Suryanathan To compile for the atom target you probably need to turn off the ACL library and set the "INC_VECTOR" setting for IXGBE to "n" to disable the components which require SSE4.2. /Bruce
[dpdk-dev] [PATCH 0/2] introduce dev_ops to get extended statistics of a device
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz > Sent: Wednesday, July 23, 2014 5:29 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 0/2] introduce dev_ops to get extended statistics > of > a device > > The generic statistics structure is getting bigger as new statistics are > added in specific devices. For instance, fdir, tx_pause or loopback > stats do not apply on virtual devices. It won't be possible to add every > specific statistics in this generic stats structure, but on the other > hand these specific statistics are useful for debugging purpose. > > This 2 patches introduces xstats_get() and xstats_reset() in > dev_ops. When registered by a device, it can be used to provide > arbitrary statistics that are identified by a name, as done by eththool > in kernel. > > After that, some statistics could be moved from the generic structure to > this new framework, but it will be part of another patch series as it > should be discussed first. > I like the idea, so Ack on the concept. :-)
[dpdk-dev] free a memzone
Rather than freeing the previously allocated memzone, could you not just re-initialize the mempool using something like rte_mempool_xmem_create? > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mahdi Dashtbozorgi > Sent: Wednesday, July 23, 2014 2:05 AM > To: dev at dpdk.org > Subject: Re: [dpdk-dev] free a memzone > > Hi guys, > > Is there any suggestion to free the previously allocated memzone? > I really need help in this issue. > Any help is appreciated. > > Best Regards, > Mahdi. > > > > On Tue, Jul 22, 2014 at 4:03 PM, Mahdi Dashtbozorgi > wrote: > > > Hi, > > > > I have two processes, which uses DPDK multi-process feature to communicate. > > Master process captures packets from NIC and put them to a ring buffer, > > which is shared between master and slave process. > > The slave process looks up the shared ring buffer using rte_ring_lookup > > function and reads the packets. > > The slave process needs a memory pool, too. Therefore, it creates a > > mempool using rte_mempool_create. But If the slave process crashes during > > its processing and runs again, rte_mempool_create function fails and tells > > that there is a memory zone with that name. > > If I use rte_mempool_lookup in this case, the memory pool is not a clean > > memory pool. Because the previous run of slave process did not terminate > > gracefully and did not return all the objects to the pool. > > Is there any function to free an existing memory zone, which I call before > > rte_mempool_create to ensure that previous memory pool does not exists > > anymore? > > > > Best Regards, > > Mahdi. > >
[dpdk-dev] How to change the mbuf size
Thanks, Helin, I got it. -Original Message- From: Zhang, Helin [mailto:helin.zh...@intel.com] Sent: Tuesday, July 22, 2014 10:42 PM To: GongJinrong; dev at dpdk.org Subject: RE: [dpdk-dev] How to change the mbuf size Hi John No, you do not need to change the mbuf size, you just need to configure the maximum packet length and jumbo frame correctly. Of cause, if you want to put the whole packet into a mbuf, you can define size of mbuf you wanted when calling rte_mempool_create() during initialization. Regards, Helin > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of GongJinrong > Sent: Tuesday, July 22, 2014 5:27 PM > To: dev at dpdk.org > Subject: [dpdk-dev] How to change the mbuf size > > Hi, guys > >I am using pmd driver to capture packets, the MTU is 8000, so I > want to change the dpdk memory block size to 8000, how can I do that? > > Best Regards > John Gong
[dpdk-dev] Performance - linking against DPDK shared vs static libraries
On 23/07/14 15:58, Kavanagh, Mark B wrote: > Hi, > > I build a switching application, which links against DPDK shared libraries; > when I run the application, I see throughput of X. I then build the > application again, except this time I link against DPDK shared libraries, > having modified the application's build parameters appropriately. In this > case, I see a performance drop of around .04%, which given the high > throughput of the application is significant. > > Is such performance degradation to be expected when using DPDK shared > libraries, and if not, are there any best-known methods for preventing > performance degradation, assuming that I may be constrained to using shared > libraries going forward? Do you mean .04% or 4%? I would be more inclined to believe the latter. Shared libraries are inherently slower due to indirection from PIC, and being required to use them seems like a silly constraint in the context of high-performance computing. - antti
[dpdk-dev] dpdk-1.7.0 bug report
Hi, 2014-07-23 14:24, David Binderman: > dpdk-1.7.0/lib/librte_ether/rte_ether.h:208]: (style) Expression '(X & 0x2) > == 0x1' is always false. Which tool are you using? Thanks for the report -- Thomas
[dpdk-dev] Performance - linking against DPDK shared vs static libraries
Hi, I build a switching application, which links against DPDK shared libraries; when I run the application, I see throughput of X. I then build the application again, except this time I link against DPDK shared libraries, having modified the application's build parameters appropriately. In this case, I see a performance drop of around .04%, which given the high throughput of the application is significant. Is such performance degradation to be expected when using DPDK shared libraries, and if not, are there any best-known methods for preventing performance degradation, assuming that I may be constrained to using shared libraries going forward? Thanks, Mark -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] About round trip latency with DPDK
Hello, I am trying to develop a low-latency application, and I measured the round trip latency with DPDK. However I got an average of 650~720 microseconds round-trip latency with Intel 82599 10Gbps NIC. The experiment method is as follows. 2 machines (A and B) are connected back-to-back. Machine A embeds a time stamp in the packet and sends to B, B (use testpmd or l2fwd) forwards packets back to A immediately (A->B->A), and A receives packets and calculates time difference between current time and the embedded time stamp. (code : https://github.com/kay21s/dpdk/tree/master/examples/recv_send) I have 3 machines, and performing the above experiment on each pair leads to a similar latency. However, previous academic papers report that DPDK offers only a few 10 microseconds round trip latency. What's the round trip latency DPDK is supposed to offer? Have you measured it at Intel? Thanks a lot, Kai
[dpdk-dev] Performance - linking against DPDK shared vs static libraries
On Wed, Jul 23, 2014 at 09:43:49PM +, Kavanagh, Mark B wrote: > I take it ... that the performance drop when using shared libraries is > expected behavior? s/expected behavior/and unavoidable consequence/g ;) Matthew Hall.
[dpdk-dev] dpdk-1.7.0 bug report
Hello there, > 2014-07-23 14:24, David Binderman: >> dpdk-1.7.0/lib/librte_ether/rte_ether.h:208]: (style) Expression '(X & 0x2) >> == 0x1' is always false. > > Which tool are you using? cppcheck, available from sourceforge. Strongly recommended. Regards David Binderman
[dpdk-dev] [PATCH 2/2] testpmd: add a new command to get the extended statistics of a port
Add a new token in "show port" command to dump the extended statistics
of a device. It validates the new xstats framework added in previous commit.
Signed-off-by: Olivier Matz
---
app/test-pmd/cmdline.c | 22 --
app/test-pmd/config.c | 34 ++
app/test-pmd/testpmd.h | 2 ++
3 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 345be11..972ef8c 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -183,14 +183,14 @@ static void cmd_help_long_parsed(void *parsed_result,
"Display:\n"
"\n\n"
- "show port (info|stats|fdir|stat_qmap) (port_id|all)\n"
+ "show port (info|stats|xstats|fdir|stat_qmap)
(port_id|all)\n"
"Display information for port_id, or all.\n\n"
"show port rss-hash [key]\n"
"Display the RSS hash functions and RSS hash key"
" of port X\n\n"
- "clear port (info|stats|fdir|stat_qmap) (port_id|all)\n"
+ "clear port (info|stats|xstats|fdir|stat_qmap)
(port_id|all)\n"
"Clear information for port_id, or all.\n\n"
"show config (rxtx|cores|fwd)\n"
@@ -5015,12 +5015,18 @@ static void cmd_showportall_parsed(void *parsed_result,
if (!strcmp(res->what, "stats"))
for (i = 0; i < nb_ports; i++)
nic_stats_clear(i);
+ else if (!strcmp(res->what, "xstats"))
+ for (i = 0; i < nb_ports; i++)
+ nic_xstats_clear(i);
} else if (!strcmp(res->what, "info"))
for (i = 0; i < nb_ports; i++)
port_infos_display(i);
else if (!strcmp(res->what, "stats"))
for (i = 0; i < nb_ports; i++)
nic_stats_display(i);
+ else if (!strcmp(res->what, "xstats"))
+ for (i = 0; i < nb_ports; i++)
+ nic_xstats_display(i);
else if (!strcmp(res->what, "fdir"))
for (i = 0; i < nb_ports; i++)
fdir_get_infos(i);
@@ -5036,13 +5042,13 @@ cmdline_parse_token_string_t cmd_showportall_port =
TOKEN_STRING_INITIALIZER(struct cmd_showportall_result, port, "port");
cmdline_parse_token_string_t cmd_showportall_what =
TOKEN_STRING_INITIALIZER(struct cmd_showportall_result, what,
-"info#stats#fdir#stat_qmap");
+"info#stats#xstats#fdir#stat_qmap");
cmdline_parse_token_string_t cmd_showportall_all =
TOKEN_STRING_INITIALIZER(struct cmd_showportall_result, all, "all");
cmdline_parse_inst_t cmd_showportall = {
.f = cmd_showportall_parsed,
.data = NULL,
- .help_str = "show|clear port info|stats|fdir|stat_qmap all",
+ .help_str = "show|clear port info|stats|xstats|fdir|stat_qmap all",
.tokens = {
(void *)_showportall_show,
(void *)_showportall_port,
@@ -5068,10 +5074,14 @@ static void cmd_showport_parsed(void *parsed_result,
if (!strcmp(res->show, "clear")) {
if (!strcmp(res->what, "stats"))
nic_stats_clear(res->portnum);
+ else if (!strcmp(res->what, "xstats"))
+ nic_xstats_clear(res->portnum);
} else if (!strcmp(res->what, "info"))
port_infos_display(res->portnum);
else if (!strcmp(res->what, "stats"))
nic_stats_display(res->portnum);
+ else if (!strcmp(res->what, "xstats"))
+ nic_xstats_display(res->portnum);
else if (!strcmp(res->what, "fdir"))
fdir_get_infos(res->portnum);
else if (!strcmp(res->what, "stat_qmap"))
@@ -5085,14 +5095,14 @@ cmdline_parse_token_string_t cmd_showport_port =
TOKEN_STRING_INITIALIZER(struct cmd_showport_result, port, "port");
cmdline_parse_token_string_t cmd_showport_what =
TOKEN_STRING_INITIALIZER(struct cmd_showport_result, what,
-"info#stats#fdir#stat_qmap");
+"info#stats#xstats#fdir#stat_qmap");
cmdline_parse_token_num_t cmd_showport_portnum =
TOKEN_NUM_INITIALIZER(struct cmd_showport_result, portnum, INT32);
cmdline_parse_inst_t cmd_showport = {
.f = cmd_showport_parsed,
.data = NULL,
- .help_str = "show|clear port info|stats|fdir|stat_qmap X (X = port
number)",
+ .help_str = "show|clear port info|stats|xstats|fdir|stat_qmap X (X =
port number)",
.tokens = {
(void *)_showport_show,
(void *)_showport_port,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index c72f6ee..0a42ee9
[dpdk-dev] [PATCH 1/2] ethdev: add a new rte_eth_xstats_get method to retrieve extended statistics
This method can be implemented by a poll mode driver to provide
non-standard statistics (which are not part of the generic statistics
structure). Each statistic is returned in a generic form: "name" and
"value" and can be used to dump PMD-specific statistics in the same way
than ethtool in linux kernel.
If the PMD does not provide the xstats_get and xstats_set functions, the
ethdev API will return the generic statistics in the xstats format
(name, value).
This commit opens the door for a clean-up of the generic statistics
structure, only keeping statistics that are really common to all PMDs
and moving specific ones into the xstats API.
Reviewed-by: David Marchand
Signed-off-by: Olivier Matz
---
lib/librte_ether/rte_ethdev.c | 137 ++
lib/librte_ether/rte_ethdev.h | 60 +-
2 files changed, 195 insertions(+), 2 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index fd1010a..b71b679 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -114,6 +114,48 @@ static uint8_t nb_ports = 0;
/* spinlock for eth device callbacks */
static rte_spinlock_t rte_eth_dev_cb_lock = RTE_SPINLOCK_INITIALIZER;
+/* store statistics names and its offset in stats structure */
+struct rte_eth_xstats_name_off {
+ char name[RTE_ETH_XSTATS_NAME_SIZE];
+ unsigned offset;
+};
+
+static struct rte_eth_xstats_name_off rte_stats_strings[] = {
+{"rx_packets", offsetof(struct rte_eth_stats, ipackets)},
+{"tx_packets", offsetof(struct rte_eth_stats, opackets)},
+{"rx_bytes", offsetof(struct rte_eth_stats, ibytes)},
+{"tx_bytes", offsetof(struct rte_eth_stats, obytes)},
+{"tx_errors", offsetof(struct rte_eth_stats, oerrors)},
+{"rx_missed_errors", offsetof(struct rte_eth_stats, imissed)},
+{"rx_crc_errors", offsetof(struct rte_eth_stats, ibadcrc)},
+{"rx_bad_length_errors", offsetof(struct rte_eth_stats, ibadlen)},
+{"rx_errors", offsetof(struct rte_eth_stats, ierrors)},
+{"alloc_rx_buff_failed", offsetof(struct rte_eth_stats, rx_nombuf)},
+{"fdir_match", offsetof(struct rte_eth_stats, fdirmatch)},
+{"fdir_miss", offsetof(struct rte_eth_stats, fdirmiss)},
+{"tx_flow_control_xon", offsetof(struct rte_eth_stats, tx_pause_xon)},
+{"rx_flow_control_xon", offsetof(struct rte_eth_stats, rx_pause_xon)},
+{"tx_flow_control_xoff", offsetof(struct rte_eth_stats,
tx_pause_xoff)},
+{"rx_flow_control_xoff", offsetof(struct rte_eth_stats,
rx_pause_xoff)},
+};
+#define RTE_NB_STATS (sizeof(rte_stats_strings) / sizeof(rte_stats_strings[0]))
+
+static struct rte_eth_xstats_name_off rte_rxq_stats_strings[] = {
+ {"rx_packets", offsetof(struct rte_eth_stats, q_ipackets)},
+ {"rx_bytes", offsetof(struct rte_eth_stats, q_ibytes)},
+};
+#define RTE_NB_RXQ_STATS (sizeof(rte_rxq_stats_strings) / \
+ sizeof(rte_rxq_stats_strings[0]))
+
+static struct rte_eth_xstats_name_off rte_txq_stats_strings[] = {
+ {"tx_packets", offsetof(struct rte_eth_stats, q_opackets)},
+ {"tx_bytes", offsetof(struct rte_eth_stats, q_obytes)},
+ {"tx_errors", offsetof(struct rte_eth_stats, q_errors)},
+};
+#define RTE_NB_TXQ_STATS (sizeof(rte_txq_stats_strings) / \
+ sizeof(rte_txq_stats_strings[0]))
+
+
/**
* The user application callback description.
*
@@ -1201,6 +1243,101 @@ rte_eth_stats_reset(uint8_t port_id)
(*dev->dev_ops->stats_reset)(dev);
}
+/* retrieve ethdev extended statistics */
+int
+rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstats *xstats,
+ unsigned n)
+{
+ struct rte_eth_stats eth_stats;
+ struct rte_eth_dev *dev;
+ unsigned count, i, q;
+ uint64_t val;
+ char *stats_ptr;
+
+ if (port_id >= nb_ports) {
+ PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
+ return -1;
+ }
+ dev = _eth_devices[port_id];
+
+ /* implemented by the driver */
+ if (dev->dev_ops->xstats_get != NULL)
+ return (*dev->dev_ops->xstats_get)(dev, xstats, n);
+
+ /* else, return generic statistics */
+ count = RTE_NB_STATS;
+ count += dev->data->nb_rx_queues * RTE_NB_RXQ_STATS;
+ count += dev->data->nb_tx_queues * RTE_NB_TXQ_STATS;
+ if (n < count)
+ return count;
+
+ /* now fill the xstats structure */
+
+ count = 0;
+ memset(_stats, 0, sizeof(eth_stats));
+ rte_eth_stats_get(port_id, _stats);
+
+ /* global stats */
+ for (i = 0; i < RTE_NB_STATS; i++) {
+ stats_ptr = (char *)_stats + rte_stats_strings[i].offset;
+ val = *(uint64_t *)stats_ptr;
+ snprintf(xstats[count].name, sizeof(xstats[count].name),
+ "%s", rte_stats_strings[i].name);
+ xstats[count++].value = val;
+ }
+
+
[dpdk-dev] [PATCH 0/2] introduce dev_ops to get extended statistics of a device
The generic statistics structure is getting bigger as new statistics are added in specific devices. For instance, fdir, tx_pause or loopback stats do not apply on virtual devices. It won't be possible to add every specific statistics in this generic stats structure, but on the other hand these specific statistics are useful for debugging purpose. This 2 patches introduces xstats_get() and xstats_reset() in dev_ops. When registered by a device, it can be used to provide arbitrary statistics that are identified by a name, as done by eththool in kernel. After that, some statistics could be moved from the generic structure to this new framework, but it will be part of another patch series as it should be discussed first. Olivier Matz (2): ethdev: add a new rte_eth_xstats_get method to retrieve extended statistics testpmd: add a new command to get the extended statistics of a port app/test-pmd/cmdline.c| 22 +-- app/test-pmd/config.c | 34 +++ app/test-pmd/testpmd.h| 2 + lib/librte_ether/rte_ethdev.c | 137 ++ lib/librte_ether/rte_ethdev.h | 60 +- 5 files changed, 247 insertions(+), 8 deletions(-) -- 2.0.1
[dpdk-dev] dpdk-1.7.0 bug report
Hello there, dpdk-1.7.0/lib/librte_ether/rte_ether.h:208]: (style) Expression '(X & 0x2) == 0x1' is always false. Source code is ??? return ((ea->addr_bytes[0] & ETHER_LOCAL_ADMIN_ADDR) == 1); but #define ETHER_LOCAL_ADMIN_ADDR 0x02 /**< Locally assigned Eth. address. */ Regards David Binderman
[dpdk-dev] [PATCH] eal/linuxapp: Add parameter to specify master lcore id
Hi all, the only issue I could imagine is that current DPDK applications are utilizing the implicit assumption that the master lcore is always set to the first available lcore. I would consider this as a "bug" in the application because it sets up its worker threads not "properly". However, as far I could check it, the DPDK framework seems to cope with it correctly. It would be nice if somebody else could confirm my statement. Thanks, Simon On 23.07.2014 10:53, Hiroshi Shimamoto wrote: > Hi, > >> Subject: Re: [dpdk-dev] [PATCH] eal/linuxapp: Add parameter to specify >> master lcore id >> >> Hi Hiroshi, >> >> 2014-07-22 23:40, Hiroshi Shimamoto: >>> does anyone have interest in this functionality? >>> >>> I think this is important and useful. >>> Since we should care about core assignment to get high performance >>> and the master lcore thread is special in DPDK, we will want to >>> assign the master to the target core. >>> For example, with hyperthreading I'd like to make a pair of packet >>> processing threads into one physical core and separate the master >>> thread which does some management. >> >> Thank you for showing your interest. >> Does it mean you carefully reviewed this patch? In this case, I'd appreciate >> a note "Reviewed-by:". > > Not yet deeply, wait a bit, we're testing this patch in our application. > Will report if it works fine. > > By the way, we should add the same code into the BSD code, right? > > thanks, > Hiroshi > >> >> Thanks >> -- >> Thomas
[dpdk-dev] free a memzone
Hi guys, Is there any suggestion to free the previously allocated memzone? I really need help in this issue. Any help is appreciated. Best Regards, Mahdi. On Tue, Jul 22, 2014 at 4:03 PM, Mahdi Dashtbozorgi wrote: > Hi, > > I have two processes, which uses DPDK multi-process feature to communicate. > Master process captures packets from NIC and put them to a ring buffer, > which is shared between master and slave process. > The slave process looks up the shared ring buffer using rte_ring_lookup > function and reads the packets. > The slave process needs a memory pool, too. Therefore, it creates a > mempool using rte_mempool_create. But If the slave process crashes during > its processing and runs again, rte_mempool_create function fails and tells > that there is a memory zone with that name. > If I use rte_mempool_lookup in this case, the memory pool is not a clean > memory pool. Because the previous run of slave process did not terminate > gracefully and did not return all the objects to the pool. > Is there any function to free an existing memory zone, which I call before > rte_mempool_create to ensure that previous memory pool does not exists > anymore? > > Best Regards, > Mahdi. >
[dpdk-dev] [PATCH v2] ethdev: Rename RX/TX enable queue field for queue start and stop
Update comments for the field start_rx_per_q for better readability.
Rename the field name to rx_enable_queue for better readability too.
Accordingly Update its reference in sample vhost.
Signed-off-by: Changchun Ouyang
---
examples/vhost/main.c | 4 ++--
lib/librte_ether/rte_ethdev.h | 16 ++--
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 8
lib/librte_pmd_ixgbe/ixgbe_rxtx.h | 4 ++--
4 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 193aa25..2eea431 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -2984,9 +2984,9 @@ MAIN(int argc, char *argv[])
char pool_name[RTE_MEMPOOL_NAMESIZE];
char ring_name[RTE_MEMPOOL_NAMESIZE];
- rx_conf_default.start_rx_per_q = (uint8_t)zero_copy;
+ rx_conf_default.rx_enable_queue = (uint8_t)zero_copy;
rx_conf_default.rx_drop_en = 0;
- tx_conf_default.start_tx_per_q = (uint8_t)zero_copy;
+ tx_conf_default.tx_enable_queue = (uint8_t)zero_copy;
nb_mbuf = num_rx_descriptor
+ num_switching_cores * MBUF_CACHE_SIZE_ZCP
+ num_switching_cores * MAX_PKT_BURST;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 50df654..ba439f6 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -604,7 +604,16 @@ struct rte_eth_rxconf {
struct rte_eth_thresh rx_thresh; /**< RX ring threshold registers. */
uint16_t rx_free_thresh; /**< Drives the freeing of RX descriptors. */
uint8_t rx_drop_en; /**< Drop packets if no descriptors are available.
*/
- uint8_t start_rx_per_q; /**< start rx per queue. */
+ /**< If rx_enable_queue is true, rte_eth_dev_rx_queue_start should be
+ invocated to start RX for one queue after rte_eth_dev_start is
+ invocated, and rte_eth_dev_rx_queue_start instead of
+ rte_eth_dev_start is responsible for allocating mbuf from
+ mempool and setup the DMA physical address. It is useful in
+ such scenario: buffer address is not available at the point of
+ rte_eth_dev_start's invocating but available later, e.g. in
+ VHOST zero copy case, the buffer address used to setup DMA
+ address is available only after one VM(guest) startup. */
+ uint8_t rx_enable_queue;
};
#define ETH_TXQ_FLAGS_NOMULTSEGS 0x0001 /**< nb_segs=1 for all mbufs */
@@ -625,7 +634,10 @@ struct rte_eth_txconf {
uint16_t tx_rs_thresh; /**< Drives the setting of RS bit on TXDs. */
uint16_t tx_free_thresh; /**< Drives the freeing of TX buffers. */
uint32_t txq_flags; /**< Set flags for the Tx queue */
- uint8_t start_tx_per_q; /**< start tx per queue. */
+ /**< If tx_enable_queue is true, rte_eth_dev_tx_queue_start must be
+ invocated to start TX for one queue after rte_eth_dev_start is
+ invocated. Refer to start_rx_per_q for the use case. */
+ uint8_t tx_enable_queue;
};
/**
diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index dfc2076..2872fad 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -1846,7 +1846,7 @@ ixgbe_dev_tx_queue_setup(struct rte_eth_dev *dev,
txq->port_id = dev->data->port_id;
txq->txq_flags = tx_conf->txq_flags;
txq->ops = _txq_ops;
- txq->start_tx_per_q = tx_conf->start_tx_per_q;
+ txq->tx_enable_queue = tx_conf->tx_enable_queue;
/*
* Modification to set VFTDT for virtual function if vf is detected
@@ -2091,7 +2091,7 @@ ixgbe_dev_rx_queue_setup(struct rte_eth_dev *dev,
rxq->crc_len = (uint8_t) ((dev->data->dev_conf.rxmode.hw_strip_crc) ?
0 : ETHER_CRC_LEN);
rxq->drop_en = rx_conf->rx_drop_en;
- rxq->start_rx_per_q = rx_conf->start_rx_per_q;
+ rxq->rx_enable_queue = rx_conf->rx_enable_queue;
/*
* Allocate RX ring hardware descriptors. A memzone large enough to
@@ -3652,13 +3652,13 @@ ixgbe_dev_rxtx_start(struct rte_eth_dev *dev)
for (i = 0; i < dev->data->nb_tx_queues; i++) {
txq = dev->data->tx_queues[i];
- if (!txq->start_tx_per_q)
+ if (!txq->tx_enable_queue)
ixgbe_dev_tx_queue_start(dev, i);
}
for (i = 0; i < dev->data->nb_rx_queues; i++) {
rxq = dev->data->rx_queues[i];
- if (!rxq->start_rx_per_q)
+ if (!rxq->rx_enable_queue)
ixgbe_dev_rx_queue_start(dev, i);
}
diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.h
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.h
index 64c0695..d6d856e 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.h
+++
[dpdk-dev] [PATCH] kni: optimizing the rte_kni_rx_burst
The current implementation of rte_kni_rx_burst polls the fifo for buffers.
Irrespective of success or failure, it allocates the mbuf and try to put them
into the alloc_q
if the buffers are not added to alloc_q, it frees them.
This waste lots of cpu cycles in allocating and freeing the buffers if alloc_q
is full.
The logic has been changed to:
1. Initially allocand add buffer(burstsize) to alloc_q
2. Add buffers to alloc_q only when you are pulling out the buffers.
Signed-off-by: Hemant Agrawal
---
lib/librte_kni/rte_kni.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index 76feef4..01e85f8 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -263,6 +263,9 @@ rte_kni_alloc(struct rte_mempool *pktmbuf_pool,
ctx->in_use = 1;
+ /* Allocate mbufs and then put them into alloc_q */
+ kni_allocate_mbufs(ctx);
+
return ctx;
fail:
@@ -369,8 +372,9 @@ rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf
**mbufs, unsigned num)
{
unsigned ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);
- /* Allocate mbufs and then put them into alloc_q */
- kni_allocate_mbufs(kni);
+ /* If buffers removed, allocate mbufs and then put them into alloc_q */
+ if(ret)
+ kni_allocate_mbufs(kni);
return ret;
}
--
1.7.9.6
[dpdk-dev] Performance - linking against DPDK shared vs static libraries
On Wed, 23 Jul 2014 15:58:06 + "Kavanagh, Mark B" wrote: > Hi, > > I build a switching application, which links against DPDK shared libraries; > when I run the application, I see throughput of X. I then build the > application again, except this time I link against DPDK shared libraries, > having modified the application's build parameters appropriately. In this > case, I see a performance drop of around .04%, which given the high > throughput of the application is significant. > > Is such performance degradation to be expected when using DPDK shared > libraries, and if not, are there any best-known methods for preventing > performance degradation, assuming that I may be constrained to using shared > libraries going forward? > > Thanks, > Mark > -- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please contact > the sender and delete all copies. > Shared libraries live on different pages and cause more TLB misses.
[dpdk-dev] [PATCH] igb_uio: fall back to enable/disable irq mode
On Wed, 23 Jul 2014 09:38:46 +0600 Yerden Zhumabekov wrote: > Rewritten IRQ mode handling code introduced in commit 399a3f0d > (igb_uio: fix IRQ mode handling) renders some faulty NICs (VMware > e1000, for example) unusable if INTX mode is not supported. > > This patch gets these NICs up and running, but throwing a kernel > warning. > > Signed-off-by: Yerden Zhumabekov That is because the VMWare PCI INTX is broken. The masking logic doesn't work. Rather than applying this patch a deeper fix in E1000 and DPDK handling of link state is needed. Better to just make the E1000 able to function without IRQ for Link state than just pretend masking works.
[dpdk-dev] [PATCH] eal/linuxapp: Add parameter to specify master lcore id
2014-07-23 08:53, Hiroshi Shimamoto: > 2014-07-23 09:50, Thomas Monjalon: > > 2014-07-22 23:40, Hiroshi Shimamoto: > > > does anyone have interest in this functionality? > > > > > > I think this is important and useful. > > > Since we should care about core assignment to get high performance > > > and the master lcore thread is special in DPDK, we will want to > > > assign the master to the target core. > > > For example, with hyperthreading I'd like to make a pair of packet > > > processing threads into one physical core and separate the master > > > thread which does some management. > > > > Thank you for showing your interest. > > Does it mean you carefully reviewed this patch? In this case, I'd appreciate > > a note "Reviewed-by:". > > Not yet deeply, wait a bit, we're testing this patch in our application. > Will report if it works fine. > > By the way, we should add the same code into the BSD code, right? Right. I'd prefer to reduce the duplicated footprint and have more common code between BSD and Linux. But waiting this enhancement, we have to maintain the duplicated code for BSD. -- Thomas
[dpdk-dev] [PATCH 03/10] igb_uio: dont wrap pci_num_vf function needlessly
2014-07-18 09:14, Stephen Hemminger:
> /* sriov sysfs */
> -int local_pci_num_vf(struct pci_dev *dev)
> -{
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,34)
> +static int pci_num_vf(struct pci_dev *dev)
> struct iov {
> int pos;
> int nres;
A brace is missing here.
Fixed in master branch:
http://dpdk.org/browse/dpdk/commit/?id=282e1ec8570
--
Thomas
[dpdk-dev] [PATCH] eal/linuxapp: Add parameter to specify master lcore id
Hi Hiroshi, 2014-07-22 23:40, Hiroshi Shimamoto: > does anyone have interest in this functionality? > > I think this is important and useful. > Since we should care about core assignment to get high performance > and the master lcore thread is special in DPDK, we will want to > assign the master to the target core. > For example, with hyperthreading I'd like to make a pair of packet > processing threads into one physical core and separate the master > thread which does some management. Thank you for showing your interest. Does it mean you carefully reviewed this patch? In this case, I'd appreciate a note "Reviewed-by:". Thanks -- Thomas
[dpdk-dev] [PATCH] igb_uio: fall back to enable/disable irq mode
Rewritten IRQ mode handling code introduced in commit 399a3f0d
(igb_uio: fix IRQ mode handling) renders some faulty NICs (VMware
e1000, for example) unusable if INTX mode is not supported.
This patch gets these NICs up and running, but throwing a kernel
warning.
Signed-off-by: Yerden Zhumabekov
---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
index f220a12..c4ab01a 100644
--- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
+++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
@@ -620,9 +620,9 @@ igbuio_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
udev->info.irq_flags = IRQF_SHARED;
udev->mode = RTE_INTR_MODE_LEGACY;
} else {
- dev_err(>dev, "PCI INTX mask not supported\n");
- err = -EIO;
- goto fail_release_iomem;
+ dev_warn(>dev, "PCI INTX mask not supported\n");
+ udev->info.irq_flags = IRQF_SHARED;
+ udev->mode = RTE_INTR_MODE_LEGACY;
}
break;
default:
--
1.7.10.4
[dpdk-dev] [PATCH] igb_uio dropped support for some faulty NICs
Hi, Recent patch 399a3f0d (igb_uio: fix IRQ mode handling) has introduces new IRQ mode handling code. As Stephen reported earlier, VMware PCI emulation of interrupts is somehow broken, so INTX mode is not supported (see http://dpdk.org/ml/archives/dev/2014-May/002432.html). The current code makes VMware e1000 unbindable to igb_uio driver and throwing -EIO error. What I suggest is to throw a kernel warning but make the work with this kind of NIC possible. Yerden Zhumabekov (1): igb_uio: fall back to enable/disable irq mode lib/librte_eal/linuxapp/igb_uio/igb_uio.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 1.7.10.4
[dpdk-dev] [PATCH] eal/linuxapp: Add parameter to specify master lcore id
> Hi all, > > does anyone have interest in this functionality? Yes, I think this is useful for DPDK vSwitch. > > I think this is important and useful. > Since we should care about core assignment to get high performance and the > master lcore thread is special in DPDK, we will want to assign the master to > the target core. > For example, with hyperthreading I'd like to make a pair of packet processing > threads into one physical core and separate the master thread which does > some management. > > thanks, > Hiroshi >
[dpdk-dev] [PATCH v2] ethdev: Rename RX/TX enable queue field for queue start and stop
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ouyang Changchun
> Sent: Wednesday, July 23, 2014 12:48 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] ethdev: Rename RX/TX enable queue field
> for queue start and stop
>
> Update comments for the field start_rx_per_q for better readability.
> Rename the field name to rx_enable_queue for better readability too.
> Accordingly Update its reference in sample vhost.
>
> Signed-off-by: Changchun Ouyang
Acked-by Chen Jing (Mark)
> ---
> examples/vhost/main.c | 4 ++--
> lib/librte_ether/rte_ethdev.h | 16 ++--
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 8
> lib/librte_pmd_ixgbe/ixgbe_rxtx.h | 4 ++--
> 4 files changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/examples/vhost/main.c b/examples/vhost/main.c
> index 193aa25..2eea431 100644
> --- a/examples/vhost/main.c
> +++ b/examples/vhost/main.c
> @@ -2984,9 +2984,9 @@ MAIN(int argc, char *argv[])
> char pool_name[RTE_MEMPOOL_NAMESIZE];
> char ring_name[RTE_MEMPOOL_NAMESIZE];
>
> - rx_conf_default.start_rx_per_q = (uint8_t)zero_copy;
> + rx_conf_default.rx_enable_queue = (uint8_t)zero_copy;
> rx_conf_default.rx_drop_en = 0;
> - tx_conf_default.start_tx_per_q = (uint8_t)zero_copy;
> + tx_conf_default.tx_enable_queue = (uint8_t)zero_copy;
> nb_mbuf = num_rx_descriptor
> + num_switching_cores * MBUF_CACHE_SIZE_ZCP
> + num_switching_cores * MAX_PKT_BURST;
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index 50df654..ba439f6 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -604,7 +604,16 @@ struct rte_eth_rxconf {
> struct rte_eth_thresh rx_thresh; /**< RX ring threshold registers. */
> uint16_t rx_free_thresh; /**< Drives the freeing of RX descriptors.
> */
> uint8_t rx_drop_en; /**< Drop packets if no descriptors are available.
> */
> - uint8_t start_rx_per_q; /**< start rx per queue. */
> + /**< If rx_enable_queue is true, rte_eth_dev_rx_queue_start
> should be
> + invocated to start RX for one queue after rte_eth_dev_start
> is
> + invocated, and rte_eth_dev_rx_queue_start instead of
> + rte_eth_dev_start is responsible for allocating mbuf from
> + mempool and setup the DMA physical address. It is useful in
> + such scenario: buffer address is not available at the point of
> + rte_eth_dev_start's invocating but available later, e.g. in
> + VHOST zero copy case, the buffer address used to setup
> DMA
> + address is available only after one VM(guest) startup. */
> + uint8_t rx_enable_queue;
> };
>
> #define ETH_TXQ_FLAGS_NOMULTSEGS 0x0001 /**< nb_segs=1 for all
> mbufs */
> @@ -625,7 +634,10 @@ struct rte_eth_txconf {
> uint16_t tx_rs_thresh; /**< Drives the setting of RS bit on TXDs. */
> uint16_t tx_free_thresh; /**< Drives the freeing of TX buffers. */
> uint32_t txq_flags; /**< Set flags for the Tx queue */
> - uint8_t start_tx_per_q; /**< start tx per queue. */
> + /**< If tx_enable_queue is true, rte_eth_dev_tx_queue_start must
> be
> + invocated to start TX for one queue after rte_eth_dev_start
> is
> + invocated. Refer to start_rx_per_q for the use case. */
> + uint8_t tx_enable_queue;
> };
>
> /**
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> index dfc2076..2872fad 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> @@ -1846,7 +1846,7 @@ ixgbe_dev_tx_queue_setup(struct rte_eth_dev
> *dev,
> txq->port_id = dev->data->port_id;
> txq->txq_flags = tx_conf->txq_flags;
> txq->ops = _txq_ops;
> - txq->start_tx_per_q = tx_conf->start_tx_per_q;
> + txq->tx_enable_queue = tx_conf->tx_enable_queue;
>
> /*
>* Modification to set VFTDT for virtual function if vf is detected
> @@ -2091,7 +2091,7 @@ ixgbe_dev_rx_queue_setup(struct rte_eth_dev
> *dev,
> rxq->crc_len = (uint8_t) ((dev->data-
> >dev_conf.rxmode.hw_strip_crc) ?
> 0 : ETHER_CRC_LEN);
> rxq->drop_en = rx_conf->rx_drop_en;
> - rxq->start_rx_per_q = rx_conf->start_rx_per_q;
> + rxq->rx_enable_queue = rx_conf->rx_enable_queue;
>
> /*
>* Allocate RX ring hardware descriptors. A memzone large enough to
> @@ -3652,13 +3652,13 @@ ixgbe_dev_rxtx_start(struct rte_eth_dev *dev)
>
> for (i = 0; i < dev->data->nb_tx_queues; i++) {
> txq = dev->data->tx_queues[i];
> - if (!txq->start_tx_per_q)
> + if (!txq->tx_enable_queue)
> ixgbe_dev_tx_queue_start(dev, i);
> }
>
> for (i = 0; i <
[dpdk-dev] [PATCH] virtio: Support mergeable buffer in virtio PMD.
Hi Thomas Ok, I will resolve the conflict and send the v2 patch. Thanks and regards, Changchun -Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Tuesday, July 22, 2014 9:29 PM To: Ouyang, Changchun Cc: dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH] virtio: Support mergeable buffer in virtio PMD. Hi, 2014-07-12 10:24, Ouyang Changchun: > This patch supports mergeable buffer feature in DPDK based virtio PMD, > which can receive jumbo frame with larger size, like 3K, 4K or even 9K. > > Signed-off-by: Ouyang Changchun Could you please rebase your patch on current master branch? There is a conflict about statistics and I'd prefer you manage it by yourself. The conflicting commit is "virtio: maintain stats per queue": http://dpdk.org/browse/dpdk/commit/?id=9658d17da27bdaa By the way, it would be really helpful if someone would like to carefully review this patch. Thanks -- Thomas
[dpdk-dev] [PATCH] eal/linuxapp: Add parameter to specify master lcore id
Hi all,
does anyone have interest in this functionality?
I think this is important and useful.
Since we should care about core assignment to get high performance
and the master lcore thread is special in DPDK, we will want to
assign the master to the target core.
For example, with hyperthreading I'd like to make a pair of packet
processing threads into one physical core and separate the master
thread which does some management.
thanks,
Hiroshi
> Subject: Re: [dpdk-dev] [PATCH] eal/linuxapp: Add parameter to specify master
> lcore id
>
> Comments?
>
> On 08.07.2014 11:42, Simon Kuenzer wrote:
> > Here are some comments about the use case of this patch:
> >
> > This patch is especially useful in cases where DPDK applications scale
> > their CPU resources at runtime via starting and stopping slave lcores.
> > Since the coremask defines the maximum scale-out for such a application,
> > the master lcore becomes to the minimum scale-in.
> > Imagine, running multiple primary processed of such DPDK applications,
> > users might want to overlap the coremasks for scaling. However, it would
> > still make sense to run the master lcores on different CPU cores.
> >
> > In DPDK vSwitch we might end up in such a scenario with a future release:
> >https://lists.01.org/pipermail/dpdk-ovs/2014-March/000770.html
> >https://lists.01.org/pipermail/dpdk-ovs/2014-March/000773.html
> >
> > Thanks,
> >
> > Simon
> >
> > On 08.07.2014 10:28, Simon Kuenzer wrote:
> >> This commit enables users to specify the lcore id that
> >> is used as master lcore.
> >>
> >> Signed-off-by: Simon Kuenzer
> >> ---
> >> lib/librte_eal/linuxapp/eal/eal.c | 33
> >> +
> >> 1 file changed, 33 insertions(+)
> >>
> >> diff --git a/lib/librte_eal/linuxapp/eal/eal.c
> >> b/lib/librte_eal/linuxapp/eal/eal.c
> >> index 573fd06..4ad5b9b 100644
> >> --- a/lib/librte_eal/linuxapp/eal/eal.c
> >> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> >> @@ -101,6 +101,7 @@
> >> #define OPT_XEN_DOM0"xen-dom0"
> >> #define OPT_CREATE_UIO_DEV "create-uio-dev"
> >> #define OPT_VFIO_INTR"vfio-intr"
> >> +#define OPT_MASTER_LCORE "master-lcore"
> >>
> >> #define RTE_EAL_BLACKLIST_SIZE0x100
> >>
> >> @@ -336,6 +337,7 @@ eal_usage(const char *prgname)
> >> "[--proc-type primary|secondary|auto] \n\n"
> >> "EAL options:\n"
> >> " -c COREMASK : A hexadecimal bitmask of cores to run
> >> on\n"
> >> + " --"OPT_MASTER_LCORE" ID: Core ID that is used as master\n"
> >> " -n NUM : Number of memory channels\n"
> >> " -v : Display version information on startup\n"
> >> " -d LIB.so: add driver (can be used multiple times)\n"
> >> @@ -468,6 +470,21 @@ eal_parse_coremask(const char *coremask)
> >> return 0;
> >> }
> >>
> >> +/* Changes the lcore id of the master thread */
> >> +static int
> >> +eal_parse_master_lcore(const char *arg)
> >> +{
> >> +struct rte_config *cfg = rte_eal_get_configuration();
> >> +int master_lcore = atoi(arg);
> >> +
> >> +if (!(master_lcore >= 0 && master_lcore < RTE_MAX_LCORE))
> >> +return -1;
> >> +if (cfg->lcore_role[master_lcore] != ROLE_RTE)
> >> +return -1;
> >> +cfg->master_lcore = master_lcore;
> >> +return 0;
> >> +}
> >> +
> >> static int
> >> eal_parse_syslog(const char *facility)
> >> {
> >> @@ -653,6 +670,7 @@ eal_parse_args(int argc, char **argv)
> >> {OPT_HUGE_DIR, 1, 0, 0},
> >> {OPT_NO_SHCONF, 0, 0, 0},
> >> {OPT_PROC_TYPE, 1, 0, 0},
> >> +{OPT_MASTER_LCORE, 1, 0, 0},
> >> {OPT_FILE_PREFIX, 1, 0, 0},
> >> {OPT_SOCKET_MEM, 1, 0, 0},
> >> {OPT_PCI_WHITELIST, 1, 0, 0},
> >> @@ -802,6 +820,21 @@ eal_parse_args(int argc, char **argv)
> >> else if (!strcmp(lgopts[option_index].name,
> >> OPT_PROC_TYPE)) {
> >> internal_config.process_type =
> >> eal_parse_proc_type(optarg);
> >> }
> >> +else if (!strcmp(lgopts[option_index].name,
> >> OPT_MASTER_LCORE)) {
> >> +if (!coremask_ok) {
> >> +RTE_LOG(ERR, EAL, "please specify the master "
> >> +"lcore id after specifying "
> >> +"the coremask\n");
> >> +eal_usage(prgname);
> >> +return -1;
> >> +}
> >> +if (eal_parse_master_lcore(optarg) < 0) {
> >> +RTE_LOG(ERR, EAL, "invalid parameter for --"
> >> +OPT_MASTER_LCORE "\n");
> >> +eal_usage(prgname);
> >> +return -1;
> >> +}
> >> +}
> >> else if (!strcmp(lgopts[option_index].name,
> >> OPT_FILE_PREFIX)) {
> >> internal_config.hugefile_prefix = optarg;
> >> }
> >>
> >
