[dpdk-dev] [PATCH] net/bonding: not handle vlan slow packet
From: ZengGanghui if rx vlan offload is enable we should not handle vlan slow packets too. Signed-off-by: Haifeng Lin --- drivers/net/bonding/rte_eth_bond_pmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c index 43334f7..6c74bba 100644 --- a/drivers/net/bonding/rte_eth_bond_pmd.c +++ b/drivers/net/bonding/rte_eth_bond_pmd.c @@ -169,7 +169,7 @@ 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))) && -- 1.8.3.1
[dpdk-dev] net/bonding: not handle vlan slow packet
if rx vlan offload is enable we should not handle vlan slow packets too. Signed-off-by: Haifeng Lin diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c index 43334f7..6c74bba 100644 --- a/drivers/net/bonding/rte_eth_bond_pmd.c +++ b/drivers/net/bonding/rte_eth_bond_pmd.c @@ -169,7 +169,7 @@ 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))) &&
[dpdk-dev] [PATCH] net/bonding: not handle vlan slow packet
From: Haifeng Lin
if rx vlan offload is enable we should not handle vlan slow
packets too.
Signed-off-by: Haifeng Lin
---
drivers/net/bonding/rte_eth_bond_pmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 09ce7bf..9e99442 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -169,7 +169,7 @@ 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 {
--
1.8.3.1
[dpdk-dev] [PATCH] net/bonding: not handle vlan slow packet
From: Haifeng Lin
if rx vlan offload is enable we should not handle vlan slow
packets too.
Signed-off-by: Haifeng Lin
---
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 {
--
1.8.3.1
[dpdk-dev] [RFC v2] Generic flow director/filtering/classification API
Hi Adrien Just a double check, do you have any update on the v1 patch set, as now it is the end of October? We are extremly eager to see the v1 patch set for development. I don't think we need full validation on the v1 patch set for API. It should be together with PMD and example application. If we can see the v1 API patch set earlier, we can help to validate it with our code changes. That's should be more efficient and helpful. Any comments on my personal understanding? Thank you very much for the hard work and kind helps! Regards, Helin > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Adrien Mazarguil > Sent: Friday, September 30, 2016 1:11 AM > To: dev at dpdk.org > Cc: Thomas Monjalon > Subject: Re: [dpdk-dev] [RFC v2] Generic flow > director/filtering/classification > API > > On Fri, Aug 19, 2016 at 08:50:44PM +0200, Adrien Mazarguil wrote: > > Hi All, > > > > Thanks to many for the positive and constructive feedback I've > > received so far. Here is the updated specification (v0.7) at last. > > > > I've attempted to address as many comments as possible but could not > > process them all just yet. A new section "Future evolutions" has been > > added for the remaining topics. > > > > This series adds rte_flow.h to the DPDK tree. Next time I will attempt > > to convert the specification as a documentation commit part of the > > patchset and actually implement API functions. > [...] > > A quick update, we initially targeted 16.11 as the DPDK release this API would > be available for, turns out this goal was somewhat too optimistic as > September is ending and we are about to overshoot the deadline for > integration (basically everything took longer than expected, big surprise). > > So instead of rushing things now to include a botched API in 16.11 with no > PMD support, we simply modified the target, now set to 17.02. On the plus > side this should leave developers more time to refine and test the API before > applications and PMDs start to use it. > > I intend to send the patchset for the first non-draft version mid-October > worst case (ASAP in fact). I still haven't replied to several comments but did > take them into account, thanks for your feedback. > > -- > Adrien Mazarguil > 6WIND
[dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support to the TX path
> -Original Message- > From: Maxime Coquelin [mailto:maxime.coquelin at redhat.com] > Sent: Friday, October 28, 2016 3:42 PM > To: Wang, Zhihong ; Yuanhan Liu > > Cc: stephen at networkplumber.org; Pierre Pfister (ppfister) > ; Xie, Huawei ; dev at > dpdk.org; > vkaplans at redhat.com; mst at redhat.com > Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support > to the TX path > > > > On 10/28/2016 02:49 AM, Wang, Zhihong wrote: > > > >> > -Original Message- > >> > From: Yuanhan Liu [mailto:yuanhan.liu at linux.intel.com] > >> > Sent: Thursday, October 27, 2016 6:46 PM > >> > To: Maxime Coquelin > >> > Cc: Wang, Zhihong ; > >> > stephen at networkplumber.org; Pierre Pfister (ppfister) > >> > ; Xie, Huawei ; > dev at dpdk.org; > >> > vkaplans at redhat.com; mst at redhat.com > >> > Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors > support > >> > to the TX path > >> > > >> > On Thu, Oct 27, 2016 at 12:35:11PM +0200, Maxime Coquelin wrote: > >>> > > > >>> > > > >>> > > On 10/27/2016 12:33 PM, Yuanhan Liu wrote: > > > >On Thu, Oct 27, 2016 at 11:10:34AM +0200, Maxime Coquelin > wrote: > > > > >>Hi Zhihong, > > > > >> > > > > >>On 10/27/2016 11:00 AM, Wang, Zhihong wrote: > >> > > >>>Hi Maxime, > >> > > >>> > >> > > >>>Seems indirect desc feature is causing serious performance > >> > > >>>degradation on Haswell platform, about 20% drop for both > >> > > >>>mrg=on and mrg=off (--txqflags=0xf00, non-vector version), > >> > > >>>both iofwd and macfwd. > > > > >>I tested PVP (with macswap on guest) and Txonly/Rxonly on an > Ivy > >> > Bridge > > > > >>platform, and didn't faced such a drop. > > > > > > > >I was actually wondering that may be the cause. I tested it with > > > >my IvyBridge server as well, I saw no drop. > > > > > > > >Maybe you should find a similar platform (Haswell) and have a try? > >>> > > Yes, that's why I asked Zhihong whether he could test Txonly in guest > to > >>> > > see if issue is reproducible like this. > >> > > >> > I have no Haswell box, otherwise I could do a quick test for you. IIRC, > >> > he tried to disable the indirect_desc feature, then the performance > >> > recovered. So, it's likely the indirect_desc is the culprit here. > >> > > >>> > > I will be easier for me to find an Haswell machine if it has not to be > >>> > > connected back to back to and HW/SW packet generator. > > In fact simple loopback test will also do, without pktgen. > > > > Start testpmd in both host and guest, and do "start" in one > > and "start tx_first 32" in another. > > > > Perf drop is about 24% in my test. > > > > Thanks, I never tried this test. > I managed to find an Haswell platform (Intel(R) Xeon(R) CPU E5-2699 v3 > @ 2.30GHz), and can reproduce the problem with the loop test you > mention. I see a performance drop about 10% (8.94Mpps/8.08Mpps). > Out of curiosity, what are the numbers you get with your setup? Hi Maxime, Let's align our test case to RC2, mrg=on, loopback, on Haswell. My results below: 1. indirect=1: 5.26 Mpps 2. indirect=0: 6.54 Mpps It's about 24% drop. > > As I never tried this test, I run it again on my Sandy Bridge setup, and > I also see a performance regression, this time of 4%. > > If I understand correctly the test, only 32 packets are allocated, > corresponding to a single burst, which is less than the queue size. > So it makes sense that the performance is lower with this test case. Actually it's 32 burst, so 1024 packets in total, enough to fill the queue. Thanks Zhihong > > Thanks, > Maxime
[dpdk-dev] Red Hat 6.5 compilation failure
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". Do we still want to support it, or should we update the documentation to remove it? Regards, -- N?lio Laranjeiro 6WIND
[dpdk-dev] mbuf changes
About the mbuf timestamp (regardless of size etc.) accuracy: We should also consider the clock source. If the NIC HW is the clock source, there will be a fixed offset from the CPU's clock, but there will also be varying drift (they have separate XTALs). And if there are multiple NICs, there will be offset and varying drift between their clocks too. If I remember correctly, the IEEE Ethernet specifications require a clock accuracy of 100 ppm. So XTALs of this quality are probably being used in the hardware. This means that the clock drift between two NICs (or a NIC and the actual time) can be in the magnitude of 100.000 ns per second. BTW: If you are interested in NTP, you should take a look at Poul-Henning Kamp's ntimed research: http://phk.freebsd.dk/time/index.html Med venlig hilsen / kind regards - Morten Br?rup
[dpdk-dev] Red Hat 6.5 compilation failure
2016-10-31 11:43, N?lio Laranjeiro: > Hi all, > > Am facing an issue with compilation on redhat 6.5 of DPDK v16.11-rc2, Thanks Nelio for raising the issue. > compilation fails with: [...] > In doc/guides/rel_notes/supported_os.rst we still support > "Red Hat Enterprise Linux 6.5". > > Do we still want to support it, or should we update the documentation to > remove it? I vote for dropping RHEL6 support in DPDK 16.11. Any other comment in the community? Please give your voice, whether you agree or disagree.
[dpdk-dev] Red Hat 6.5 compilation failure
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 >
[dpdk-dev] mbuf changes
> -Original Message- > From: dev [mailto:dev-bounces at 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.
[dpdk-dev] [PATCH v3] net/qede: fix advertising link speed capability
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
[dpdk-dev] [PATCH v3] net/qede: fix advertising link speed capability
From: Harish Patil
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
---
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 = 1;
+ 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 = 4;
+ break;
+ case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_50G:
+ adv_speed = 5;
+ break;
+ case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_BB_100G:
+ adv_speed = 10;
+ 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
[dpdk-dev] [PATCH] pmd_ring: fix coverity issue
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
---
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
