* Re: Red Hat 6.5 compilation failure
From: Neil Horman @ 2016-10-31 14:16 UTC (permalink / raw)
To: Nélio Laranjeiro; +Cc: dev
In-Reply-To: <20161031104318.GC4823@autoinstall.dev.6wind.com>
On Mon, Oct 31, 2016 at 11:43:18AM +0100, Nélio Laranjeiro wrote:
> Hi all,
>
> Am facing an issue with compilation on redhat 6.5 of DPDK v16.11-rc2,
> compilation fails with:
>
> cc1: warnings being treated as errors
> /root/dpdk/drivers/net/i40e/i40e_ethdev_vf.c: In function ‘i40evf_dev_interrupt_handler’:
> /root/dpdk/drivers/net/i40e/i40e_ethdev_vf.c:1391: error: dereferencing pointer ‘v_msg’ does break strict-aliasing rules
> /root/dpdk/drivers/net/i40e/i40e_ethdev_vf.c:1397: error: dereferencing pointer ‘v_msg’ does break strict-aliasing rules
> /root/dpdk/drivers/net/i40e/i40e_ethdev_vf.c:1398: error: dereferencing pointer ‘v_msg’ does break strict-aliasing rules
> /root/dpdk/drivers/net/i40e/i40e_ethdev_vf.c:1376: note: initialized from here
>
>
> cc1: warnings being treated as errors
> /root/dpdk/drivers/net/bnxt/bnxt_hwrm.c: In function ‘bnxt_hwrm_func_driver_unregister’:
> /root/dpdk/drivers/net/bnxt/bnxt_hwrm.c:105: error: dereferencing pointer ‘req’ does break strict-aliasing rules
> /root/dpdk/drivers/net/bnxt/bnxt_hwrm.c:66: note: initialized from here
>
>
> cc1: warnings being treated as errors
> /root/dpdk/drivers/net/qede/base/ecore_mcp.c: In function ‘ecore_mcp_nvm_rd_cmd’:
> /root/dpdk/build/include/rte_memcpy.h:740: error: array subscript is above array bounds
> /root/dpdk/drivers/net/qede/base/ecore_mcp.c: In function ‘ecore_mcp_nvm_wr_cmd’:
> /root/dpdk/build/include/rte_memcpy.h:740: error: array subscript is above array bounds
> At top level:
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
>
> In doc/guides/rel_notes/supported_os.rst we still support
> "Red Hat Enterprise Linux 6.5".
>
Most of these errors stems from the fact that in i40e there is alot of casting
from structs which lay out data in typed members to structs which have flat
memory buffers, which can cause problems if the alignment of the former isn't
what you expect. You can disable strict aliasing if you want, but its a much
better idea to fix it properly.
The subscript above array options is pretty straightforward. rte_memcpy has
a case statement that blocks memory copies to be more efficient. I would
presume that there is a call site for a ecore read operation where the buffer
array is smaller than the number of bytes copied, and the compiler noticed.
> Do we still want to support it, or should we update the documentation to
> remove it?
>
I think support probably doesn't matter, but regardless of that decision, you
should likely look a bit more closely at these errors.
Neil
> Regards,
>
> --
> Nélio Laranjeiro
> 6WIND
>
^ permalink raw reply
* Re: mbuf changes
From: Morten Brørup @ 2016-10-31 16:05 UTC (permalink / raw)
To: Olivier Matz, Bruce Richardson; +Cc: dev
In-Reply-To: <4427b23b-e9c0-4e43-9c28-fb7e56da745c@6wind.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> Sent: Tuesday, October 25, 2016 2:49 PM
>
> We should keep in mind that today we have the seqn field but it is not
> used by any PMD. In case it is implemented, would it be a per-queue
> sequence number? Is it useful from an application view?
>
> This field is only used by the librte_reorder library, and in my
> opinion, we should consider moving it in the second cache line since it
> is not filled by the PMD.
+1 because it is not filled by the NIC HW or PMD. If our argument is "better performance", I would prefer having the generic 64 bit m->userdata in cacheline0 than m->seqn.
^ permalink raw reply
* [PATCH v3] net/qede: fix advertising link speed capability
From: Rasesh Mody @ 2016-10-31 18:35 UTC (permalink / raw)
To: thomas.monjalon, bruce.richardson; +Cc: dev, Dept-EngDPDKDev
In-Reply-To: <1477721677-25668-1-git-send-email-Rasesh.Mody@cavium.com>
v3:
- check patch fixes
Fix to advertise device's link speed capability based on NVM
port configuration instead of returning driver supported speeds.
Fixes: 95e67b479506 ("net/qede: add 100G link speed capability")
Harish Patil (1):
net/qede: fix advertising link speed capability
drivers/net/qede/qede_ethdev.c | 6 ++++--
drivers/net/qede/qede_ethdev.h | 1 +
drivers/net/qede/qede_if.h | 1 +
drivers/net/qede/qede_main.c | 24 ++++++++++++++++++++++++
4 files changed, 30 insertions(+), 2 deletions(-)
--
1.7.10.3
^ permalink raw reply
* [PATCH v3] net/qede: fix advertising link speed capability
From: Rasesh Mody @ 2016-10-31 18:35 UTC (permalink / raw)
To: thomas.monjalon, bruce.richardson; +Cc: dev, Dept-EngDPDKDev
In-Reply-To: <1477938901-24999-1-git-send-email-Rasesh.Mody@cavium.com>
From: Harish Patil <harish.patil@qlogic.com>
Fix to advertise device's link speed capability based on NVM
port configuration instead of returning driver supported speeds.
Fixes: 95e67b479506 ("net/qede: add 100G link speed capability")
Signed-off-by: Harish Patil <harish.patil@qlogic.com>
---
drivers/net/qede/qede_ethdev.c | 6 ++++--
drivers/net/qede/qede_ethdev.h | 1 +
drivers/net/qede/qede_if.h | 1 +
drivers/net/qede/qede_main.c | 24 ++++++++++++++++++++++++
4 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index b91b478..59129f2 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -646,6 +646,7 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
{
struct qede_dev *qdev = eth_dev->data->dev_private;
struct ecore_dev *edev = &qdev->edev;
+ struct qed_link_output link;
PMD_INIT_FUNC_TRACE(edev);
@@ -678,8 +679,9 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
DEV_TX_OFFLOAD_UDP_CKSUM |
DEV_TX_OFFLOAD_TCP_CKSUM);
- dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G |
- ETH_LINK_SPEED_100G;
+ memset(&link, 0, sizeof(struct qed_link_output));
+ qdev->ops->common->get_link(edev, &link);
+ dev_info->speed_capa = rte_eth_speed_bitflag(link.adv_speed, 0);
}
/* return 0 means link status changed, -1 means not changed */
diff --git a/drivers/net/qede/qede_ethdev.h b/drivers/net/qede/qede_ethdev.h
index 5eb3f52..a97e3d9 100644
--- a/drivers/net/qede/qede_ethdev.h
+++ b/drivers/net/qede/qede_ethdev.h
@@ -30,6 +30,7 @@
#include "base/ecore_dev_api.h"
#include "base/ecore_iov_api.h"
#include "base/ecore_cxt.h"
+#include "base/nvm_cfg.h"
#include "qede_logs.h"
#include "qede_if.h"
diff --git a/drivers/net/qede/qede_if.h b/drivers/net/qede/qede_if.h
index 2d38b1b..4936349 100644
--- a/drivers/net/qede/qede_if.h
+++ b/drivers/net/qede/qede_if.h
@@ -70,6 +70,7 @@ struct qed_link_output {
uint32_t advertised_caps; /* In ADVERTISED defs */
uint32_t lp_caps; /* In ADVERTISED defs */
uint32_t speed; /* In Mb/s */
+ uint32_t adv_speed; /* In Mb/s */
uint8_t duplex; /* In DUPLEX defs */
uint8_t port; /* In PORT defs */
bool autoneg;
diff --git a/drivers/net/qede/qede_main.c b/drivers/net/qede/qede_main.c
index 2d354e1..d2e476c 100644
--- a/drivers/net/qede/qede_main.c
+++ b/drivers/net/qede/qede_main.c
@@ -488,6 +488,7 @@ static void qed_fill_link(struct ecore_hwfn *hwfn,
struct ecore_mcp_link_state link;
struct ecore_mcp_link_capabilities link_caps;
uint32_t media_type;
+ uint32_t adv_speed;
uint8_t change = 0;
memset(if_link, 0, sizeof(*if_link));
@@ -515,6 +516,29 @@ static void qed_fill_link(struct ecore_hwfn *hwfn,
if_link->duplex = QEDE_DUPLEX_FULL;
+ /* Fill up the native advertised speed */
+ switch (params.speed.advertised_speeds) {
+ case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G:
+ adv_speed = 10000;
+ break;
+ case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G:
+ adv_speed = 25000;
+ break;
+ case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_40G:
+ adv_speed = 40000;
+ break;
+ case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_50G:
+ adv_speed = 50000;
+ break;
+ case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_BB_100G:
+ adv_speed = 100000;
+ break;
+ default:
+ DP_NOTICE(hwfn, false, "Unknown speed\n");
+ adv_speed = 0;
+ }
+ if_link->adv_speed = adv_speed;
+
if (params.speed.autoneg)
if_link->supported_caps |= QEDE_SUPPORTED_AUTONEG;
--
1.7.10.3
^ permalink raw reply related
* Re: [RFC PATCH v2 2/3] lib: add bitrate statistics library
From: Remy Horton @ 2016-11-01 1:53 UTC (permalink / raw)
To: dev; +Cc: Morten Brørup
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC359EA8CD@smartserver.smartshare.dk>
On 28/10/2016 15:39, Morten Brørup wrote:
> Comments below.
[..]
> When working with statistical calculations using integer arithmetic,
> you should round off the integer result by adding 0.5 to the result,
> which you do by adding half of the divisor to the dividend, like
> this:
>
> delta = (delta * alpha_percent + 50) / 100;
>
> The numbers in this particular case are probably very big, so not
> rounding off doesn't affect the result a lot; but then you should add
> a comment about why rounding down is acceptable.
A minor point, but will roll it into the next patchset.
^ permalink raw reply
* [PATCH] pmd_ring: fix coverity issue
From: Mauricio Vasquez B @ 2016-11-01 3:48 UTC (permalink / raw)
To: bruce.richardson; +Cc: dev
internals->data will never be NULL, so the check is not necessary.
Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
Coverity issue: 137873
Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
---
drivers/net/ring/rte_eth_ring.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 6d2a8c1..5ca00ed 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -599,17 +599,15 @@ rte_pmd_ring_remove(const char *name)
eth_dev_stop(eth_dev);
- if (eth_dev->data) {
- internals = eth_dev->data->dev_private;
- if (internals->action == DEV_CREATE) {
- /*
- * it is only necessary to delete the rings in rx_queues because
- * they are the same used in tx_queues
- */
- for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
- r = eth_dev->data->rx_queues[i];
- rte_ring_free(r->rng);
- }
+ internals = eth_dev->data->dev_private;
+ if (internals->action == DEV_CREATE) {
+ /*
+ * it is only necessary to delete the rings in rx_queues because
+ * they are the same used in tx_queues
+ */
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
+ r = eth_dev->data->rx_queues[i];
+ rte_ring_free(r->rng);
}
rte_free(eth_dev->data->rx_queues);
--
1.9.1
^ permalink raw reply related
* [PATCH] net/mlx5: fix wrong use of vector instruction
From: Elad Persiko @ 2016-11-01 8:13 UTC (permalink / raw)
To: dev; +Cc: Elad Persiko
Constraint alignment was not respected in Tx.
Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
Signed-off-by: Elad Persiko <eladpe@mellanox.com>
---
drivers/net/mlx5/mlx5_rxtx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 21164ba..ba8e202 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -309,7 +309,7 @@ mlx5_tx_dbrec(struct txq *txq)
*txq->qp_db = htonl(txq->wqe_ci);
/* Ensure ordering between DB record and BF copy. */
rte_wmb();
- rte_mov16(dst, (uint8_t *)data);
+ memcpy(dst, (uint8_t *)data, 16);
txq->bf_offset ^= (1 << txq->bf_buf_size);
}
@@ -449,7 +449,7 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)
wqe->eseg.mss = 0;
wqe->eseg.rsvd2 = 0;
/* Start by copying the Ethernet Header. */
- rte_mov16((uint8_t *)raw, (uint8_t *)addr);
+ memcpy((uint8_t *)raw, ((uint8_t *)addr), 16);
length -= MLX5_WQE_DWORD_SIZE;
addr += MLX5_WQE_DWORD_SIZE;
/* Replace the Ethernet type by the VLAN if necessary. */
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Yuanhan Liu @ 2016-11-01 8:15 UTC (permalink / raw)
To: Maxime Coquelin; +Cc: mst@redhat.com, dev@dpdk.org, vkaplans@redhat.com
In-Reply-To: <108f3c0a-bef5-5124-fde6-01fa9870c970@redhat.com>
On Fri, Oct 28, 2016 at 09:58:51AM +0200, Maxime Coquelin wrote:
> >From my experience, and as Michael pointed out, the best mode for small packets is obviously
> >ANY_LAYOUT so it uses a single descriptor per packet.
> Of course, having a single descriptor is in theory the best way.
> But, in current Virtio PMD implementation, with no offload supported, we
> never access the virtio header at transmit time, it is allocated and
> zeroed at startup.
>
> For ANY_LAYOUT case, the virtio header is prepended to the packet, and
> need to be zeroed at packet transmit time. The performance impact is
> quite important, as show the measurements I made one month ago (txonly):
> - 2 descs per packet: 11.6Mpps
> - 1 desc per packet: 9.6Mpps
>
> As Michael suggested, I tried to replace the memset by direct
> fields assignation, but it only recovers a small part of the drop.
>
> What I suggested is to introduce a new feature, so that we can skip the
> virtio header when no offload is negotiated.
>
> Maybe you have other ideas?
>
> >So, disabling indirect descriptors may give you better pps for 64 bytes packets, but that doesn't mean you should not implement, or enable, it in your driver. That just means that the guest is not taking the right decision, and uses indirect while it should actually use any_layout.
> +1, it really depends on the use-case.
> >
> >Given virtio/vhost design (most decision comes from the guest), the host should be liberal in what it accepts, and not try to influence guest implementation by carefully picking the features it supports. Otherwise guests will never get a chance to make the right decisions either.
> Agree, what we need is to be able to disable Virtio PMD features
> without having to rebuild the PMD.
I want this feature (or more precisely, ability) long times ago.
For example, I'd wish there is an option like "force_legacy" when
both legacy and modern exist.
> It will certainly require an new API change to add this option.
I don't think it will work.
Firstly, generally, as discussed before, it's not a good idea to
introduce some PMD specific APIs.
Secondly, even if it's okay to do so, you need to let the application
(say testpmd) invoke it. Once you have done that, you need introduce
some CLI options to make sure that part is invoked.
And as stated before, it's also not a good idea to add virtio PMD
specific CLI options to testpmd.
For this case, however, I think it makes more sense if test provides
some commands to enable/disable csum and tso stuff. With that, we
could enable it dynamically.
It has "tso set/show" commands though: it just doesn't look like the
right interface to me to enable/disable tso.
--yliu
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Thomas Monjalon @ 2016-11-01 9:39 UTC (permalink / raw)
To: Yuanhan Liu, Maxime Coquelin; +Cc: dev, vkaplans, mst
In-Reply-To: <20161101081544.GP16751@yliu-dev.sh.intel.com>
2016-11-01 16:15, Yuanhan Liu:
> On Fri, Oct 28, 2016 at 09:58:51AM +0200, Maxime Coquelin wrote:
> > Agree, what we need is to be able to disable Virtio PMD features
> > without having to rebuild the PMD.
>
> I want this feature (or more precisely, ability) long times ago.
> For example, I'd wish there is an option like "force_legacy" when
> both legacy and modern exist.
You can change the behaviour of the driver with a run-time parameter
as a struct rte_devargs.
^ permalink raw reply
* [PATCH v8] app/testpmd: fix DCB configuration
From: Bernard Iremonger @ 2016-11-01 10:36 UTC (permalink / raw)
To: dev, rahul.r.shah, jingjing.wu, wenzhuo.lu
In-Reply-To: <1477665615-3723-1-git-send-email-bernard.iremonger@intel.com>
Data Centre Bridge (DCB) configuration fails when SRIOV is
enabled if nb_rxq and nb_txq are not set to 1.
The failure occurs during configuration of the ixgbe PMD when
it is started, in the ixgbe_check_mq_mode function.
Fixes: 2a977b891f99 ("app/testpmd: fix DCB configuration")
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
Changes in v8:
revise commit message.
Changes in v7:
restore nb_rxq and nb_txq setting when max_vfs is 0
app/test-pmd/testpmd.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 6185be6..96f5011 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2002,8 +2002,13 @@ init_port_dcb_config(portid_t pid,
* and has the same number of rxq and txq in dcb mode
*/
if (dcb_mode == DCB_VT_ENABLED) {
- nb_rxq = rte_port->dev_info.max_rx_queues;
- nb_txq = rte_port->dev_info.max_tx_queues;
+ if (rte_port->dev_info.max_vfs > 0) {
+ nb_rxq = 1;
+ nb_txq = 1;
+ } else {
+ nb_rxq = rte_port->dev_info.max_rx_queues;
+ nb_txq = rte_port->dev_info.max_tx_queues;
+ }
} else {
/*if vt is disabled, use all pf queues */
if (rte_port->dev_info.vmdq_pool_base == 0) {
--
2.4.3
^ permalink raw reply related
* Re: [PATCH] net/bonding: not handle vlan slow packet
From: Ferruh Yigit @ 2016-11-01 10:46 UTC (permalink / raw)
To: linhaifeng, dev, declan.doherty
In-Reply-To: <1477885947-35804-1-git-send-email-haifeng.lin@huawei.com>
Hi Haifeng,
On 10/31/2016 3:52 AM, linhaifeng wrote:
> From: Haifeng Lin <haifeng.lin@huawei.com>
>
> if rx vlan offload is enable we should not handle vlan slow
> packets too.
>
> Signed-off-by: Haifeng Lin <haifeng.lin@huawei.com>
> ---
> drivers/net/bonding/rte_eth_bond_pmd.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c
> index 09ce7bf..ca17898 100644
> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
> @@ -169,7 +169,8 @@ bond_ethdev_rx_burst_8023ad(void *queue, struct rte_mbuf **bufs,
> /* Remove packet from array if it is slow packet or slave is not
> * in collecting state or bondign interface is not in promiscus
> * mode and packet address does not match. */
> - if (unlikely(hdr->ether_type == ether_type_slow_be ||
> + if (unlikely((hdr->ether_type == ether_type_slow_be &&
> + !bufs[j]->vlan_tci) ||
> !collecting || (!promisc &&
> !is_multicast_ether_addr(&hdr->d_addr) &&
> !is_same_ether_addr(&bond_mac, &hdr->d_addr)))) {
>
There are a few version of this patch, I guess this one is the correct
one, can you please confirm?
Also this one supersede following one, right?
http://dpdk.org/dev/patchwork/patch/16840/
It helps a lot if you use versioning in the patches [PATCH -vN] and add
a description of changes in commit log (after "---") between patch versions.
Thanks,
ferruh
^ permalink raw reply
* [PATCH] app/test: fix a segfault when lpm_perf_autotest is run more than 1 time
From: Nikita Kozlov @ 2016-11-01 10:47 UTC (permalink / raw)
To: dev
num_route_entries need to be reseted.
---
app/test/test_lpm_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/app/test/test_lpm_perf.c b/app/test/test_lpm_perf.c
index 608e17a..e7e1281 100644
--- a/app/test/test_lpm_perf.c
+++ b/app/test/test_lpm_perf.c
@@ -301,6 +301,7 @@ static void generate_large_route_rule_table(void)
uint32_t ip_class;
uint8_t depth;
+ num_route_entries = 0;
memset(large_route_table, 0, sizeof(large_route_table));
for (ip_class = IP_CLASS_A; ip_class <= IP_CLASS_C; ip_class++) {
--
2.9.2
^ permalink raw reply related
* [PATCH v2] app/test: fix a segfault when lpm_perf_autotest is run more than 1 time
From: Nikita Kozlov @ 2016-11-01 11:20 UTC (permalink / raw)
To: dev
In-Reply-To: <20161101104742.12307-1-nikita@elyzion.net>
num_route_entries need to be reseted.
V2 : resubmitting the patch with a signed-off
Signed-off-by: Nikita Kozlov <nikita@elyzion.net>
---
app/test/test_lpm_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/app/test/test_lpm_perf.c b/app/test/test_lpm_perf.c
index 608e17a..e7e1281 100644
--- a/app/test/test_lpm_perf.c
+++ b/app/test/test_lpm_perf.c
@@ -301,6 +301,7 @@ static void generate_large_route_rule_table(void)
uint32_t ip_class;
uint8_t depth;
+ num_route_entries = 0;
memset(large_route_table, 0, sizeof(large_route_table));
for (ip_class = IP_CLASS_A; ip_class <= IP_CLASS_C; ip_class++) {
--
2.9.2
^ permalink raw reply related
* Re: [PATCH] app/test: fix a segfault when lpm_perf_autotest is run more than 1 time
From: Bruce Richardson @ 2016-11-01 11:20 UTC (permalink / raw)
To: Nikita Kozlov; +Cc: dev
In-Reply-To: <20161101104742.12307-1-nikita@elyzion.net>
On Tue, Nov 01, 2016 at 11:47:42AM +0100, Nikita Kozlov wrote:
> num_route_entries need to be reseted.
> ---
> app/test/test_lpm_perf.c | 1 +
> 1 file changed, 1 insertion(+)
>
You forgot your signoff on the patch, but I confirm it does indeed fix
the issue. Also, as fixes line is needed to identify the commit that
introduced the bug.
Tested-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* [PATCH v3] app/test: fix a segfault when lpm_perf_autotest is run more than 1 time
From: Nikita Kozlov @ 2016-11-01 11:55 UTC (permalink / raw)
To: dev
In-Reply-To: <20161101112000.12670-1-nikita@elyzion.net>
num_route_entries need to be reseted.
Fixes: 17d60f5b5eea ("app/test: remove large IPv4 LPM data file")
Signed-off-by: Nikita Kozlov <nikita@elyzion.net>
---
app/test/test_lpm_perf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/app/test/test_lpm_perf.c b/app/test/test_lpm_perf.c
index 608e17a..e7e1281 100644
--- a/app/test/test_lpm_perf.c
+++ b/app/test/test_lpm_perf.c
@@ -301,6 +301,7 @@ static void generate_large_route_rule_table(void)
uint32_t ip_class;
uint8_t depth;
+ num_route_entries = 0;
memset(large_route_table, 0, sizeof(large_route_table));
for (ip_class = IP_CLASS_A; ip_class <= IP_CLASS_C; ip_class++) {
--
2.9.2
^ permalink raw reply related
* Re: [PATCH] net/bonding: not handle vlan slow packet
From: linhaifeng @ 2016-11-01 12:32 UTC (permalink / raw)
To: Ferruh Yigit, dev, declan.doherty
In-Reply-To: <227a3391-019d-3a4c-e76f-d1775466261b@intel.com>
在 2016/11/1 18:46, Ferruh Yigit 写道:
> Hi Haifeng,
>
> On 10/31/2016 3:52 AM, linhaifeng wrote:
>> From: Haifeng Lin <haifeng.lin@huawei.com>
>>
>> if rx vlan offload is enable we should not handle vlan slow
>> packets too.
>>
>> Signed-off-by: Haifeng Lin <haifeng.lin@huawei.com>
>> ---
>> drivers/net/bonding/rte_eth_bond_pmd.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c
>> index 09ce7bf..ca17898 100644
>> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
>> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
>> @@ -169,7 +169,8 @@ bond_ethdev_rx_burst_8023ad(void *queue, struct rte_mbuf **bufs,
>> /* Remove packet from array if it is slow packet or slave is not
>> * in collecting state or bondign interface is not in promiscus
>> * mode and packet address does not match. */
>> - if (unlikely(hdr->ether_type == ether_type_slow_be ||
>> + if (unlikely((hdr->ether_type == ether_type_slow_be &&
>> + !bufs[j]->vlan_tci) ||
>> !collecting || (!promisc &&
>> !is_multicast_ether_addr(&hdr->d_addr) &&
>> !is_same_ether_addr(&bond_mac, &hdr->d_addr)))) {
>>
>
> There are a few version of this patch, I guess this one is the correct
> one, can you please confirm?
> Also this one supersede following one, right?
> http://dpdk.org/dev/patchwork/patch/16840/
yes，this is
>
> It helps a lot if you use versioning in the patches [PATCH -vN] and add
> a description of changes in commit log (after "---") between patch versions.
>
ok，i think should not send patch so worry：）
I have a question to ask：
Is there any other packets' type also is 0x8809 except with lacp packets?
I saw some guests try to use this type to check link status between VM
but droped by lacp bond recv function.
> Thanks,
> ferruh
>
> .
>
^ permalink raw reply
* Re: [PATCH v11 1/6] ethdev: add Tx preparation
From: Ananyev, Konstantin @ 2016-11-01 12:57 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev@dpdk.org
In-Reply-To: <2177010.quNaxrZShx@xps13>
Hi Thomas,
> > > I suggest to integrate it in the beginning of 17.02 cycle, with the hope
> > > that you can convince other developers to implement it in other drivers,
> > > so we could finally enable it in the default config.
> >
> > Ok, any insights then, how we can convince people to do that?
>
> You just have to explain clearly what this new feature is bringing
> and what will be the future possibilities.
>
> > BTW, it means then that tx_prep() should become part of mandatory API
> > to be implemented by each PMD doing TX offloads, right?
>
> Right.
> The question is "what means mandatory"?
For me "mandatory" here would mean that:
- if the PMD supports TX offloads AND
- if to be able use any of these offloads the upper layer SW would have to:
- modify the contents of the packet OR
- obey HW specific restrictions
then it is a PMD developer responsibility to provide tx_prep() that would implement
expected modifications of the packet contents and restriction checks.
Otherwise, tx_prep() implementation is not required and can be safely set to NULL.
Does it sounds good enough to everyone?
> Should we block some patches for non-compliant drivers?
If we agree that it should be a 'mandatory' one - and patch in question breaks
that requirement, then probably yes.
> Should we remove offloads capability from non-compliant drivers?
Do you mean existing PMDs?
Are there any particular right now, that can't work properly with testpmd csumonly mode?
Konstantin
^ permalink raw reply
* Re: [PATCH] pmd_ring: fix coverity issue
From: Ferruh Yigit @ 2016-11-01 14:17 UTC (permalink / raw)
To: Mauricio Vasquez B, bruce.richardson; +Cc: dev
In-Reply-To: <1477972113-2600-1-git-send-email-mauricio.vasquez@polito.it>
Hi Mauricio,
On 11/1/2016 3:48 AM, Mauricio Vasquez B wrote:
> internals->data will never be NULL, so the check is not necessary.
>
> Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
> Coverity issue: 137873
>
> Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
> ---
Thank you for the patch.
But "fix coverity issue" is not very descriptive title on its own.
Can you please describe what is really done in the patch, perhaps
something like:
"net/ring: remove unnecessary NULL check" ?
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix wrong use of vector instruction
From: Ferruh Yigit @ 2016-11-01 14:24 UTC (permalink / raw)
To: Elad Persiko, dev
In-Reply-To: <1477988007-26141-1-git-send-email-eladpe@mellanox.com>
On 11/1/2016 8:13 AM, Elad Persiko wrote:
> Constraint alignment was not respected in Tx.
>
> Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
>
> Signed-off-by: Elad Persiko <eladpe@mellanox.com>
> ---
> drivers/net/mlx5/mlx5_rxtx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
> index 21164ba..ba8e202 100644
> --- a/drivers/net/mlx5/mlx5_rxtx.c
> +++ b/drivers/net/mlx5/mlx5_rxtx.c
> @@ -309,7 +309,7 @@ mlx5_tx_dbrec(struct txq *txq)
> *txq->qp_db = htonl(txq->wqe_ci);
> /* Ensure ordering between DB record and BF copy. */
> rte_wmb();
> - rte_mov16(dst, (uint8_t *)data);
> + memcpy(dst, (uint8_t *)data, 16);
> txq->bf_offset ^= (1 << txq->bf_buf_size);
> }
>
> @@ -449,7 +449,7 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)
> wqe->eseg.mss = 0;
> wqe->eseg.rsvd2 = 0;
> /* Start by copying the Ethernet Header. */
> - rte_mov16((uint8_t *)raw, (uint8_t *)addr);
> + memcpy((uint8_t *)raw, ((uint8_t *)addr), 16);
> length -= MLX5_WQE_DWORD_SIZE;
> addr += MLX5_WQE_DWORD_SIZE;
> /* Replace the Ethernet type by the VLAN if necessary. */
>
CC: Maintainers (Adrien Mazarguil <adrien.mazarguil@6wind.com>)
^ permalink raw reply
* [PATCH] doc: add missing library to release notes
From: Ferruh Yigit @ 2016-11-01 17:03 UTC (permalink / raw)
To: dev
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
CC: Olivier Matz <olivier.matz@6wind.com>
---
doc/guides/rel_notes/release_16_11.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
index aa0c09a..5f185be 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -248,6 +248,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_mbuf.so.2
librte_mempool.so.2
librte_meter.so.1
+ librte_net.so.1
librte_pdump.so.1
librte_pipeline.so.3
librte_pmd_bond.so.1
--
2.7.4
^ permalink raw reply related
* [PATCH] net: remove mempool as a dependency
From: Ferruh Yigit @ 2016-11-01 17:03 UTC (permalink / raw)
To: dev
In-Reply-To: <20161101170331.27813-1-ferruh.yigit@intel.com>
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
lib/librte_net/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/librte_net/Makefile b/lib/librte_net/Makefile
index e5758ce..20cf664 100644
--- a/lib/librte_net/Makefile
+++ b/lib/librte_net/Makefile
@@ -45,7 +45,6 @@ SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include := rte_ip.h rte_tcp.h rte_udp.h
SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_sctp.h rte_icmp.h rte_arp.h
SYMLINK-$(CONFIG_RTE_LIBRTE_NET)-include += rte_ether.h rte_gre.h rte_net.h
-DEPDIRS-$(CONFIG_RTE_LIBRTE_NET) += lib/librte_eal lib/librte_mempool
-DEPDIRS-$(CONFIG_RTE_LIBRTE_NET) += lib/librte_mbuf
+DEPDIRS-$(CONFIG_RTE_LIBRTE_NET) += lib/librte_eal lib/librte_mbuf
include $(RTE_SDK)/mk/rte.lib.mk
--
2.7.4
^ permalink raw reply related
* [PATCH] net/enic: fix max packet length check
From: John Daley @ 2016-11-01 18:08 UTC (permalink / raw)
To: bruce.richardson; +Cc: dev
When the device was configured with an explicit maximum packet length,
it would fail if the value was greater than MTU configured in CIMC/UCSM
(plus L2 header length). It should have been compared against maximum
allowed by the device.
Fixes: bb34ffb848a0 ("net/enic: determine max egress packet size and max MTU")
Signed-off-by: John Daley <johndale@cisco.com>
---
drivers/net/enic/enic_ethdev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index bcf83d4..2b154ec 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -463,8 +463,7 @@ static void enicpmd_dev_info_get(struct rte_eth_dev *eth_dev,
device_info->max_rx_queues = enic->conf_rq_count / 2;
device_info->max_tx_queues = enic->conf_wq_count;
device_info->min_rx_bufsize = ENIC_MIN_MTU;
- device_info->max_rx_pktlen = enic->rte_dev->data->mtu
- + ETHER_HDR_LEN + 4;
+ device_info->max_rx_pktlen = enic->max_mtu + ETHER_HDR_LEN + 4;
device_info->max_mac_addrs = 1;
device_info->rx_offload_capa =
DEV_RX_OFFLOAD_VLAN_STRIP |
--
2.10.0
^ permalink raw reply related
* [PATCH v2] net/ring: remove unnecessary NULL check
From: Mauricio Vasquez B @ 2016-11-01 19:55 UTC (permalink / raw)
To: bruce.richardson; +Cc: dev, ferruh.yigit
In-Reply-To: <1477972113-2600-1-git-send-email-mauricio.vasquez@polito.it>
Coverity detected this as an issue because internals->data will never be NULL,
then the check is not necessary.
Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
Coverity issue: 137873
Signed-off-by: Mauricio Vasquez B <mauricio.vasquez@polito.it>
---
drivers/net/ring/rte_eth_ring.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 6d2a8c1..5ca00ed 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -599,17 +599,15 @@ rte_pmd_ring_remove(const char *name)
eth_dev_stop(eth_dev);
- if (eth_dev->data) {
- internals = eth_dev->data->dev_private;
- if (internals->action == DEV_CREATE) {
- /*
- * it is only necessary to delete the rings in rx_queues because
- * they are the same used in tx_queues
- */
- for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
- r = eth_dev->data->rx_queues[i];
- rte_ring_free(r->rng);
- }
+ internals = eth_dev->data->dev_private;
+ if (internals->action == DEV_CREATE) {
+ /*
+ * it is only necessary to delete the rings in rx_queues because
+ * they are the same used in tx_queues
+ */
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
+ r = eth_dev->data->rx_queues[i];
+ rte_ring_free(r->rng);
}
rte_free(eth_dev->data->rx_queues);
--
1.9.1
^ permalink raw reply related
* [PATCH] E1000: fix for forced speed/duplex config
From: Ananda Sathyanarayana @ 2016-11-01 22:47 UTC (permalink / raw)
To: wenzhuo.lu; +Cc: dev
>From the code, it looks like, hw->mac.autoneg, variable is used to
switch between calling either autoneg function or forcing
speed/duplex function. But this variable is not modified in
eth_em_start/eth_igb_start routines (it is always set to 1)
even while forcing the link speed.
Following discussion thread has some more information on
this
http://dpdk.org/ml/archives/dev/2016-October/049272.html
Signed-off-by: Ananda Sathyanarayana <ananda@versa-networks.com>
---
drivers/net/e1000/em_ethdev.c | 16 ++++++++++++++--
drivers/net/e1000/igb_ethdev.c | 16 ++++++++++++++--
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 7cf5f0c..a2412f5 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -639,6 +639,7 @@ eth_em_start(struct rte_eth_dev *dev)
speeds = &dev->data->dev_conf.link_speeds;
if (*speeds == ETH_LINK_SPEED_AUTONEG) {
hw->phy.autoneg_advertised = E1000_ALL_SPEED_DUPLEX;
+ hw->mac.autoneg = 1;
} else {
num_speeds = 0;
autoneg = (*speeds & ETH_LINK_SPEED_FIXED) == 0;
@@ -672,9 +673,20 @@ eth_em_start(struct rte_eth_dev *dev)
hw->phy.autoneg_advertised |= ADVERTISE_1000_FULL;
num_speeds++;
}
- if (num_speeds == 0 || (!autoneg && (num_speeds > 1)))
+ if (num_speeds == 0 || (!autoneg && (num_speeds > 1))) {
goto error_invalid_config;
- }
+ }
+ /*
+ * Set/reset the mac.autoneg based on the link speed,
+ * fixed or not
+ */
+ if (!autoneg) {
+ hw->mac.autoneg = 0;
+ hw->mac.forced_speed_duplex = hw->phy.autoneg_advertised;
+ } else {
+ hw->mac.autoneg = 1;
+ }
+ }
e1000_setup_link(hw);
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 4924396..9fb498f 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1327,6 +1327,7 @@ eth_igb_start(struct rte_eth_dev *dev)
speeds = &dev->data->dev_conf.link_speeds;
if (*speeds == ETH_LINK_SPEED_AUTONEG) {
hw->phy.autoneg_advertised = E1000_ALL_SPEED_DUPLEX;
+ hw->mac.autoneg = 1;
} else {
num_speeds = 0;
autoneg = (*speeds & ETH_LINK_SPEED_FIXED) == 0;
@@ -1360,9 +1361,20 @@ eth_igb_start(struct rte_eth_dev *dev)
hw->phy.autoneg_advertised |= ADVERTISE_1000_FULL;
num_speeds++;
}
- if (num_speeds == 0 || (!autoneg && (num_speeds > 1)))
+ if (num_speeds == 0 || (!autoneg && (num_speeds > 1))) {
goto error_invalid_config;
- }
+ }
+ /*
+ * Set/reset the mac.autoneg based on the link speed,
+ * fixed or not
+ */
+ if (!autoneg) {
+ hw->mac.autoneg = 0;
+ hw->mac.forced_speed_duplex = hw->phy.autoneg_advertised;
+ } else {
+ hw->mac.autoneg = 1;
+ }
+ }
e1000_setup_link(hw);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] E1000: fix for forced speed/duplex config
From: Lu, Wenzhuo @ 2016-11-02 0:37 UTC (permalink / raw)
To: Ananda Sathyanarayana; +Cc: dev@dpdk.org
In-Reply-To: <1478040424-102624-1-git-send-email-ananda@versa-networks.com>
Hi Ananda,
> -----Original Message-----
> From: Ananda Sathyanarayana [mailto:ananda@versa-networks.com]
> Sent: Wednesday, November 2, 2016 6:47 AM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org; Ananda Sathyanarayana
> Subject: [PATCH] E1000: fix for forced speed/duplex config
>
> From the code, it looks like, hw->mac.autoneg, variable is used to switch
> between calling either autoneg function or forcing speed/duplex function. But
> this variable is not modified in eth_em_start/eth_igb_start routines (it is always
> set to 1) even while forcing the link speed.
>
> Following discussion thread has some more information on this
>
> http://dpdk.org/ml/archives/dev/2016-October/049272.html
>
> Signed-off-by: Ananda Sathyanarayana <ananda@versa-networks.com>
Thanks for the patch. It looks fine to me. But as it's a fix, would you like to add a Fixes tag for it?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox