[dpdk-dev] Multiple Ring for Multiple Cores
Dear All, I have a written code which doesn't work like I want, I wanna have a separate ring_buffer for each core (each core has its own ring), So I have a 2D array with initial values, Each core start read each row of values array, do the counter (or function) and write it back on own ring, I wanna do this because I wanna have a separate memory space (here ring_buffer) allocated for each core, Wrong answer and I don't know the problem It would be appreciated if help me, Regards, -- M at hdi Mor at dm@nd B at die
[dpdk-dev] [PATCH] examples/exception_path: bad shift operation in setup_port_lcore_affinities
CID: #30688
The operaton may have an undefined behavior or yield to an unexpected result.
In setup_port_lcore_affinities: A bit shift operation has a shift amount which
is too large or has a negative value.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Daniel Mrzyglod
---
examples/exception_path/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/exception_path/main.c b/examples/exception_path/main.c
index bec9804..c14a933 100644
--- a/examples/exception_path/main.c
+++ b/examples/exception_path/main.c
@@ -351,7 +351,7 @@ setup_port_lcore_affinities(void)
port_ids[i] = rx_port++;
}
- else if (output_cores_mask & (1ULL << i)) {
+ else if (output_cores_mask & (1ULL << (i & 0x3f))) {
/* Skip ports that are not enabled */
while ((ports_mask & (1 << tx_port)) == 0) {
tx_port++;
--
2.5.5
[dpdk-dev] [PATCH] ixgbe: fix bad shift operation in ixgbe_set_pool_tx
CID 13190 (#1 of 1): Bad bit shift operation (BAD_SHIFT)
large_shift: In expression 1 << pool, left shifting by more than 31 bits
has undefined behavior. The shift amount, pool, is at least 32.
This patch limits mask shift to be in range of 32 bit PFVFTE[1] register,
for pool > 31.
Fixes: fe3a45fd4104 ("ixgbe: add VMDq support")
Signed-off-by: Tomasz Kulasek
---
drivers/net/ixgbe/ixgbe_ethdev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index f676a64..6ae82e7 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -4428,7 +4428,7 @@ ixgbe_set_pool_tx(struct rte_eth_dev *dev, uint16_t pool,
uint8_t on)
addr = IXGBE_VFTE(pool >= ETH_64_POOLS/2);
reg = IXGBE_READ_REG(hw, addr);
- val = bit1 << pool;
+ val = bit1 << (pool & 0x01F);
if (on)
reg |= val;
--
1.7.9.5
[dpdk-dev] KNI port type in IP pipeline
According to pp. 145 of DPDK programmer's guide 2.2.0, the KNI port type is described in table 23.1. But, I cannot find any material about how to specify the KNI port type in pipeline configuration file. Unfortunately, it seems there is no related source file in $DPDK_TOP/lib/librte_port. Does packet framework already implement the KNI port type somewhere or should I implement that KNI port type by myself? regards, -- Moon-Sang Lee, SW Engineer Email: sang0627 at gmail.com Wisdom begins in wonder. *Socrates*
[dpdk-dev] ethtool doesnt work on some interface after unbinding dpdk
Well, I jumped to a conclusion too soon on the ACPI, that was a wrong statement (wishful thinking), I recreated the issue even with ACPI off This time the problem statement is more narrowed down. 1. dpdk is enabled on the interface, interfaces bound to igb_uio 3. kill the process using dpdk 3. rmmod rte_kni 4. rmmod igb_uio 5. bind interface to igb 6. ethtool, ifconfig up/down etc.. works for approximately 30 seconds, and then stops working At step #6, if I do an lspci of the device, the device is completely shut down (attached a sample lspci output - memory not initialized, irqs not present in /proc/interrupts etc..). But theres nothing in the dmesg that shows any kind of errors after the messages about the interface being bound in step #5 And the wierd part is that the device is up at step #6 for like 30 seconds before it appears shut down in the pci output. Another observation is that in step #4 when igb_uio relinquishes control of the device it still seems to leave it in an initialized state, so the only theory I can think of is whether the device being left in an initia;ized state when it was handed off to igb in step #5 caused igb to run into some error and shut down the device ? The next step is to enable debugs in igb driver and see if there are any debugs that tells more about what happened Rgds, Gopa. On Fri, Apr 15, 2016 at 12:31 PM, Gopakumar Choorakkot Edakkunni < gopakumar.c.e at gmail.com> wrote: > So looks like I figured it out .. I came across this bug reference > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728692 and thought of > checking out my problem with ACPI turned off. And with ACPI turned off, the > problem doesnt happen. So theres something that the igb driver is not happy > about when acpi is on .. Any thoughts ? > > Rgds, > Gopa. > > On Fri, Apr 15, 2016 at 10:38 AM, Gopakumar Choorakkot Edakkunni < > gopakumar.c.e at gmail.com> wrote: > >> Nothing in dmesg .. The ethtool was just a side-observation, the biggest >> problem was that after unbinding from igb_uio and rebinding to igb, if I >> follow it up with an /etc/init.d/network restart, that completely hoses the >> linux system - anyone trying to open a socket (ifconfig for example) just >> hangs. Thats how I started troubleshooting this and happened to see this >> ethtool thing along with it, not sure if its related. Also the issue >> doesn't happen with one or two interfaces, there needs to be at least five >> or six interfaces for this to happen. >> >> The other thing I noticed is that if I put some sleep (2 seconds) between >> unbind igb_uio and re-bind igb, the network-restart-hosing-system doesnt >> happen, but the ethtool issue still remains >> >> Rgds, >> Gopa. >> >> On Fri, Apr 15, 2016 at 12:50 AM, Remy Horton >> wrote: >> >>> On 14/04/2016 20:25, Gopakumar Choorakkot Edakkunni wrote: >>> [..] >>> ge8-> 06:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) root:~# ls /sys/class/net/ge8/device/driver/module/drivers/ pci:igb root:~# root:~# ethtool ge8 Settings for ge8: Cannot get device settings: No such device Cannot get wake-on-lan settings: No such device Cannot get message level: No such device Cannot get link status: No such device No data available >>> >>> Seems a little odd. Does dmesg show anything related to igb/ixgbe when >>> you try this? >>> >>> ..Remy >>> >> >> >
[dpdk-dev] [RFC PATCH v1 3/3] examples/ethtool: add xstats display command
Signed-off-by: Remy Horton
---
examples/ethtool/ethtool-app/ethapp.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/examples/ethtool/ethtool-app/ethapp.c
b/examples/ethtool/ethtool-app/ethapp.c
index 2ed4796..16ae4e9 100644
--- a/examples/ethtool/ethtool-app/ethapp.c
+++ b/examples/ethtool/ethtool-app/ethapp.c
@@ -98,6 +98,8 @@ cmdline_parse_token_string_t pcmd_rxmode_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_int_params, cmd, "rxmode");
cmdline_parse_token_string_t pcmd_portstats_token_cmd =
TOKEN_STRING_INITIALIZER(struct pcmd_int_params, cmd, "portstats");
+cmdline_parse_token_string_t pcmd_xstats_token_cmd =
+ TOKEN_STRING_INITIALIZER(struct pcmd_int_params, cmd, "xstats");
cmdline_parse_token_num_t pcmd_int_token_port =
TOKEN_NUM_INITIALIZER(struct pcmd_int_params, port, UINT16);
@@ -552,6 +554,49 @@ static void pcmd_portstats_callback(__rte_unused void
*ptr_params,
printf("Port %i: Error fetching statistics\n", params->port);
}
+static void pcmd_xstats_callback(__rte_unused void *ptr_params,
+ __rte_unused struct cmdline *ctx,
+ __rte_unused void *ptr_data)
+{
+ struct rte_eth_xstats xstats[256];
+ struct pcmd_int_params *params = ptr_params;
+ int cnt_xstats, idx_xstat;
+ struct rte_eth_xstats_name *ptr_names;
+
+
+ if (!rte_eth_dev_is_valid_port(params->port)) {
+ printf("Error: Invalid port number %i\n", params->port);
+ return;
+ }
+
+ cnt_xstats = rte_eth_xstats_names(params->port, NULL, 0);
+ if (cnt_xstats < 0) {
+ printf("Port %i: %s\n", params->port, strerror(-cnt_xstats));
+ return;
+ }
+ printf("Number of xstats: %i\n", cnt_xstats);
+ ptr_names = malloc(sizeof(struct rte_eth_xstats_name) * cnt_xstats);
+ if (cnt_xstats != rte_eth_xstats_names(
+ params->port, ptr_names, cnt_xstats)) {
+ printf("Error: Fetched and expected counts mismatch\n");
+ return;
+ }
+
+ cnt_xstats = rte_eth_xstats_get(params->port, xstats, 256);
+ if (cnt_xstats < 0) {
+ printf("Error: Unable to get xstats (%s)\n",
+ strerror(-cnt_xstats));
+ return;
+ }
+ for (idx_xstat = 0; idx_xstat < cnt_xstats; idx_xstat++) {
+ /* Assume ptr_names[x].id = x */
+ printf("%s: %lu\n", ptr_names[xstats[idx_xstat].key].name,
+ xstats[idx_xstat].value);
+ }
+ free(ptr_names);
+}
+
+
static void pcmd_ringparam_callback(__rte_unused void *ptr_params,
__rte_unused struct cmdline *ctx,
void *ptr_data)
@@ -790,6 +835,17 @@ cmdline_parse_inst_t pcmd_portstats = {
NULL
},
};
+cmdline_parse_inst_t pcmd_xstats = {
+ .f = pcmd_xstats_callback,
+ .data = NULL,
+ .help_str = "xstats \n"
+ " Print port eth xstats",
+ .tokens = {
+ (void *)_xstats_token_cmd,
+ (void *)_int_token_port,
+ NULL
+ },
+};
cmdline_parse_inst_t pcmd_ringparam = {
.f = pcmd_ringparam_callback,
.data = NULL,
@@ -858,6 +914,7 @@ cmdline_parse_ctx_t list_prompt_commands[] = {
(cmdline_parse_inst_t *)_stop,
(cmdline_parse_inst_t *)_validate,
(cmdline_parse_inst_t *)_vlan,
+ (cmdline_parse_inst_t *)_xstats,
(cmdline_parse_inst_t *)_quit,
NULL
};
--
2.5.5
[dpdk-dev] [RFC PATCH v1 2/3] drivers/net/ixgbe: change xstats to use integers
Signed-off-by: Remy Horton
---
drivers/net/ixgbe/ixgbe_ethdev.c | 87 +++-
1 file changed, 78 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3f1ebc1..4d31fe9 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -179,6 +179,10 @@ static int ixgbevf_dev_xstats_get(struct rte_eth_dev *dev,
struct rte_eth_xstats *xstats, unsigned n);
static void ixgbe_dev_stats_reset(struct rte_eth_dev *dev);
static void ixgbe_dev_xstats_reset(struct rte_eth_dev *dev);
+static int ixgbe_dev_xstats_names(__rte_unused struct rte_eth_dev *dev,
+ struct rte_eth_xstats_name *ptr_names, __rte_unused unsigned limit);
+static int ixgbevf_dev_xstats_names(__rte_unused struct rte_eth_dev *dev,
+ struct rte_eth_xstats_name *ptr_names, __rte_unused unsigned limit);
static int ixgbe_dev_queue_stats_mapping_set(struct rte_eth_dev *eth_dev,
uint16_t queue_id,
uint8_t stat_idx,
@@ -466,6 +470,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.xstats_get = ixgbe_dev_xstats_get,
.stats_reset = ixgbe_dev_stats_reset,
.xstats_reset = ixgbe_dev_xstats_reset,
+ .xstats_names = ixgbe_dev_xstats_names,
.queue_stats_mapping_set = ixgbe_dev_queue_stats_mapping_set,
.dev_infos_get= ixgbe_dev_info_get,
.dev_supported_ptypes_get = ixgbe_dev_supported_ptypes_get,
@@ -555,6 +560,7 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops = {
.xstats_get = ixgbevf_dev_xstats_get,
.stats_reset = ixgbevf_dev_stats_reset,
.xstats_reset = ixgbevf_dev_stats_reset,
+ .xstats_names = ixgbevf_dev_xstats_names,
.dev_close= ixgbevf_dev_close,
.allmulticast_enable = ixgbevf_dev_allmulticast_enable,
.allmulticast_disable = ixgbevf_dev_allmulticast_disable,
@@ -2698,6 +2704,76 @@ ixgbe_xstats_calc_num(void) {
(IXGBE_NB_TXQ_PRIO_STATS * 8);
}
+static int ixgbe_dev_xstats_names(__rte_unused struct rte_eth_dev *dev,
+ struct rte_eth_xstats_name *ptr_names, __rte_unused unsigned limit)
+{
+ const unsigned cnt_stats = ixgbe_xstats_calc_num();
+ unsigned stat, i, count, offset;
+
+ if (ptr_names != NULL) {
+ count = 0;
+ offset = 0;
+
+ /* Note: limit >= cnt_stats checked upstream
+* in rte_eth_xstats_names()
+*/
+
+ /* Extended stats from ixgbe_hw_stats */
+ for (i = 0; i < IXGBE_NB_HW_STATS; i++) {
+ snprintf(ptr_names[count].name,
+ sizeof(ptr_names[count].name),
+ "%s",
+ rte_ixgbe_stats_strings[i].name);
+ count++;
+ offset += RTE_ETH_XSTATS_NAME_SIZE;
+ }
+
+ /* RX Priority Stats */
+ for (stat = 0; stat < IXGBE_NB_RXQ_PRIO_STATS; stat++) {
+ for (i = 0; i < 8; i++) {
+ snprintf(ptr_names[count].name,
+ sizeof(ptr_names[count].name),
+ "rx_priority%u_%s", i,
+ rte_ixgbe_rxq_strings[stat].name);
+ count++;
+ offset += RTE_ETH_XSTATS_NAME_SIZE;
+ }
+ }
+
+ /* TX Priority Stats */
+ for (stat = 0; stat < IXGBE_NB_TXQ_PRIO_STATS; stat++) {
+ for (i = 0; i < 8; i++) {
+ snprintf(ptr_names[count].name,
+ sizeof(ptr_names[count].name),
+ "tx_priority%u_%s", i,
+ rte_ixgbe_txq_strings[stat].name);
+ count++;
+ offset += RTE_ETH_XSTATS_NAME_SIZE;
+ }
+ }
+ /* FIXME: Debugging check */
+ if (cnt_stats != count)
+ return -EIO;
+ }
+ return cnt_stats;
+}
+
+static int ixgbevf_dev_xstats_names(__rte_unused struct rte_eth_dev *dev,
+ struct rte_eth_xstats_name *ptr_names, __rte_unused unsigned limit)
+{
+ unsigned i;
+
+ if (limit < IXGBEVF_NB_XSTATS)
+ return -ENOMEM;
+
+ if (ptr_names != NULL)
+ for (i = 0; i < IXGBEVF_NB_XSTATS; i++)
+ snprintf(ptr_names[i].name,
+ sizeof(ptr_names[i].name),
+ "%s",
[dpdk-dev] [RFC PATCH v1 1/3] rte: change xstats to use integer keys
Signed-off-by: Remy Horton
---
lib/librte_ether/rte_ethdev.c | 87 +++
lib/librte_ether/rte_ethdev.h | 38 +++
2 files changed, 117 insertions(+), 8 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a31018e..cdd0685 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1507,6 +1507,82 @@ rte_eth_stats_reset(uint8_t port_id)
dev->data->rx_mbuf_alloc_failed = 0;
}
+static int
+rte_eth_xstats_count(uint8_t port_id)
+{
+ struct rte_eth_dev *dev;
+ int count;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
+ dev = _eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->xstats_names, -ENOTSUP);
+ count = (*dev->dev_ops->xstats_names)(dev, NULL, 0);
+ if (count >= 0) {
+ count += RTE_NB_STATS;
+ count += dev->data->nb_rx_queues * RTE_NB_RXQ_STATS;
+ count += dev->data->nb_tx_queues * RTE_NB_TXQ_STATS;
+ }
+ return count;
+}
+
+int
+rte_eth_xstats_names(uint8_t port_id, struct rte_eth_xstats_name *ptr_names,
+ unsigned limit)
+{
+ struct rte_eth_dev *dev;
+ int cnt_used_entries;
+ int cnt_expected_entries;
+ uint32_t idx, id_queue;
+ int offset;
+
+ cnt_expected_entries = rte_eth_xstats_count(port_id);
+ if (cnt_expected_entries < 0 || ptr_names == NULL)
+ return cnt_expected_entries;
+
+ if ((int)limit < cnt_expected_entries)
+ return -ERANGE;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
+ dev = _eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->xstats_names, -ENOTSUP);
+ cnt_used_entries = (*dev->dev_ops->xstats_names)(
+ dev, ptr_names, limit);
+
+ if (cnt_used_entries < 0)
+ return cnt_used_entries;
+
+ offset = cnt_used_entries * RTE_ETH_XSTATS_NAME_SIZE;
+ for (idx = 0; idx < RTE_NB_STATS; idx++) {
+ snprintf(ptr_names[cnt_used_entries].name,
+ sizeof(ptr_names[0].name),
+ "%s", rte_stats_strings[idx].name);
+ offset += RTE_ETH_XSTATS_NAME_SIZE;
+ cnt_used_entries++;
+ }
+ for (id_queue = 0; id_queue < dev->data->nb_rx_queues; id_queue++) {
+ for (idx = 0; idx < RTE_NB_RXQ_STATS; idx++) {
+ snprintf(ptr_names[cnt_used_entries].name,
+ sizeof(ptr_names[0].name),
+ "rx_q%u%s",
+ id_queue, rte_rxq_stats_strings[idx].name);
+ offset += RTE_ETH_XSTATS_NAME_SIZE;
+ cnt_used_entries++;
+ }
+
+ }
+ for (id_queue = 0; id_queue < dev->data->nb_tx_queues; id_queue++) {
+ for (idx = 0; idx < RTE_NB_TXQ_STATS; idx++) {
+ snprintf(ptr_names[cnt_used_entries].name,
+ sizeof(ptr_names[0].name),
+ "tx_q%u%s",
+ id_queue, rte_txq_stats_strings[idx].name);
+ offset += RTE_ETH_XSTATS_NAME_SIZE;
+ cnt_used_entries++;
+ }
+ }
+ return cnt_used_entries;
+}
+
/* retrieve ethdev extended statistics */
int
rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstats *xstats,
@@ -1551,8 +1627,7 @@ rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstats
*xstats,
stats_ptr = RTE_PTR_ADD(_stats,
rte_stats_strings[i].offset);
val = *stats_ptr;
- snprintf(xstats[count].name, sizeof(xstats[count].name),
- "%s", rte_stats_strings[i].name);
+ xstats[count].key = count + xcount;
xstats[count++].value = val;
}
@@ -1563,9 +1638,7 @@ rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstats
*xstats,
rte_rxq_stats_strings[i].offset +
q * sizeof(uint64_t));
val = *stats_ptr;
- snprintf(xstats[count].name, sizeof(xstats[count].name),
- "rx_q%u_%s", q,
- rte_rxq_stats_strings[i].name);
+ xstats[count].key = count + xcount;
xstats[count++].value = val;
}
}
@@ -1577,9 +1650,7 @@ rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstats
*xstats,
rte_txq_stats_strings[i].offset +
q * sizeof(uint64_t));
val = *stats_ptr;
- snprintf(xstats[count].name, sizeof(xstats[count].name),
- "tx_q%u_%s", q,
-
[dpdk-dev] [RFC PATCH v1 0/3] Remove string operations from xstats
The current extended ethernet statistics fetching involve doing several string operations, which causes performance issues if there are lots of statistics and/or network interfaces. This RFC patchset changes the API for xstats to use integer identifiers instead of strings and implements this new API for the ixgbe driver. Others drivers to follow. -- Since this will involve API & ABI breakage as previously advertised, there are several design assumptions that need consideration: *) id-name & id-value pairs for both lookup and query Permits out-of-order and non-contigious returning of names/ids/values, even though expected implmentations would in practice return items in sorted order by id. Is this sufficent/desirable future proofing? Idea is to allow possibility of drivers returning partial statistics. *) Bulk name-id mapping lookup only At the moment individual lookup is not supported, as this would impose extra overheads on drivers. The assumption is that any end user would fetch all this data once on startup and then cache the mappings. *) Replacement or additional API This patch replaces the current xstats API, but there is no inherant reason beyond maintainability why this funtionality could not be in addition rather than a replacement. What is consensus on this? Comments welcome. Remy Horton (3): rte: change xstats to use integer keys drivers/net/ixgbe: change xstats to use integer keys examples/ethtool: add xstats display command drivers/net/ixgbe/ixgbe_ethdev.c | 87 +++ examples/ethtool/ethtool-app/ethapp.c | 57 +++ lib/librte_ether/rte_ethdev.c | 87 +++ lib/librte_ether/rte_ethdev.h | 38 +++ 4 files changed, 252 insertions(+), 17 deletions(-) -- 2.5.5
[dpdk-dev] [PATCH PktGen/PCAP] let multi tx queues with pcap work
Currently, dpdk-pktgen will panic when assigning multi tx queues with pcap
packet, for example:
./app/app/build/pktgen -c f -n 2 -- -P -m "[0:1-3].0" -s 0:pcap/large.pcap
This patch fix this bug by assigning qid to memory pool name.
Signed-off-by: Zhouyi Zhou
---
app/pktgen-pcap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/pktgen-pcap.c b/app/pktgen-pcap.c
index 1af0a53..960294c 100644
--- a/app/pktgen-pcap.c
+++ b/app/pktgen-pcap.c
@@ -337,7 +337,7 @@ pktgen_pcap_parse(pcap_info_t *pcap, port_info_t *info,
unsigned qid)
wr_pcap_rewind(pcap);
- snprintf(name, sizeof(name), "%-12s%d:%d", "PCAP TX", info->pid, 0);
+ snprintf(name, sizeof(name), "%-12s%d:%d", "PCAP TX", info->pid, qid);
rte_printf_status("Process: %-*s ", 18, name);
pkt_sizes = elt_count = i = 0;
--
1.9.1
[dpdk-dev] [PATCH] ixgbe: fix bad shift operation in ixgbe_set_pool_rx
CID 13193 (#1 of 1): Bad bit shift operation (BAD_SHIFT)
large_shift: In expression 1 << pool, left shifting by more than 31 bits
has undefined behavior. The shift amount, pool, is at least 32.
This patch limits mask shift to be in range of 32 bit PFVFRE[1] register,
for pool > 31.
Fixes: fe3a45fd4104 ("ixgbe: add VMDq support")
Signed-off-by: Tomasz Kulasek
---
drivers/net/ixgbe/ixgbe_ethdev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3f1ebc1..f676a64 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -4401,7 +4401,7 @@ ixgbe_set_pool_rx(struct rte_eth_dev *dev, uint16_t pool,
uint8_t on)
addr = IXGBE_VFRE(pool >= ETH_64_POOLS/2);
reg = IXGBE_READ_REG(hw, addr);
- val = bit1 << pool;
+ val = bit1 << (pool & 0x01F);
if (on)
reg |= val;
--
1.7.9.5
[dpdk-dev] [PATCH v2 1/1] cmdline: add any multi string mode to token string
>While parsing token string there may be several modes: >- fixed single string >- multi-choice single string >- any single string > >This patch add one more mode - any multi string. > >Signed-off-by: Piotr Azarewicz Does this patch also require updates to the documentation? > Regards, Keith
[dpdk-dev] [PATCH 06/36] mempool: update library version
On 04/14/2016 12:19 PM, Olivier Matz wrote: > Next changes of this patch series are too heavy to keep a compat > layer. So bump the version number of the library. > > Signed-off-by: Olivier Matz > --- > doc/guides/rel_notes/release_16_04.rst | 2 +- > lib/librte_mempool/Makefile| 2 +- > lib/librte_mempool/rte_mempool_version.map | 6 ++ > 3 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/doc/guides/rel_notes/release_16_04.rst > b/doc/guides/rel_notes/release_16_04.rst > index d0a09ef..5fe172d 100644 > --- a/doc/guides/rel_notes/release_16_04.rst > +++ b/doc/guides/rel_notes/release_16_04.rst > @@ -513,7 +513,7 @@ The libraries prepended with a plus sign were incremented > in this version. > librte_kvargs.so.1 > librte_lpm.so.2 > librte_mbuf.so.2 > - librte_mempool.so.1 > + + librte_mempool.so.2 > librte_meter.so.1 > + librte_pipeline.so.3 > librte_pmd_bond.so.1 This will go in doc/guides/rel_notes/release_16_07.rst (the file did not exist at the time the patch series was created).
[dpdk-dev] [PATCH PktGen/PCAP] let multi tx queues with pcap work
Thank you.
>Currently, dpdk-pktgen will panic when assigning multi tx queues with pcap
>packet, for example:
>./app/app/build/pktgen -c f -n 2 -- -P -m "[0:1-3].0" -s 0:pcap/large.pcap
>
>This patch fix this bug by assigning qid to memory pool name.
>
>Signed-off-by: Zhouyi Zhou
>---
> app/pktgen-pcap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/app/pktgen-pcap.c b/app/pktgen-pcap.c
>index 1af0a53..960294c 100644
>--- a/app/pktgen-pcap.c
>+++ b/app/pktgen-pcap.c
>@@ -337,7 +337,7 @@ pktgen_pcap_parse(pcap_info_t *pcap, port_info_t *info,
>unsigned qid)
>
> wr_pcap_rewind(pcap);
>
>- snprintf(name, sizeof(name), "%-12s%d:%d", "PCAP TX", info->pid, 0);
>+ snprintf(name, sizeof(name), "%-12s%d:%d", "PCAP TX", info->pid, qid);
> rte_printf_status("Process: %-*s ", 18, name);
>
> pkt_sizes = elt_count = i = 0;
>--
>1.9.1
>
>
>
Regards,
Keith
[dpdk-dev] [PATCH 26/36] mempool: introduce a function to create an empty mempool
>
>
>On 04/14/2016 05:57 PM, Wiles, Keith wrote:
>>> Introduce a new function rte_mempool_create_empty()
>>> that allocates a mempool that is not populated.
>>>
>>> The functions rte_mempool_create() and rte_mempool_xmem_create()
>>> now make use of it, making their code much easier to read.
>>> Currently, they are the only users of rte_mempool_create_empty()
>>> but the function will be made public in next commits.
>>>
>>> Signed-off-by: Olivier Matz
>>> +/* create an empty mempool */
>>> +static struct rte_mempool *
>>> +rte_mempool_create_empty(const char *name, unsigned n, unsigned elt_size,
>>> + unsigned cache_size, unsigned private_data_size,
>>> + int socket_id, unsigned flags)
>>> {
>>
>> When two processes need to use the same mempool, do we have a race condition
>> with one doing a rte_mempool_create_empty() and the other process tries to
>> use it when it finds that mempool before being fully initialized by the
>> first process?
>>
>
>I'm not an expert of the dpdk multiprocess model. But I would
>say that there are a lot of possible race conditions like this
>(ex: a port is created but not started), and I assume that
>applications doing multiprocess have their synchronization.
>
>If we really want a solution in mempool, we could:
>
>- remove the TAILQ_INSERT_TAIL() from rte_mempool_create()
>- create a new function rte_mempool_share() that adds the
> mempool in the tailq for multiprocess. This function would
> be called at the end of rte_mempool_create(), or by the
> user if using rte_mempool_create_empty().
>
>I may be mistaking but I don't feel it's really required. Any
>comment from a multiprocess expert is welcome though.
Yes, I agree we should have the developer handle the multiprocess
synchronization. The only thing I think we can do is provide a sync point API,
but that is all I can think of to do.
Maybe instead of adding a fix for each place in DPDK, we require the developer
to add the sync up when he has done all of the inits in his code or we provide
one. Maybe a minor issue and we can ignore my comments for now.
>
>
>Regards,
>Olivier
>
Regards,
Keith
[dpdk-dev] [PATCH 10/36] mempool: use the list to iterate the mempool elements
>Hi,
>
>On 04/14/2016 05:33 PM, Wiles, Keith wrote:
>>>
>>> static void
>>> -txq_mp2mr_mbuf_check(void *arg, void *start, void *end,
>>> -uint32_t index __rte_unused)
>>> +txq_mp2mr_mbuf_check(struct rte_mempool *mp, void *arg, void *obj,
>>> + __rte_unused uint32_t index)
>>
>> I have seen this use of __rte_unused or attributes attached to variables and
>> structures in couple different ways.
>>
>> I have seen the placement of the attribute after and before the variable I
>> prefer the attribute to be after, but could adapt I hope.
>> Do we have a rule about where the attribute is put in this case and others.
>> I have seen the attributes for structures are always at the end of the
>> structure, which is some cases it may not compile in other places.
>>
>> I would like to suggest we place the attributes at the end of structure e.g.
>> __rte_cached_aligned and I would like to see the __rte_unused after the
>> variable as a style in the code.
>
>I agree the __rte_unused shouldn't have moved in this patch.
>
>About the default place of attributes, I've seen an exemple where
>putting it at the end didn't what I expected:
>
> struct {
> int foo;
> } __rte_cache_aligned;
>
>The expected behavior is to define a structure which is cache aligned.
>But if "rte_memory.h" is not included, it will define a structure which
>is not cache aligned, and a global variable called __rte_cache_aligned,
>without any compiler warning.
>
>The gcc doc gives some hints about where to place the attributes:
>https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
Then I suggest we start using the suggested syntax in the above link.
I did a quick read of the text and did not see where the above unused would be
placed, did someone find it?
>
>Given its length, I'm not sure the dpdk coding rules should contain
>anything more than "refer to gcc documentation" ;)
>
>Regards,
>Olivier
>
Regards,
Keith
[dpdk-dev] [RFC 2/2] librte_ether: add new fields to rte_eth_dev_info struct
2016-04-14 10:44, Reshma Pattan:
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -908,6 +908,9 @@ struct rte_eth_dev_info {
> struct rte_eth_desc_lim rx_desc_lim; /**< RX descriptors limits */
> struct rte_eth_desc_lim tx_desc_lim; /**< TX descriptors limits */
> uint32_t speed_capa; /**< Supported speeds bitmap (ETH_LINK_SPEED_). */
> + /** number of queues configured by software*/
> + uint16_t nb_rx_queues; /**< Number of RX queues. */
> + uint16_t nb_tx_queues; /**< Number of TX queues. */
> };
I think the ethdev design is strange for these structures.
struct rte_eth_dev is internal to be used inside the ethdev API
or by the drivers.
It contains struct rte_eth_dev_data which can be of interest for
the application, except the dev_private part (which could be
directly in struct rte_eth_dev).
So the global question is: how to share the device data with the
application?
Instead of giving a pointer or a copy of struct rte_eth_dev_data,
we have some different accessors:
- rte_eth_dev_info_get() with a specific struct rte_eth_dev_info
which gathers a lot of info, not only from struct rte_eth_dev_data
- rte_eth_macaddr_get()
- rte_eth_dev_socket_id()
- rte_eth_link_get() which is more than an accessor
I think having some specialized accessors is good.
But the rte_eth_dev_info_get() looks like to be a big request
without precise goal and going to break ABI really often.
There are some queues informations, some (not so precise)
offload capabilities, some steering (RSS/VMDq) informations,
the default configuration of some Intel NIC thresholds,
the speed capabilities, etc.
Shouldn't we try to streamline this API?
[dpdk-dev] ethtool doesnt work on some interface after unbinding dpdk
So looks like I figured it out .. I came across this bug reference https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728692 and thought of checking out my problem with ACPI turned off. And with ACPI turned off, the problem doesnt happen. So theres something that the igb driver is not happy about when acpi is on .. Any thoughts ? Rgds, Gopa. On Fri, Apr 15, 2016 at 10:38 AM, Gopakumar Choorakkot Edakkunni < gopakumar.c.e at gmail.com> wrote: > Nothing in dmesg .. The ethtool was just a side-observation, the biggest > problem was that after unbinding from igb_uio and rebinding to igb, if I > follow it up with an /etc/init.d/network restart, that completely hoses the > linux system - anyone trying to open a socket (ifconfig for example) just > hangs. Thats how I started troubleshooting this and happened to see this > ethtool thing along with it, not sure if its related. Also the issue > doesn't happen with one or two interfaces, there needs to be at least five > or six interfaces for this to happen. > > The other thing I noticed is that if I put some sleep (2 seconds) between > unbind igb_uio and re-bind igb, the network-restart-hosing-system doesnt > happen, but the ethtool issue still remains > > Rgds, > Gopa. > > On Fri, Apr 15, 2016 at 12:50 AM, Remy Horton > wrote: > >> On 14/04/2016 20:25, Gopakumar Choorakkot Edakkunni wrote: >> [..] >> >>> ge8-> 06:00.0 Ethernet controller: Intel Corporation 82576 Gigabit >>> Network Connection (rev 01) >>> >>> root:~# ls /sys/class/net/ge8/device/driver/module/drivers/ >>> pci:igb >>> root:~# >>> >>> root:~# ethtool ge8 >>> Settings for ge8: >>> Cannot get device settings: No such device >>> Cannot get wake-on-lan settings: No such device >>> Cannot get message level: No such device >>> Cannot get link status: No such device >>> No data available >>> >> >> Seems a little odd. Does dmesg show anything related to igb/ixgbe when >> you try this? >> >> ..Remy >> > >
[dpdk-dev] [RFC 1/2] doc: announce ABI change for rte_eth_dev_info structure
2016-04-14 10:44, Reshma Pattan: > New fields nb_rx_queues and nb_tx_queues will be added to > rte_eth_dev_info structure. > Changes to API rte_eth_dev_info_get() will be done to update > these new fields to rte_eth_dev_info object. > > Signed-off-by:reshma Pattan In general the Signed-off lines are the same as the From: field. Here it would be: Signed-off-by: Reshma Pattan (note the spaces and the uppercase) > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -90,3 +90,9 @@ Deprecation Notices >a handle, like the way kernel exposes an fd to user for locating a >specific file, and to keep all major structures internally, so that >we are likely to be free from ABI violations in future. > + > +* A librte_ether public structure ``rte_eth_dev_info`` will be changed in > 16.07. > + The proposed change will add new parameters ``nb_rx_queues``, > ``nb_tx_queues`` > + to the structure. These are the number of queues configured by software. > + Modification to definition of ``rte_eth_dev_info_get()`` will be done > + to update new parameters to ``rte_eth_dev_info`` object. It is too late for this announce as it won't appear in the doc downloaded for version 16.04. So it is obviously rejected. The question here is: are you allowed to do a small ABI change given that the ABI will be broken in this version? I would say there can be some exceptional tolerance. I have no strong opinion myself but maybe others will have one. By the way, I have some comments about the patch.
[dpdk-dev] [PATCH] examples: fix CID 30690 bad bit shift operation
It fix coverity issue:
CID 30690 (#1 of 1): Bad bit shift operation (BAD_SHIFT)
10. large_shift: In expression 1ULL << i, left shifting by more than 63 bits
has undefined behavior. The shift amount, i, is as much as 127.
Fixes: de3cfa2c9823 ("sched: initial import")
Signed-off-by: Slawomir Mrozowicz
---
examples/qos_sched/args.c | 84 +--
1 file changed, 52 insertions(+), 32 deletions(-)
diff --git a/examples/qos_sched/args.c b/examples/qos_sched/args.c
index 3e7fd08..cd077ba 100644
--- a/examples/qos_sched/args.c
+++ b/examples/qos_sched/args.c
@@ -53,7 +53,7 @@
static uint32_t app_master_core = 1;
static uint32_t app_numa_mask;
-static uint64_t app_used_core_mask = 0;
+static int app_used_core_mask[RTE_MAX_LCORE];
static uint64_t app_used_port_mask = 0;
static uint64_t app_used_rx_port_mask = 0;
static uint64_t app_used_tx_port_mask = 0;
@@ -115,22 +115,23 @@ static inline int str_is(const char *str, const char *is)
return strcmp(str, is) == 0;
}
-/* returns core mask used by DPDK */
-static uint64_t
-app_eal_core_mask(void)
+/* compare used core with eal configuration,
+ returns:
+ 1 if equal
+ 0 if differ */
+static int
+app_eal_core_check(void)
{
- uint32_t i;
- uint64_t cm = 0;
+ uint16_t i;
+ int ret = 1;
struct rte_config *cfg = rte_eal_get_configuration();
- for (i = 0; i < RTE_MAX_LCORE; i++) {
- if (cfg->lcore_role[i] == ROLE_RTE)
- cm |= (1ULL << i);
+ for (i = 0; i < RTE_MAX_LCORE && ret; i++) {
+ if ((cfg->lcore_role[i] == ROLE_RTE) != app_used_core_mask[i])
+ ret = 0;
}
- cm |= (1ULL << cfg->master_lcore);
-
- return cm;
+ return ret;
}
@@ -292,14 +293,9 @@ app_parse_flow_conf(const char *conf_str)
app_used_tx_port_mask |= mask;
app_used_port_mask |= mask;
- mask = 1lu << pconf->rx_core;
- app_used_core_mask |= mask;
-
- mask = 1lu << pconf->wt_core;
- app_used_core_mask |= mask;
-
- mask = 1lu << pconf->tx_core;
- app_used_core_mask |= mask;
+ app_used_core_mask[pconf->rx_core] = 1;
+ app_used_core_mask[pconf->wt_core] = 1;
+ app_used_core_mask[pconf->tx_core] = 1;
nb_pfc++;
@@ -335,7 +331,7 @@ app_parse_args(int argc, char **argv)
int option_index;
const char *optname;
char *prgname = argv[0];
- uint32_t i, nb_lcores;
+ uint16_t i, j, k, nb_lcores;
static struct option lgopts[] = {
{ "pfc", 1, 0, 0 },
@@ -349,6 +345,9 @@ app_parse_args(int argc, char **argv)
{ NULL, 0, 0, 0 }
};
+ for (i = 0; i < RTE_MAX_LCORE; i++)
+ app_used_core_mask[i] = 0;
+
/* initialize EAL first */
ret = rte_eal_init(argc, argv);
if (ret < 0)
@@ -436,19 +435,40 @@ app_parse_args(int argc, char **argv)
}
/* check master core index validity */
- for(i = 0; i <= app_master_core; i++) {
- if (app_used_core_mask & (1u << app_master_core)) {
- RTE_LOG(ERR, APP, "Master core index is not configured
properly\n");
- app_usage(prgname);
- return -1;
- }
+ if (app_used_core_mask[app_master_core] == 1) {
+ RTE_LOG(ERR, APP,
+ "Master core index is not configured properly\n");
+ app_usage(prgname);
+ return -1;
}
- app_used_core_mask |= 1u << app_master_core;
+ app_used_core_mask[app_master_core] = 1;
+
+ if ((app_eal_core_check() == 0) ||
+ (app_master_core != rte_get_master_lcore())) {
+
+ char used_hexstr[RTE_MAX_LCORE/4+1];
+ char conf_hexstr[RTE_MAX_LCORE/4+1];
+ int used_byte, conf_byte;
+ struct rte_config *cfg = rte_eal_get_configuration();
+
+ for (i = 0; i < RTE_MAX_LCORE/4; i++) {
+ used_byte = 0;
+ conf_byte = 0;
+ for (j = 0; j < 3; j++) {
+ k = 4 * (RTE_MAX_LCORE/4 - i - 1) + j;
+ used_byte += app_used_core_mask[k] << j;
+ conf_byte +=
+ ((cfg->lcore_role[k] ==
+ ROLE_RTE)?1:0) << j;
+ }
+ sprintf(_hexstr[i], "%1x", used_byte);
+ sprintf(_hexstr[i], "%1x", used_byte);
+ }
+
+ RTE_LOG(ERR, APP, "EAL core mask not configured properly\n");
+ RTE_LOG(ERR, APP, " must be : %s\n", used_hexstr);
+ RTE_LOG(ERR, APP, " instead of: %s\n", conf_hexstr);
- if ((app_used_core_mask != app_eal_core_mask()) ||
-
[dpdk-dev] [PATCH] mlx4: use dummy rxqs when a non-pow2 number is requested
Hi, On 03/22/2016 03:27 PM, Wiles, Keith wrote: > Hi Olivier, > >> Hi Keith, >> >> On 03/21/2016 06:38 PM, Wiles, Keith wrote: On Mar 21, 2016, at 11:10 AM, Olivier Matz wrote: When using RSS, the number of rxqs has to be a power of two. This is a problem because there is no API is dpdk that makes the application aware of that. A good compromise is to allow the application to request a number of rxqs that is not a power of 2, but having inactive queues that will never receive packets. In this configuration, a warning will be issued to users to let them know that this is not an optimal configuration. >>> >>> Not sure I like this solution. I think an error should be returned with a >>> log message instead. What if the next driver needs power of three or must >>> be odd or even number. >>> >>> The bigger problem is the application is no longer portable for any given >>> nic configuration. >>> >>> We need a method for the application to query the system for these types of >>> information. But as we do not have that API we need to just error the >>> request off. >> >> >> The initial problem is that the driver says "I support a maximum >> of X queues" and if the application configures a lower number, it >> gets an error. >> >> There is no API in DPDK to tell that only specific number of queues >> are supported. Adding an API is a solution, but in this case it's >> probably overkill. With this patch, the driver can present the proper >> number of queues to the application, knowing that the spreading of >> the packets won't be ideal (some queues won't receive packets), but >> it will work. >> >> A step further in this direction would be to configure more queues >> than asked in hardware to do a better spreading, almost similar to >> what is done with RETA tables in mlx5. But this is more complicated >> to do, especially if we want it for 16.04. > > Well I guess I must agree with the solution, but I am not real happy. Can we > mark this a temp fix until we figure out a cleaner solution as I would not > want this type of solution forever or be the standard way to handle these > problems. Back on this issue, I agree that a cleaner solution may be needed, probably in the ethdev API. I did a quick look in the drivers directory and, from what I remember, vmxnet3 also need to have a number of rxq and txq to be a power of 2. >From what I see in the code, if an application tries to configure a number of queue which is not a power of 2 on vmxnet3, the driver will fail to start without any log. Yong, do you feel a patch similar to what was done on mlx4 is feasable/suitable in vmxnet3 driver? Shouldn't at least have some error logs saying that the number of rxq/txq is invalid? It cleanup or rework is planned in the ethdev API for 16.11, maybe this is a problem that should be addressed. Regards, Olivier
[dpdk-dev] ethtool doesnt work on some interface after unbinding dpdk
Nothing in dmesg .. The ethtool was just a side-observation, the biggest problem was that after unbinding from igb_uio and rebinding to igb, if I follow it up with an /etc/init.d/network restart, that completely hoses the linux system - anyone trying to open a socket (ifconfig for example) just hangs. Thats how I started troubleshooting this and happened to see this ethtool thing along with it, not sure if its related. Also the issue doesn't happen with one or two interfaces, there needs to be at least five or six interfaces for this to happen. The other thing I noticed is that if I put some sleep (2 seconds) between unbind igb_uio and re-bind igb, the network-restart-hosing-system doesnt happen, but the ethtool issue still remains Rgds, Gopa. On Fri, Apr 15, 2016 at 12:50 AM, Remy Horton wrote: > On 14/04/2016 20:25, Gopakumar Choorakkot Edakkunni wrote: > [..] > >> ge8-> 06:00.0 Ethernet controller: Intel Corporation 82576 Gigabit >> Network Connection (rev 01) >> >> root:~# ls /sys/class/net/ge8/device/driver/module/drivers/ >> pci:igb >> root:~# >> >> root:~# ethtool ge8 >> Settings for ge8: >> Cannot get device settings: No such device >> Cannot get wake-on-lan settings: No such device >> Cannot get message level: No such device >> Cannot get link status: No such device >> No data available >> > > Seems a little odd. Does dmesg show anything related to igb/ixgbe when you > try this? > > ..Remy >
[dpdk-dev] [PATCH] port: bump ABI for pcap file support
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Thursday, April 14, 2016 7:34 PM > To: Zhang, Roy Fan > Cc: dev at dpdk.org; Dumitrescu, Cristian ; > Singh, Jasvinder > Subject: [PATCH] port: bump ABI for pcap file support > > Support of PCAP file has been added to rte_port in release 16.04 > as NEXT_ABI. It is in the standard ABI of the release 16.07. > > Signed-off-by: Thomas Monjalon > --- > doc/guides/rel_notes/deprecation.rst | 5 - > doc/guides/rel_notes/release_16_07.rst | 5 - > examples/ip_pipeline/init.c| 4 > lib/librte_port/Makefile | 2 +- > lib/librte_port/rte_port_source_sink.c | 14 -- > lib/librte_port/rte_port_source_sink.h | 3 --- > 6 files changed, 5 insertions(+), 28 deletions(-) > Acked-by: Cristian Dumitrescu
[dpdk-dev] [PATCH v2] mem: fix freeing of memzone used by ivshmem
although previous implementation returned an error when trying to release a
memzone assigned to an ivshmem device, it stills freed it.
Fixes: cd10c42eb5bc ("mem: fix ivshmem freeing")
Signed-off-by: Mauricio Vasquez B
---
v2:
solved compilation problem when ivshmem is disabled
lib/librte_eal/common/eal_common_memzone.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_memzone.c
b/lib/librte_eal/common/eal_common_memzone.c
index 711c845..a8f804c 100644
--- a/lib/librte_eal/common/eal_common_memzone.c
+++ b/lib/librte_eal/common/eal_common_memzone.c
@@ -321,15 +321,19 @@ rte_memzone_free(const struct rte_memzone *mz)
idx = ((uintptr_t)mz - (uintptr_t)mcfg->memzone);
idx = idx / sizeof(struct rte_memzone);
- addr = mcfg->memzone[idx].addr;
#ifdef RTE_LIBRTE_IVSHMEM
/*
* If ioremap_addr is set, it's an IVSHMEM memzone and we cannot
* free it.
*/
- if (mcfg->memzone[idx].ioremap_addr != 0)
- ret = -EINVAL;
+ if (mcfg->memzone[idx].ioremap_addr != 0) {
+ rte_rwlock_write_unlock(>mlock);
+ return -EINVAL;
+ }
#endif
+
+ addr = mcfg->memzone[idx].addr;
+
if (addr == NULL)
ret = -EINVAL;
else if (mcfg->memzone_cnt == 0) {
--
1.9.1
[dpdk-dev] [PATCH] mem: fix freeing of memzone used by ivshmem
This patch does not compile when ivshmem is disabled:
compile error:
CC malloc_heap.o
/home/patchWorkOrg/compilation/lib/librte_eal/common/eal_common_memzone.c(353):
error #177: label "error" was declared but never referenced
error:
^
I'll send a v2 solving this issue
On Thu, Apr 14, 2016 at 4:48 PM, Sergio Gonzalez Monroy <
sergio.gonzalez.monroy at intel.com> wrote:
> On 14/04/2016 14:48, Mauricio Vasquez B wrote:
>
>> although previous implementation returned an error when trying to release
>> a
>> memzone assigned to an ivshmem device, it stills freed it.
>>
>> Fixes: cd10c42eb5bc ("mem: fix ivshmem freeing")
>>
>> Signed-off-by: Mauricio Vasquez B <
>> mauricio.vasquezbernal at studenti.polito.it>
>> ---
>> lib/librte_eal/common/eal_common_memzone.c | 12 ++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>>
>>
> Thanks for the fix (not sure what I was thinking at the time).
>
> Acked-by: Sergio Gonzalez Monroy
>
>
[dpdk-dev] memory allocation requirements
On 15/04/2016 08:12, Olivier Matz wrote: > Hi, > > On 04/14/2016 05:39 PM, Sergio Gonzalez Monroy wrote: >>> Just to mention that some evolutions [1] are planned in mempool in >>> 16.07, allowing to populate a mempool with several chunks of memory, >>> and still ensuring that the objects are physically contiguous. It >>> completely removes the need to allocate a big virtually contiguous >>> memory zone (and also physically contiguous if not using >>> rte_mempool_create_xmem(), which is probably the case in most of >>> the applications). >>> >>> Knowing this, the code that remaps the hugepages to get the largest >>> possible physically contiguous zone probably becomes useless after >>> the mempool series. Changing it to only one mmap(file) in hugetlbfs >>> per NUMA socket would clearly simplify this part of EAL. >>> >> Are you suggesting to make those changes after the mempool series >> has been applied but keeping the current memzone/malloc behavior? > I wonder if the default property of memzone/malloc which is to > allocate physically contiguous memory shouldn't be dropped. It could > remain optional, knowing that allocating a physically contiguous zone > larger than a page cannot be guaranteed. > > But yes, I'm in favor of doing these changes in eal_memory.c, it would > drop a lot a complex code (all rtemap* stuff), and today I'm not seeing > any big issue of doing it... maybe we'll find one during the > discussion :) I'm in favor of doing those changes but then I think we need to support allocating no contig memory through memzone/malloc or other libraries such as librte_hash may not be able to get the memory they need, right? Otherwise all library would need a rework like the mempool series to deal with non-contig memory. For contig memory, I would prefer a new API for dma areas (something similar to rte_eth_dma_zone_reserve() in ethdev) that would transparently deal with the case where we have multiple huge page sizes. Sergio > Regards, > Olivier
[dpdk-dev] [RFC 2/2] librte_ether: add new fields to rte_eth_dev_info struct
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Reshma Pattan > Sent: Thursday, April 14, 2016 10:45 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [RFC 2/2] librte_ether: add new fields to > rte_eth_dev_info struct > > New fields nb_rx_queues and nb_tx_queues are added to rte_eth_dev_info > structure. > Changes to API rte_eth_dev_info_get() are done to update these new fields > to rte_eth_dev_info object. > > Signed-off-by:reshma Pattan Acked-by: John McNamara
[dpdk-dev] [PATCH 26/36] mempool: introduce a function to create an empty mempool
On 04/14/2016 05:57 PM, Wiles, Keith wrote:
>> Introduce a new function rte_mempool_create_empty()
>> that allocates a mempool that is not populated.
>>
>> The functions rte_mempool_create() and rte_mempool_xmem_create()
>> now make use of it, making their code much easier to read.
>> Currently, they are the only users of rte_mempool_create_empty()
>> but the function will be made public in next commits.
>>
>> Signed-off-by: Olivier Matz
>> +/* create an empty mempool */
>> +static struct rte_mempool *
>> +rte_mempool_create_empty(const char *name, unsigned n, unsigned elt_size,
>> +unsigned cache_size, unsigned private_data_size,
>> +int socket_id, unsigned flags)
>> {
>
> When two processes need to use the same mempool, do we have a race condition
> with one doing a rte_mempool_create_empty() and the other process tries to
> use it when it finds that mempool before being fully initialized by the first
> process?
>
I'm not an expert of the dpdk multiprocess model. But I would
say that there are a lot of possible race conditions like this
(ex: a port is created but not started), and I assume that
applications doing multiprocess have their synchronization.
If we really want a solution in mempool, we could:
- remove the TAILQ_INSERT_TAIL() from rte_mempool_create()
- create a new function rte_mempool_share() that adds the
mempool in the tailq for multiprocess. This function would
be called at the end of rte_mempool_create(), or by the
user if using rte_mempool_create_empty().
I may be mistaking but I don't feel it's really required. Any
comment from a multiprocess expert is welcome though.
Regards,
Olivier
[dpdk-dev] [RFC 1/2] doc: announce ABI change for rte_eth_dev_info structure
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Reshma Pattan > Sent: Thursday, April 14, 2016 10:45 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [RFC 1/2] doc: announce ABI change for > rte_eth_dev_info structure > > New fields nb_rx_queues and nb_tx_queues will be added to rte_eth_dev_info > structure. > Changes to API rte_eth_dev_info_get() will be done to update these new > fields to rte_eth_dev_info object. > > Signed-off-by:reshma Pattan Acked-by: John McNamara
[dpdk-dev] [PATCH 14/36] mempool: store physaddr in mempool objects
On 04/14/2016 05:40 PM, Wiles, Keith wrote: >> Store the physical address of the object in its header. It simplifies >> rte_mempool_virt2phy() and prepares the removing of the paddr[] table >> in the mempool header. >> >> Signed-off-by: Olivier Matz >> --- >> lib/librte_mempool/rte_mempool.c | 17 +++-- >> lib/librte_mempool/rte_mempool.h | 11 ++- >> 2 files changed, 17 insertions(+), 11 deletions(-) >> >> diff --git a/lib/librte_mempool/rte_mempool.c >> b/lib/librte_mempool/rte_mempool.c >> index 839b828..b8e46fc 100644 >> --- a/lib/librte_mempool/rte_mempool.c >> +++ b/lib/librte_mempool/rte_mempool.c >> @@ -132,19 +132,22 @@ static unsigned optimize_object_size(unsigned obj_size) >> typedef void (*rte_mempool_obj_iter_t)(void * /*obj_iter_arg*/, >> void * /*obj_start*/, >> void * /*obj_end*/, >> -uint32_t /*obj_index */); >> +uint32_t /*obj_index */, >> +phys_addr_t /*physaddr*/); > > What is the reason to comment out the variable names, if no reason I would > suggest we remove the comment marks and leave the var names. I just kept the initial style here. Anyway this code is removed later in the series. See "mempool: simplify xmem_usage". Olivier
[dpdk-dev] [PATCH] pci: remove deprecated specific config
On Fri, Apr 15, 2016 at 2:53 AM, Zhang, Helin wrote: > > >> -Original Message- >> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] >> Sent: Friday, April 15, 2016 5:33 AM >> To: Zhang, Helin >> Cc: dev at dpdk.org >> Subject: [PATCH] pci: remove deprecated specific config >> >> The driver i40e was using a specific PCI config before the release 16.04. >> From 16.04, it is always enabled in i40e (commit 56465cfaf). >> The API has been deprecated in the commit 68f77593823cab. >> The igb_uio implementation has been deprecated in commit b7cf8e155. >> The config helper - through igb_uio sysfs entries - is now removed. >> >> Signed-off-by: Thomas Monjalon > Acked-by: Helin Zhang Thanks. Acked-by: David Marchand -- David Marchand
[dpdk-dev] memory allocation requirements
Hi, On 04/14/2016 05:39 PM, Sergio Gonzalez Monroy wrote: >> Just to mention that some evolutions [1] are planned in mempool in >> 16.07, allowing to populate a mempool with several chunks of memory, >> and still ensuring that the objects are physically contiguous. It >> completely removes the need to allocate a big virtually contiguous >> memory zone (and also physically contiguous if not using >> rte_mempool_create_xmem(), which is probably the case in most of >> the applications). >> >> Knowing this, the code that remaps the hugepages to get the largest >> possible physically contiguous zone probably becomes useless after >> the mempool series. Changing it to only one mmap(file) in hugetlbfs >> per NUMA socket would clearly simplify this part of EAL. >> > > Are you suggesting to make those changes after the mempool series > has been applied but keeping the current memzone/malloc behavior? I wonder if the default property of memzone/malloc which is to allocate physically contiguous memory shouldn't be dropped. It could remain optional, knowing that allocating a physically contiguous zone larger than a page cannot be guaranteed. But yes, I'm in favor of doing these changes in eal_memory.c, it would drop a lot a complex code (all rtemap* stuff), and today I'm not seeing any big issue of doing it... maybe we'll find one during the discussion :) Regards, Olivier
[dpdk-dev] ethtool doesnt work on some interface after unbinding dpdk
On 14/04/2016 20:25, Gopakumar Choorakkot Edakkunni wrote: [..] > ge8-> 06:00.0 Ethernet controller: Intel Corporation 82576 Gigabit > Network Connection (rev 01) > > root:~# ls /sys/class/net/ge8/device/driver/module/drivers/ > pci:igb > root:~# > > root:~# ethtool ge8 > Settings for ge8: > Cannot get device settings: No such device > Cannot get wake-on-lan settings: No such device > Cannot get message level: No such device > Cannot get link status: No such device > No data available Seems a little odd. Does dmesg show anything related to igb/ixgbe when you try this? ..Remy
[dpdk-dev] [PATCH] i40evf: Ignore disabled HW CRC strip for Linux PF hosts
> -Original Message-
> From: David Marchand [mailto:david.marchand at 6wind.com]
> Sent: Friday, April 15, 2016 3:41 PM
> To: Topel, Bjorn
> Cc: dev at dpdk.org; Zhang, Helin ; Wu, Jingjing
>
> Subject: Re: [dpdk-dev] [PATCH] i40evf: Ignore disabled HW CRC strip for
> Linux PF
> hosts
>
> CC maintainers.
>
> On Thu, Apr 14, 2016 at 4:58 PM, Bj?rn T?pel wrote:
> > On Linux PF hosts, the VF has no means of changing the HW CRC strip
> > setting for a RX queue. It's implicitly enabled.
> >
> > This patch ignores, and warns, if HW CRC stripping was disabled.
> >
> > Signed-off-by: Bj?rn T?pel
> > ---
> > drivers/net/i40e/i40e_ethdev_vf.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> > b/drivers/net/i40e/i40e_ethdev_vf.c
> > index 2bce69b..f88eb79 100644
> > --- a/drivers/net/i40e/i40e_ethdev_vf.c
> > +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> > @@ -1567,6 +1567,8 @@ i40evf_dev_configure(struct rte_eth_dev *dev) {
> > struct i40e_adapter *ad =
> >
> I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
> > + struct rte_eth_conf *conf = >data->dev_conf;
> > + struct i40e_vf *vf;
> >
> > /* Initialize to TRUE. If any of Rx queues doesn't meet the bulk
> > * allocation or vector Rx preconditions we will reset it.
> > @@ -1576,6 +1578,19 @@ i40evf_dev_configure(struct rte_eth_dev *dev)
> > ad->tx_simple_allowed = true;
> > ad->tx_vec_allowed = true;
> >
> > + /* For Linux PF hosts, VF has no ability to disable HW CRC strip,
> > +* and is implicitly enabled by the PF.
> > +*/
> > + if (!conf->rxmode.hw_strip_crc) {
> > + vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
> > + if ((vf->version_major == I40E_VIRTCHNL_VERSION_MAJOR)
> &&
> > + (vf->version_minor <=
> I40E_VIRTCHNL_VERSION_MINOR)) {
> > + /* Peer is Linux PF host. */
> > + PMD_INIT_LOG(NOTICE, "VF can't disable HW CRC
> Strip.");
> > + conf->rxmode.hw_strip_crc = 1;
> > + }
> > + }
> > +
> > return i40evf_init_vlan(dev);
> > }
>
> Not sure this is the right way to handle it.
> The driver should return an error rather than silently discard what the
> application
> asked.
I also think it should return an error with checking if the host is kernel
driver, and crc strip is disabled in VF.
Thank you David!
Regards,
Helin
>
> >
> > --
> > 2.7.4
> >
> > --
> > Intel Sweden AB
> > Registered Office: Isafjordsgatan 30B, 164 40 Kista, Stockholm, Sweden
> > Registration Number: 556189-6027
> >
> > 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.
>
> Please, remove this.
>
>
> --
> David Marchand
[dpdk-dev] [PATCH v1 1/1] ixgbe: fix queue stop
Hi,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Piotr Azarewicz
> Sent: Thursday, April 14, 2016 6:00 PM
> To: Zhang, Helin; Ananyev, Konstantin
> Cc: dev at dpdk.org; Azarewicz, PiotrX T
> Subject: [dpdk-dev] [PATCH v1 1/1] ixgbe: fix queue stop
>
> It should be checked if queue enable bit is clear.
>
> CID 13215 : Wrong operator used (CONSTANT_EXPRESSION_RESULT)
> operator_confusion: txdctl | 33554432 is always 1/true regardless of the
> values
> of its operand. This occurs as the logical second operand of '&&'.
>
> CID 13216 : Wrong operator used (CONSTANT_EXPRESSION_RESULT)
> operator_confusion: rxdctl | 33554432 is always 1/true regardless of the
> values
> of its operand. This occurs as the logical second operand of '&&'.
>
> Coverity issue: 13215
> Coverity issue: 13216
> Fixes: 029fd06d40fa ("ixgbe: queue start and stop")
>
> Signed-off-by: Piotr Azarewicz
Acked-by: Wenzhuo Lu
Sometimes machine is smarter than human :) Thanks Piotr for handling this.
[dpdk-dev] [PATCH] pci: remove deprecated specific config
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, April 15, 2016 5:33 AM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: [PATCH] pci: remove deprecated specific config > > The driver i40e was using a specific PCI config before the release 16.04. > From 16.04, it is always enabled in i40e (commit 56465cfaf). > The API has been deprecated in the commit 68f77593823cab. > The igb_uio implementation has been deprecated in commit b7cf8e155. > The config helper - through igb_uio sysfs entries - is now removed. > > Signed-off-by: Thomas Monjalon Acked-by: Helin Zhang
[dpdk-dev] [PATCH] pci: remove deprecated specific config
The driver i40e was using a specific PCI config before the release 16.04.
>From 16.04, it is always enabled in i40e (commit 56465cfaf).
The API has been deprecated in the commit 68f77593823cab.
The igb_uio implementation has been deprecated in commit b7cf8e155.
The config helper - through igb_uio sysfs entries - is now removed.
Signed-off-by: Thomas Monjalon
---
config/common_base| 8 -
doc/guides/linux_gsg/enable_func.rst | 15 -
doc/guides/rel_notes/deprecation.rst | 7 -
lib/librte_eal/common/include/rte_pci.h | 14 -
lib/librte_eal/linuxapp/eal/eal_pci.c | 12 ---
lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 52 ---
6 files changed, 108 deletions(-)
diff --git a/config/common_base b/config/common_base
index 0124e86..1a54e4c 100644
--- a/config/common_base
+++ b/config/common_base
@@ -101,14 +101,6 @@ CONFIG_RTE_MALLOC_DEBUG=n
CONFIG_RTE_EAL_PMD_PATH=""
#
-# Special configurations in PCI Config Space for high performance
-# They are all deprecated, and will be removed later.
-#
-CONFIG_RTE_PCI_CONFIG=n
-CONFIG_RTE_PCI_EXTENDED_TAG=""
-CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE=0
-
-#
# Compile Environment Abstraction Layer to support Vmware TSC map
#
CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
diff --git a/doc/guides/linux_gsg/enable_func.rst
b/doc/guides/linux_gsg/enable_func.rst
index 076770f..ec0e04d 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -186,21 +186,6 @@ Check with the local Intel's Network Division application
engineers for firmware
The base driver to support firmware version of FVL3E will be integrated in the
next
DPDK release, so currently the validated firmware version is 4.2.6.
-Enabling Extended Tag
-~
-
-PCI configuration of ``extended_tag`` has big impact on small packet size
-performance of 40G ports. Enabling ``extended_tag`` can help 40G port to
-achieve the best performance, especially for small packet size.
-
-* Disabling/enabling ``extended_tag`` can be done in some BIOS implementations.
-
-* If BIOS does not enable it, and does not support changing it, tools
- (e.g. ``setpci`` on Linux) can be used to enable or disable ``extended_tag``.
-
-* From release 16.04, ``extended_tag`` is enabled by default during port
- initialization, users don't need to care about that anymore.
-
Use 16 Bytes RX Descriptor Size
~~~
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index a3fdbb1..c78cde7 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -20,13 +20,6 @@ Deprecation Notices
do not need to care about the kind of devices that are being used, making it
easier to add new buses later.
-* The EAL function pci_config_space_set is deprecated in release 16.04
- and will be removed from 16.07.
- Macros CONFIG_RTE_PCI_CONFIG, CONFIG_RTE_PCI_EXTENDED_TAG and
- CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE will be removed.
- The /sys entries extended_tag and max_read_request_size created by igb_uio
- will be removed.
-
* ABI changes are planned for struct rte_pci_id, i.e., add new field ``class``.
This new added ``class`` field can be used to probe pci device by class
related info. This change should impact size of struct rte_pci_id and struct
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index e692094..9f2301d 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -577,20 +577,6 @@ void rte_eal_pci_ioport_read(struct rte_pci_ioport *p,
void rte_eal_pci_ioport_write(struct rte_pci_ioport *p,
const void *data, size_t len, off_t offset);
-#ifdef RTE_PCI_CONFIG
-#include
-/**
- * Set special config space registers for performance purpose.
- * It is deprecated, as all configurations have been moved into
- * each PMDs respectively.
- *
- * @param dev
- * A pointer to a rte_pci_device structure describing the device
- * to use
- */
-void pci_config_space_set(struct rte_pci_device *dev) __rte_deprecated;
-#endif /* RTE_PCI_CONFIG */
-
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index dbf12a8..bdc08a0 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -481,18 +481,6 @@ error:
return -1;
}
-#ifdef RTE_PCI_CONFIG
-/*
- * It is deprecated, all its configurations have been moved into
- * each PMD respectively.
- */
-void
-pci_config_space_set(__rte_unused struct rte_pci_device *dev)
-{
- RTE_LOG(DEBUG, EAL, "Nothing here, as it is deprecated\n");
-}
-#endif
-
/* Read PCI config space. */
int rte_eal_pci_read_config(const struct rte_pci_device *device,
void *buf, size_t len, off_t offset)
diff --git
