Re: [dpdk-dev] [PATCH 1/2] mk: add Marvell ARMADA architecture based on armv8-a
Hi, > -Original Message- > From: dev On Behalf Of lir...@marvell.com > Sent: Saturday, May 18, 2019 05:34 > To: tho...@monjalon.net > Cc: dev@dpdk.org; Liron Himi > Subject: [dpdk-dev] [PATCH 1/2] mk: add Marvell ARMADA architecture > based on armv8-a > > From: Liron Himi > > This patch introduces armada target to address difference in number of cores, > no numa support > > Signed-off-by: Liron Himi > Reviewed-by: Alan Winkowski > Tested-by: Liron Himi > --- > config/defconfig_arm64-armada-linux-gcc| 24 > > config/defconfig_arm64-armada-linuxapp-gcc | 24 > > 2 files changed, 48 insertions(+) > create mode 100644 config/defconfig_arm64-armada-linux-gcc > create mode 100644 config/defconfig_arm64-armada-linuxapp-gcc > > diff --git a/config/defconfig_arm64-armada-linux-gcc > b/config/defconfig_arm64-armada-linux-gcc > new file mode 100644 > index 000..573b278 > --- /dev/null > +++ b/config/defconfig_arm64-armada-linux-gcc > @@ -0,0 +1,24 @@ > +# SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2018 Marvell > +International Ltd # > + > +#include "defconfig_arm64-armv8a-linux-gcc" > + > +CONFIG_RTE_LIBRTE_MVEP_COMMON=y > +CONFIG_RTE_LIBRTE_MVPP2_PMD=y > +CONFIG_RTE_LIBRTE_MVNETA_PMD=y > +CONFIG_RTE_LIBRTE_PMD_MVSAM_CRYPTO=y > + > +# > +# Compile Environment Abstraction Layer # > +CONFIG_RTE_MAX_LCORE=16 > +CONFIG_RTE_MAX_NUMA_NODES=1 > +CONFIG_RTE_CACHE_LINE_SIZE=64 > + > +# Disable NXP as it is conflict with MUSDK > CONFIG_RTE_LIBRTE_DPAA_BUS=n > + > +# Doesn't support NUMA > +CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n > +CONFIG_RTE_LIBRTE_VHOST_NUMA=n > diff --git a/config/defconfig_arm64-armada-linuxapp-gcc > b/config/defconfig_arm64-armada-linuxapp-gcc > new file mode 100644 > index 000..573b278 > --- /dev/null > +++ b/config/defconfig_arm64-armada-linuxapp-gcc > @@ -0,0 +1,24 @@ > +# SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2018 Marvell > +International Ltd # > + > +#include "defconfig_arm64-armv8a-linux-gcc" > + Maybe CONFIG_RTE_MACHINE and CONFIG_RTE_ARCH_ARM_TUNE can be added as well. I referred to defconfig_arm64-dpaa2-linuxapp-gcc. > +CONFIG_RTE_LIBRTE_MVEP_COMMON=y > +CONFIG_RTE_LIBRTE_MVPP2_PMD=y > +CONFIG_RTE_LIBRTE_MVNETA_PMD=y > +CONFIG_RTE_LIBRTE_PMD_MVSAM_CRYPTO=y > + > +# > +# Compile Environment Abstraction Layer # > +CONFIG_RTE_MAX_LCORE=16 > +CONFIG_RTE_MAX_NUMA_NODES=1 > +CONFIG_RTE_CACHE_LINE_SIZE=64 > + > +# Disable NXP as it is conflict with MUSDK > CONFIG_RTE_LIBRTE_DPAA_BUS=n > + > +# Doesn't support NUMA > +CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n > +CONFIG_RTE_LIBRTE_VHOST_NUMA=n > -- > 2.7.4
[dpdk-dev] [PATCH] net/ixgbe/base: wait for link after copper MAC setup
After setting up the link on x552/X557-AT 10GBASE-T NICs, sometimes the
link does not get set up properly and as a result all the subsequent
calls to ixgbe_check_link() from ixgbe_dev_link_update_share() fail.
Introduce a delay time of 1s in ixgbe_setup_mac_link_t_X550em() before
beginning to set up the external PHY link speed to ensure that the
controller can acquire the link.
Signed-off-by: Ashijeet Acharya
---
Hello,
This patch makes changes in the base driver.
Similar patch was introduced in case of fiber link MAC setup earlier
http://patchwork.dpdk.org/patch/43119/
Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=69
drivers/net/ixgbe/base/ixgbe_x550.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c
b/drivers/net/ixgbe/base/ixgbe_x550.c
index a920a146e..930a61a20 100644
--- a/drivers/net/ixgbe/base/ixgbe_x550.c
+++ b/drivers/net/ixgbe/base/ixgbe_x550.c
@@ -4440,6 +4440,8 @@ s32 ixgbe_setup_mac_link_t_X550em(struct ixgbe_hw *hw,
{
s32 status;
ixgbe_link_speed force_speed;
+ u32 i;
+ bool link_up = false;
DEBUGFUNC("ixgbe_setup_mac_link_t_X550em");
@@ -4459,6 +4461,19 @@ s32 ixgbe_setup_mac_link_t_X550em(struct ixgbe_hw *hw,
if (status != IXGBE_SUCCESS)
return status;
+
+ /* Wait for the controller to acquire link */
+ for (i = 0; i < 10; i++) {
+ msec_delay(100);
+
+ status = ixgbe_check_link(hw, &force_speed, &link_up,
+ false);
+ if (status != IXGBE_SUCCESS)
+ return status;
+
+ if (link_up)
+ break;
+ }
}
return hw->phy.ops.setup_link_speed(hw, speed,
autoneg_wait_to_complete);
--
2.11.0
[dpdk-dev] [PATCH v2] examples/l3fwd-power: add telemetry mode support
Add new telemetry mode support for l3fwd-power.
This is a standalone mode, in this mode l3fwd-power
does simple l3fwding along with calculating
empty polls, full polls, and busy percentage for
each forwarding core. The aggregation of these
values of all cores is reported as application
level telemetry to metric library for every 10ms from the
master core.
The busy percentage is calculated by recording the poll_count
and when the count reaches a defined value the total
cycles it took is measured and compared with minimum and maximum
reference cycles and busy rate is set according to either 0% or
50% or 100%.
Signed-off-by: Reshma Pattan
---
v2: Increased telemetry timer value.
Corrected typos.
Fixed if condition to avoid extra indentation.
Added metrics dependency to meson build file.
---
---
doc/guides/rel_notes/release_19_08.rst| 5 +
.../sample_app_ug/l3_forward_power_man.rst| 21 ++
examples/l3fwd-power/main.c | 310 --
examples/l3fwd-power/meson.build | 2 +-
4 files changed, 318 insertions(+), 20 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_08.rst
b/doc/guides/rel_notes/release_19_08.rst
index b9510f93a..e318e400a 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -54,6 +54,11 @@ New Features
Also, make sure to start the actual text at the margin.
=
+* **Added new telemetry mode for l3fwd-power application.**
+
+ Added telemetry mode to l3fwd-power application to report
+ application level busyness, empty and full polls of rte_eth_rx_burst().
+
Removed Items
-
diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst
b/doc/guides/sample_app_ug/l3_forward_power_man.rst
index e44a11b2c..7b0fc8d2b 100644
--- a/doc/guides/sample_app_ug/l3_forward_power_man.rst
+++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst
@@ -107,6 +107,8 @@ where,
* --empty-poll: Traffic Aware power management. See below for details
+* --telemetry: Telemetry mode.
+
See :doc:`l3_forward` for details.
The L3fwd-power example reuses the L3fwd command line options.
@@ -431,3 +433,22 @@ then be started without the training mode so traffic can
start immediately.
.. code-block:: console
./examples/l3fwd-power/build/l3fwd-power -l 1-3 -- -p 0x0f
--config="(0,0,2),(0,1,3)" --empty-poll "0,34,54" –P
+
+Telemetry Mode
+--
+
+The telemetry mode support for ``l3fwd-power`` is a standalone mode, in this
mode
+``l3fwd-power`` does simple l3fwding along with calculating empty polls, full
polls,
+and busy percentage for each forwarding core. The aggregation of these
+values of all cores is reported as application level telemetry to metric
+library for every 10ms from the master core.
+
+The busy percentage is calculated by recording the poll_count
+and when the count reaches a defined value the total
+cycles it took is measured and compared with minimum and maximum
+reference cycles and accordingly busy rate is set to either 0% or
+50% or 100%.
+
+.. code-block:: console
+
+./examples/l3fwd-power/build/l3fwd-power -l 1-3 -- -p 0x0f
--config="(0,0,2),(0,1,3)" --telemetry
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index 3b448acc4..50e06c209 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -44,6 +45,7 @@
#include
#include
#include
+#include
#include "perf_core.h"
#include "main.h"
@@ -146,17 +148,59 @@ static uint32_t enabled_port_mask = 0;
static int promiscuous_on = 0;
/* NUMA is enabled by default. */
static int numa_on = 1;
-/* emptypoll is disabled by default. */
-static bool empty_poll_on;
+static bool empty_poll_stop;
static bool empty_poll_train;
-volatile bool empty_poll_stop;
+volatile bool quit_signal;
static struct ep_params *ep_params;
static struct ep_policy policy;
static long ep_med_edpi, ep_hgh_edpi;
+/* timer to update telemetry every 500ms */
+static struct rte_timer telemetry_timer;
+
+/* stats index returned by metrics lib */
+int telstats_index;
+
+struct telstats_name {
+ char name[RTE_ETH_XSTATS_NAME_SIZE];
+};
+
+/* telemetry stats to be reported */
+const struct telstats_name telstats_strings[] = {
+ {"empty_poll"},
+ {"full_poll"},
+ {"busy_percent"}
+};
+
+/* core busyness in percentage */
+enum busy_rate {
+ ZERO = 0,
+ PARTIAL = 50,
+ FULL = 100
+};
+
+/* reference poll count to measure core busyness */
+#define DEFAULT_COUNT 1
+/*
+ * reference CYCLES to be used to
+ * measure core busyness based on poll count
+ */
+#define MIN_CYCLES 150ULL
+#define MAX_CYCLES 250ULL
+
+/* (500ms) */
+#define TELEMETRY_INTERVALS_PER_SEC 2
static int parse_ptype; /**< Parse packet type using rx callback, and */
Re: [dpdk-dev] [PATCH v2] examples/l3fwd-power: add telemetry mode support
On 24-May-19 10:34 AM, Reshma Pattan wrote: Add new telemetry mode support for l3fwd-power. This is a standalone mode, in this mode l3fwd-power does simple l3fwding along with calculating empty polls, full polls, and busy percentage for each forwarding core. The aggregation of these values of all cores is reported as application level telemetry to metric library for every 10ms from the master core. The busy percentage is calculated by recording the poll_count and when the count reaches a defined value the total cycles it took is measured and compared with minimum and maximum reference cycles and busy rate is set according to either 0% or 50% or 100%. Signed-off-by: Reshma Pattan --- LGTM Acked-by: Anatoly Burakov -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH 05/15] net: add rte prefix to ether defines
On 5/21/2019 5:13 PM, Olivier Matz wrote: > Add 'RTE_' prefix to defines: > - rename ETHER_ADDR_LEN as RTE_ETHER_ADDR_LEN. > - rename ETHER_TYPE_LEN as RTE_ETHER_TYPE_LEN. > - rename ETHER_CRC_LEN as RTE_ETHER_CRC_LEN. > - rename ETHER_HDR_LEN as RTE_ETHER_HDR_LEN. > - rename ETHER_MIN_LEN as RTE_ETHER_MIN_LEN. > - rename ETHER_MAX_LEN as RTE_ETHER_MAX_LEN. > - rename ETHER_MTU as RTE_ETHER_MTU. net/ice has RTE_ETHER_MTU in next-net, I am fixing it. > - rename ETHER_MAX_VLAN_FRAME_LEN as RTE_ETHER_MAX_VLAN_FRAME_LEN. > - rename ETHER_MAX_VLAN_ID as RTE_ETHER_MAX_VLAN_ID. > - rename ETHER_MAX_JUMBO_FRAME_LEN as RTE_ETHER_MAX_JUMBO_FRAME_LEN. > - rename ETHER_MIN_MTU as RTE_ETHER_MIN_MTU. > - rename ETHER_LOCAL_ADMIN_ADDR as RTE_ETHER_LOCAL_ADMIN_ADDR. > - rename ETHER_GROUP_ADDR as RTE_ETHER_GROUP_ADDR. > - rename ETHER_TYPE_IPv4 as RTE_ETHER_TYPE_IPv4. > - rename ETHER_TYPE_IPv6 as RTE_ETHER_TYPE_IPv6. > - rename ETHER_TYPE_ARP as RTE_ETHER_TYPE_ARP. > - rename ETHER_TYPE_VLAN as RTE_ETHER_TYPE_VLAN. > - rename ETHER_TYPE_RARP as RTE_ETHER_TYPE_RARP. > - rename ETHER_TYPE_QINQ as RTE_ETHER_TYPE_QINQ. > - rename ETHER_TYPE_ETAG as RTE_ETHER_TYPE_ETAG. > - rename ETHER_TYPE_1588 as RTE_ETHER_TYPE_1588. > - rename ETHER_TYPE_SLOW as RTE_ETHER_TYPE_SLOW. > - rename ETHER_TYPE_TEB as RTE_ETHER_TYPE_TEB. > - rename ETHER_TYPE_LLDP as RTE_ETHER_TYPE_LLDP. > - rename ETHER_TYPE_MPLS as RTE_ETHER_TYPE_MPLS. > - rename ETHER_TYPE_MPLSM as RTE_ETHER_TYPE_MPLSM. > - rename ETHER_VXLAN_HLEN as RTE_ETHER_VXLAN_HLEN. > - rename ETHER_ADDR_FMT_SIZE as RTE_ETHER_ADDR_FMT_SIZE. > - rename VXLAN_GPE_TYPE_IPV4 as RTE_VXLAN_GPE_TYPE_IPV4. > - rename VXLAN_GPE_TYPE_IPV6 as RTE_VXLAN_GPE_TYPE_IPV6. > - rename VXLAN_GPE_TYPE_ETH as RTE_VXLAN_GPE_TYPE_ETH. > - rename VXLAN_GPE_TYPE_NSH as RTE_VXLAN_GPE_TYPE_NSH. > - rename VXLAN_GPE_TYPE_MPLS as RTE_VXLAN_GPE_TYPE_MPLS. > - rename VXLAN_GPE_TYPE_GBP as RTE_VXLAN_GPE_TYPE_GBP. > - rename VXLAN_GPE_TYPE_VBNG as RTE_VXLAN_GPE_TYPE_VBNG. > - rename ETHER_VXLAN_GPE_HLEN as RTE_ETHER_VXLAN_GPE_HLEN. > > Do not update the command line library to avoid adding a dependency to > librte_net. > > Signed-off-by: Olivier Matz <...>
Re: [dpdk-dev] [PATCH 01/15] net: add rte prefix to arp structures
On 5/21/2019 5:13 PM, Olivier Matz wrote:
> Also rename arp_hrd, arp_pro, arp_hln, arp_pln and arp_op fields
> to avoid conflict with the #defines in gnu libc.
>
> Signed-off-by: Olivier Matz
<...>
> @@ -614,7 +614,7 @@ mode6_debug(const char __attribute__((unused)) *info,
> struct ether_hdr *eth_h,
> }
> #ifdef RTE_LIBRTE_BOND_DEBUG_ALB
> else if (ether_type == rte_cpu_to_be_16(ETHER_TYPE_ARP)) {
> - arp_h = (struct arp_hdr *)((char *)(eth_h + 1) + offset);
> + arp_h = (struct rte_arp_hdr *)((char *)(eth_h + 1) + offset);
> ipv4_addr_to_dot(arp_h->arp_data.arp_sip, src_ip,
> MaxIPv4String);
> ipv4_addr_to_dot(arp_h->arp_data.arp_tip, dst_ip,
> MaxIPv4String);
> arp_op_name(rte_be_to_cpu_16(arp_h->arp_op),
There is one 'arp_op' seems left here (should be 'arp_opcode'), I am fixing
while merging.
Re: [dpdk-dev] [PATCH 00/15] prefix network structures
On 5/21/2019 5:13 PM, Olivier Matz wrote: > The rte_net headers conflict with the libc headers, because > some definitions are duplicated, sometimes with few differences. > > This patchset adds the rte_ (or RTE_) prefix to all structures, functions > and defines in rte_net library. This is a big changeset, that will > break the API of many functions, but not the ABI. > > This was discussed in [1], and requested by the techboard [2]. > > patch-v1: > * rease on top of v19.05 > * remove uneeded renames in drivers/net/bonding/rte_eth_bond_pmd.c > and app/test-pmd/icmpecho.c (arp-related variables) > * do not modify base drivers, except cxgbe, thunderx, enetc, qede: > only files that already contain dpdk definitions are modified. > * fix checkpatch issues when it does not impact the code style too > much. Big warnings remain about the RTE_IPv4() macros because > arguments are separated by ',' instead of ', '. > * add a release note patch > * tested compilation on x86_64-linux and x86_64-freebsd. > > rfc-v2: > * rebase on top of v19.05-rc1 > > > [1] http://mails.dpdk.org/archives/dev/2018-January/087384.html > [2] http://mails.dpdk.org/archives/dev/2019-February/125033.html > > > Olivier Matz (15): > net: add rte prefix to arp structures > net: add rte prefix to arp defines > net: add rte prefix to ether structures > net: add rte prefix to ether functions > net: add rte prefix to ether defines > net: add rte prefix to esp structure > net: add rte prefix to gre structure > net: add rte prefix to icmp structure > net: add rte prefix to icmp defines > net: add rte prefix to ip structure > net: add rte prefix to ip defines > net: add rte prefix to sctp structure > net: add rte prefix to tcp structure > net: add rte prefix to udp structure > doc: announce network api change Reviewed-by: Stephen Hemminger Reviewed-by: Maxime Coquelin For series, Reviewed-by: Ferruh Yigit Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [dpdk-stable] [PATCH] app/testpmd: fix offloads overwrite by default configuration
On 5/24/2019 2:55 AM, Zhao1, Wei wrote:
>
> Hi, Ferruh
>
>> -Original Message-
>> From: Yigit, Ferruh
>> Sent: Tuesday, May 21, 2019 11:43 PM
>> To: Zhao1, Wei ; dev@dpdk.org
>> Cc: sta...@dpdk.org; Peng, Yuan ; Lu, Wenzhuo
>>
>> Subject: Re: [dpdk-stable] [PATCH] app/testpmd: fix offloads overwrite by
>> default configuration
>>
>> On 5/21/2019 2:30 AM, Zhao1, Wei wrote:
>>> Hi, Ferruh
>>>
-Original Message-
From: Yigit, Ferruh
Sent: Monday, May 20, 2019 11:23 PM
To: Zhao1, Wei ; dev@dpdk.org
Cc: sta...@dpdk.org; Peng, Yuan ; Lu, Wenzhuo
Subject: Re: [dpdk-stable] [PATCH] app/testpmd: fix offloads
overwrite by default configuration
On 5/14/2019 2:56 AM, Zhao1, Wei wrote:
> Hi, Ferruh
>
>> -Original Message-
>> From: Yigit, Ferruh
>> Sent: Tuesday, May 14, 2019 12:36 AM
>> To: Zhao1, Wei ; dev@dpdk.org
>> Cc: sta...@dpdk.org; Peng, Yuan ; Lu, Wenzhuo
>>
>> Subject: Re: [dpdk-stable] [PATCH] app/testpmd: fix offloads
>> overwrite by default configuration
>>
>> On 5/9/2019 8:20 AM, Wei Zhao wrote:
>>> There is an error in function rxtx_port_config(), which may
>>> overwrite offloads configuration get from function
>>> launch_args_parse() when run testpmd app. So rxtx_port_config()
>>> should
do "or" for port offloads.
>>>
>>> Fixes: d44f8a485f5d ("app/testpmd: enable per queue configure")
>>> cc: sta...@dpdk.org
>>>
>>> Signed-off-by: Wei Zhao
>>> ---
>>> app/test-pmd/testpmd.c | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
>>> 6fbfd29..f0061d9 100644
>>> --- a/app/test-pmd/testpmd.c
>>> +++ b/app/test-pmd/testpmd.c
>>> @@ -2809,9 +2809,12 @@ static void rxtx_port_config(struct
>>> rte_port *port) {
>>> uint16_t qid;
>>> + uint64_t offloads;
>>>
>>> for (qid = 0; qid < nb_rxq; qid++) {
>>> + offloads = port->rx_conf[qid].offloads;
>>> port->rx_conf[qid] = port->dev_info.default_rxconf;
>>> + port->rx_conf[qid].offloads |= offloads;
>>
>> OK to this changes as a fix for this release.
>>
>> But I think intention is, if no offload information is provided by
>> user to use use the driver provided defaults, if user explicitly
>> provided some values to use them, instead of OR these two.
>>
>> With this approach it is not possible to disable a driver default
>> value, so it becomes mandatory offload instead of default offload values.
>>
>> Wei, what do you think, does it make sense?
>
>
> I agree with you, but it is sure that the original code has offloads
> overwrite
issue.
> What is your suggestion for code implement?
> I find that Thomas has apply it, if you has other idea, maybe you
> has to
commit patch base to this patch.
Hi Wei,
Yes this needs to be incremental fix to existing code.
Queue specific offload can be altered either by providing Rx/Tx
offload as command line argument [1] (port configs set to each
queues) or via testpmd commands [2].
Does it make sense to set a global flag when one of above occurs and
use default config only if it is not set?
>>>
>>> I AGREE with you to submit an incremental fix, and it make sense to
>>> set a global flag when one of above occurs and use default config only if
>>> it is
>> not set when implement code, but I do not have time to prepare such a patch
>> by now, so maybe later or some else.
>>
>> I see, can you submit a public defect to record the issue, so it can be
>> addressed
>> later without forgotten?
>
> Sure, but what is a public defect patch? Do you mean I need to update some
> doc? Can you give me a link as an example
No documentation, please create an issue in public DPDK bug tracker:
https://bugs.dpdk.org/
>
>
>>
>>>
[1]
Tx
tx-offloads
Rx
disable-crc-strip
enable-lro
enable-scatter
enable-rx-cksum
enable-rx-timestamp
enable-hw-vlan
enable-hw-vlan-filter
enable-hw-vlan-strip
enable-hw-vlan-extend
[2]
"port config rx_offload ..."
"port rxq rx_offload ..."
"port config tx_offload ..."
"port txq tx_offload ..."
>>>
>
Re: [dpdk-dev] [PATCH 1/2] mk: add Marvell ARMADA architecture based on armv8-a
On 5/24/2019 2:10 AM, Ruifeng Wang (Arm Technology China) wrote: > Hi, > >> -Original Message- >> From: Liron Himi >> Sent: Thursday, May 23, 2019 18:51 >> To: Ruifeng Wang (Arm Technology China) ; >> tho...@monjalon.net >> Cc: dev@dpdk.org; nd ; Liron Himi >> Subject: RE: [dpdk-dev] [PATCH 1/2] mk: add Marvell ARMADA architecture >> based on armv8-a >> >> Hi, >> >> This patch can only work with MUSDK newer than 18.09. >> Do you have access to a newer version? > > Will newer MUSDK version available on github? > I have no access to Marvell Extranet. +1, in github [1] latest branch I can see is 18.09 [1]: https://github.com/MarvellEmbeddedProcessors/musdk-marvell.git > >> >> Regards, >> Liron >> >> -Original Message- >> From: Ruifeng Wang (Arm Technology China) >> Sent: Thursday, May 23, 2019 13:11 >> To: Liron Himi ; tho...@monjalon.net >> Cc: dev@dpdk.org; nd >> Subject: [EXT] RE: [dpdk-dev] [PATCH 1/2] mk: add Marvell ARMADA >> architecture based on armv8-a >> >> External Email >> >> -- >> Hi Liron, >> >>> -Original Message- >>> From: dev On Behalf Of lir...@marvell.com >>> Sent: Saturday, May 18, 2019 05:27 >>> To: tho...@monjalon.net >>> Cc: dev@dpdk.org; Liron Himi >>> Subject: [dpdk-dev] [PATCH 1/2] mk: add Marvell ARMADA architecture >>> based on armv8-a >>> >>> From: Liron Himi >>> >>> This patch introduces armada target to address difference in number of >>> cores, no numa support >>> >>> Change-Id: Ieaabe77b165000fe1280f98105329a0e63833b92 >>> Signed-off-by: Liron Himi >>> Reviewed-by: Alan Winkowski >>> Tested-by: Liron Himi >>> --- >> >> My local compilation on MacchiatoBin failed with the target. >> I have musdk-armada-18.09 checked out from >> https://github.com/MarvellEmbeddedProcessors/musdk-marvell.git >> LIBMUSDK_PATH was set before compiling. >> Hit errors as below: >> == Build drivers/net/mvneta >>CC mvneta_ethdev.o >> In file included from >> /home/arm/dpdk/drivers/net/mvneta/mvneta_rxtx.h:10:0, >> from >> /home/arm/dpdk/drivers/net/mvneta/mvneta_ethdev.c:25: >> /home/arm/dpdk/drivers/net/mvneta/mvneta_ethdev.h:24:29: >> fatal error: drivers/mv_neta.h: No such file or directory >> compilation terminated. >> /home/arm/dpdk/mk/internal/rte.compile-pre.mk:114: recipe for >> target 'mvneta_ethdev.o' failed >> >> I tried to copy the files from musdk to LIBMUSDK_PATH, but still cannot >> finish compiling. >>CC test_ipsec.o >>LD test >> /home/arm/dpdk/arm64-armada-linuxapp- >> gcc/lib/librte_pmd_mvneta.a(mvneta_ethdev.o): In function >> `mvneta_stats_get': >> mvneta_ethdev.c:(.text+0x1c4): undefined reference to >> `neta_ppio_get_statistics' >> /home/arm/dpdk/arm64-armada-linuxapp- >> gcc/lib/librte_pmd_mvneta.a(mvneta_ethdev.o): In function >> `mvneta_mtu_set': >> mvneta_ethdev.c:(.text+0x368): undefined reference to >> `neta_ppio_set_mru' >> mvneta_ethdev.c:(.text+0x37c): undefined reference to >> `neta_ppio_set_mtu' >> /home/arm/dpdk/arm64-armada-linuxapp- >> gcc/lib/librte_pmd_mvneta.a(mvneta_ethdev.o): In function >> `mvneta_promiscuous_disable': >> mvneta_ethdev.c:(.text+0x4e4): undefined reference to >> `neta_ppio_get_promisc' >> mvneta_ethdev.c:(.text+0x4f8): undefined reference to >> `neta_ppio_set_promisc' >> .. >> >> My musdk repo is updated. Is anything else needed? >> >> Regards, >> /Ruifeng
Re: [dpdk-dev] [PATCH] net/i40e: i40e rework for ipn3ke
On 5/24/2019 2:05 AM, Xu, Rosen wrote:
> Hi,
>
>> -Original Message-
>> From: Pei, Andy
>> Sent: Thursday, May 23, 2019 17:15
>> To: dev@dpdk.org
>> Cc: Pei, Andy ; Zhang, Roy Fan
>> ; Zhang, Qi Z ; Wu,
>> Jingjing ; Xing, Beilei ;
>> Yigit,
>> Ferruh ; Xu, Rosen
>> Subject: [PATCH] net/i40e: i40e rework for ipn3ke
>
>> Add switch_mode argument for i40e PF to specify the specific FPGA that i40e
>> PF is connected to.
>> i40e PF get link status update via the connected FPGA.
>>
>> Fixes: c60869e2b742 ("net/i40e: fix link status update")
>> Cc: roy.fan.zh...@intel.com
>> Cc: qi.z.zh...@intel.com
>> Cc: jingjing...@intel.com
>> Cc: beilei.x...@intel.com
>> Cc: ferruh.yi...@intel.com
>> Cc: rosen...@intel.com
>
> My understanding cc people should add in git send-email not in patch.
"git send-email" is picking the names from commit log, so putting the names in
the commit log is another way, but as you said at the end of the day we don't
want names be in the git history.
But what can be done is, putting the names after "---" works for both, those
names still will be picked by "git send-email" and cc'ed automatically, and this
information is part of the patch meanwhile they will be stripped automatically
when merged, so they won't be in the git history without causing manual cleanup
task to maintainers.
>
>> Signed-off-by: Andy Pei
>> ---
<- HERE
>> drivers/net/i40e/i40e_ethdev.c | 128
>> +++--
>> 1 file changed, 122 insertions(+), 6 deletions(-)
>>
<...>
Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
On 5/23/2019 11:01 PM, Stephen Hemminger wrote:
> Several users have run into problems where the MLX drivers were not
> enabled in their build. And then trying to run their DPDK
> application on Azure. What happens is that all packets
> go over the slow path, and failsafe repeatedly probes for never
> existing sub-device.
>
> Both Mellanox drivers should be checked. MLX4 for current versions,
> and MLX5 for future upgrades. This code is only called if Hyper-V/Azure
> is detected.
>
> Signed-off-by: Stephen Hemminger
> ---
> drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c
> b/drivers/net/vdev_netvsc/vdev_netvsc.c
> index 801f54c96e01..64f9dbf66e18 100644
> --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
> +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
> @@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
> struct rte_devargs *devargs;
> struct rte_bus *vbus = rte_bus_find_by_name("vdev");
>
> +#ifndef RTE_LIBRTE_MLX4_PMD
> + DRV_LOG(WARNING, "Mellanox MLX4 not configured.");
> +#endif
> +#ifndef RTE_LIBRTE_MLX5_PMD
> + DRV_LOG(WARNING, "Mellanox MLX5 not configured.");
> +#endif
Is it OK a virtual PMD being this much aware of another PMD?
Can it be an option to add this check into build system? And if there is direct
dependency perhaps even don't compile the 'vdev_netvsc' when none mlx PMD is
enabled.
> +
> RTE_EAL_DEVARGS_FOREACH("vdev", devargs)
> if (!strncmp(devargs->name, VDEV_NETVSC_DRIVER_NAME,
>VDEV_NETVSC_DRIVER_NAME_LEN))
>
Re: [dpdk-dev] [PATCH v1 25/27] mempool/octeontx2: add optimized dequeue operation for arm64
writes:
> From: Pavan Nikhilesh
>
> This patch adds an optimized arm64 instruction based routine to leverage
> CPU pipeline characteristics of octeontx2. The theme is to fill the
> pipeline with CASP operations as much HW can do so that HW can do alloc()
> HW ops in full throttle.
>
> Cc: Olivier Matz
>
> Signed-off-by: Pavan Nikhilesh
> Signed-off-by: Jerin Jacob
> Signed-off-by: Vamsi Attunuru
> ---
> drivers/mempool/octeontx2/otx2_mempool_ops.c | 291 +++
> 1 file changed, 291 insertions(+)
>
> diff --git a/drivers/mempool/octeontx2/otx2_mempool_ops.c
> b/drivers/mempool/octeontx2/otx2_mempool_ops.c
> index c59bd73c0..ebe90d122 100644
> --- a/drivers/mempool/octeontx2/otx2_mempool_ops.c
> +++ b/drivers/mempool/octeontx2/otx2_mempool_ops.c
> @@ -37,6 +37,293 @@ npa_lf_aura_op_alloc_one(const int64_t wdata, int64_t *
> const addr,
> return -ENOENT;
> }
>
> +#if defined(RTE_ARCH_ARM64)
> +static __rte_noinline int
> +npa_lf_aura_op_search_alloc(const int64_t wdata, int64_t * const addr,
> + void **obj_table, unsigned int n)
> +{
> + uint8_t i;
> +
> + for (i = 0; i < n; i++) {
> + if (obj_table[i] != NULL)
> + continue;
> + if (npa_lf_aura_op_alloc_one(wdata, addr, obj_table, i))
> + return -ENOENT;
> + }
> +
> + return 0;
> +}
> +
> +static __attribute__((optimize("-O3"))) __rte_noinline int __hot
> +npa_lf_aura_op_alloc_bulk(const int64_t wdata, int64_t * const addr,
> + unsigned int n, void **obj_table)
> +{
> + const __uint128_t wdata128 = ((__uint128_t)wdata << 64) | wdata;
> + uint64x2_t failed = vdupq_n_u64(~0);
> +
> + switch (n) {
> + case 32:
> + {
> + __uint128_t t0, t1, t2, t3, t4, t5, t6, t7, t8, t9;
> + __uint128_t t10, t11;
> +
> + asm volatile (
> + ".cpu generic+lse\n"
> + "casp %[t0], %H[t0], %[wdata], %H[wdata], [%[loc]]\n"
> + "casp %[t1], %H[t1], %[wdata], %H[wdata], [%[loc]]\n"
> + "casp %[t2], %H[t2], %[wdata], %H[wdata], [%[loc]]\n"
> + "casp %[t3], %H[t3], %[wdata], %H[wdata], [%[loc]]\n"
> + "casp %[t4], %H[t4], %[wdata], %H[wdata], [%[loc]]\n"
> + "casp %[t5], %H[t5], %[wdata], %H[wdata], [%[loc]]\n"
> + "casp %[t6], %H[t6], %[wdata], %H[wdata], [%[loc]]\n"
> + "casp %[t7], %H[t7], %[wdata], %H[wdata], [%[loc]]\n"
> + "casp %[t8], %H[t8], %[wdata], %H[wdata], [%[loc]]\n"
> + "casp %[t9], %H[t9], %[wdata], %H[wdata], [%[loc]]\n"
> + "casp %[t10], %H[t10], %[wdata], %H[wdata], [%[loc]]\n"
> + "casp %[t11], %H[t11], %[wdata], %H[wdata], [%[loc]]\n"
> + "fmov d16, %[t0]\n"
> + "fmov v16.D[1], %H[t0]\n"
> + "casp %[t0], %H[t0], %[wdata], %H[wdata], [%[loc]]\n"
> + "fmov d17, %[t1]\n"
> + "fmov v17.D[1], %H[t1]\n"
> + "casp %[t1], %H[t1], %[wdata], %H[wdata], [%[loc]]\n"
> + "fmov d18, %[t2]\n"
> + "fmov v18.D[1], %H[t2]\n"
> + "casp %[t2], %H[t2], %[wdata], %H[wdata], [%[loc]]\n"
> + "fmov d19, %[t3]\n"
> + "fmov v19.D[1], %H[t3]\n"
> + "casp %[t3], %H[t3], %[wdata], %H[wdata], [%[loc]]\n"
> + "and %[failed].16B, %[failed].16B, v16.16B\n"
> + "and %[failed].16B, %[failed].16B, v17.16B\n"
> + "and %[failed].16B, %[failed].16B, v18.16B\n"
> + "and %[failed].16B, %[failed].16B, v19.16B\n"
> + "fmov d20, %[t4]\n"
> + "fmov v20.D[1], %H[t4]\n"
> + "fmov d21, %[t5]\n"
> + "fmov v21.D[1], %H[t5]\n"
> + "fmov d22, %[t6]\n"
> + "fmov v22.D[1], %H[t6]\n"
> + "fmov d23, %[t7]\n"
> + "fmov v23.D[1], %H[t7]\n"
> + "and %[failed].16B, %[failed].16B, v20.16B\n"
> + "and %[failed].16B, %[failed].16B, v21.16B\n"
> + "and %[failed].16B, %[failed].16B, v22.16B\n"
> + "and %[failed].16B, %[failed].16B, v23.16B\n"
> + "st1 { v16.2d, v17.2d, v18.2d, v19.2d}, [%[dst]], 64\n"
> + "st1 { v20.2d, v21.2d, v22.2d, v23.2d}, [%[dst]], 64\n"
> + "fmov d16, %[t8]\n"
> + "fmov v16.D[1], %H[t8]\n"
> + "fmov d17, %[t9]\n"
> + "fmov v17.D[1], %H[t9]\n"
> + "fmov d18, %[t10]\n"
> + "fmov v18.D[1], %H[t10]\n"
> + "fmov d19, %[t11]\n"
> + "fmov v19.D[1], %H[t11]\n"
> + "and %[failed].16B, %[failed].16B, v16.16B\n"
> + "and %[failed].16B, %[failed].16B, v17.16B\n"
> + "and %[failed].16B, %[failed].16B, v18.16B\n"
> + "and %[failed].16B, %[failed].16B, v19.16B\n"
> + "fmov d20, %[t0]\n"
> + "fmov v20.D[1], %H[t0]\n"
> + "fmov d21, %[t1]\n"
Re: [dpdk-dev] [PATCH] devtools: pass custom options to checkpatch
On 5/23/2019 8:45 AM, Olivier Matz wrote: > Add the ability to pass custom options to checkpatch script. An example > of use is to change the output format so it can run in emacs compilation > mode: > > DPDK_CHECKPATCH_PATH=/path/to/linux/scripts/checkpatch.pl \ > DPDK_CHECKPATCH_OPTIONS='--emacs --showfile --no-color' \ > /path/to/dpdk.org/devtools/checkpatches.sh > > Signed-off-by: Olivier Matz Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH v2 3/5] vhost: do not inline unlikely fragmented buffers code
On 5/20/19 7:51 AM, Tiwei Bie wrote:
On Fri, May 17, 2019 at 05:06:11PM +0200, Maxime Coquelin wrote:
[...]
+static void
+copy_vnet_hdr_from_desc(struct virtio_net_hdr *hdr,
+ struct buf_vector *buf_vec)
+{
+ uint64_t len;
+ uint64_t remain = sizeof(struct virtio_net_hdr);
+ uint64_t src;
+ uint64_t dst = (uint64_t)(uintptr_t)&hdr;
typo: s/&hdr/hdr/
Nice catch! It wasn't spotted at build time due to the cast.
+
+ /*
+* No luck, the virtio-net header doesn't fit
+* in a contiguous virtual area.
+*/
+ while (remain) {
+ len = RTE_MIN(remain, buf_vec->buf_len);
+ src = buf_vec->buf_addr;
+ rte_memcpy((void *)(uintptr_t)dst,
+ (void *)(uintptr_t)src, len);
+
+ remain -= len;
+ dst += len;
+ buf_vec++;
+ }
+}
+
static __rte_always_inline int
copy_desc_to_mbuf(struct virtio_net *dev, struct vhost_virtqueue *vq,
struct buf_vector *buf_vec, uint16_t nr_vec,
@@ -1094,28 +1126,7 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct
vhost_virtqueue *vq,
if (virtio_net_with_host_offload(dev)) {
if (unlikely(buf_len < sizeof(struct virtio_net_hdr))) {
- uint64_t len;
- uint64_t remain = sizeof(struct virtio_net_hdr);
- uint64_t src;
- uint64_t dst = (uint64_t)(uintptr_t)&tmp_hdr;
- uint16_t hdr_vec_idx = 0;
-
- /*
-* No luck, the virtio-net header doesn't fit
-* in a contiguous virtual area.
-*/
It's better to not move above comments.
Right, I will revert it back here.
For the rest,
Reviewed-by: Tiwei Bie
Thanks,
Maxime
- while (remain) {
- len = RTE_MIN(remain,
- buf_vec[hdr_vec_idx].buf_len);
- src = buf_vec[hdr_vec_idx].buf_addr;
- rte_memcpy((void *)(uintptr_t)dst,
- (void *)(uintptr_t)src, len);
-
- remain -= len;
- dst += len;
- hdr_vec_idx++;
- }
-
+ copy_vnet_hdr_from_desc(&tmp_hdr, buf_vec);
hdr = &tmp_hdr;
} else {
hdr = (struct virtio_net_hdr *)((uintptr_t)buf_addr);
--
2.21.0
Re: [dpdk-dev] [PATCH v2] net/i40e: allow VF to configure pctype mapping
On 5/23/2019 2:37 AM, Beilei Xing wrote:
> This patch allows VF to get/update/reset pctype
> mapping info.
>
> Signed-off-by: Beilei Xing
> ---
> v2 changes:
> - Allow VF update/reset pctype mapping.
>
> drivers/net/i40e/rte_pmd_i40e.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/net/i40e/rte_pmd_i40e.c b/drivers/net/i40e/rte_pmd_i40e.c
> index 7ae78e4..b3bdc61 100644
> --- a/drivers/net/i40e/rte_pmd_i40e.c
> +++ b/drivers/net/i40e/rte_pmd_i40e.c
> @@ -2405,8 +2405,6 @@ int rte_pmd_i40e_flow_type_mapping_reset(uint16_t port)
>
> dev = &rte_eth_devices[port];
>
> - if (!is_i40e_supported(dev))
> - return -ENOTSUP;
Hi Beilei,
Since these are public APIs, these checks are to prevent possible issues user
call these APIs with a port_id that is not 'i40e' at all, in that case the API
still will try to work on that device and this may lead a crash or corruption in
that device.
Instead of removing these checks, can it be possible to extend it to cover both
PF and VF? If there are APIs in this file that requires device explicitly to be
PF or VF, perhaps we can create two version of the check and use appropriate one
for the API.
>
> i40e_set_default_pctype_table(dev);
>
> @@ -2425,9 +2423,6 @@ int rte_pmd_i40e_flow_type_mapping_get(
>
> dev = &rte_eth_devices[port];
>
> - if (!is_i40e_supported(dev))
> - return -ENOTSUP;
> -
> ad = I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
>
> for (i = 0; i < I40E_FLOW_TYPE_MAX; i++) {
> @@ -2453,9 +2448,6 @@ rte_pmd_i40e_flow_type_mapping_update(
>
> dev = &rte_eth_devices[port];
>
> - if (!is_i40e_supported(dev))
> - return -ENOTSUP;
> -
> if (count > I40E_FLOW_TYPE_MAX)
> return -EINVAL;
>
>
Re: [dpdk-dev] [PATCH] devtools: pass custom options to checkpatch
On 5/23/2019 8:45 AM, Olivier Matz wrote: > Add the ability to pass custom options to checkpatch script. An example > of use is to change the output format so it can run in emacs compilation > mode: > > DPDK_CHECKPATCH_PATH=/path/to/linux/scripts/checkpatch.pl \ > DPDK_CHECKPATCH_OPTIONS='--emacs --showfile --no-color' \ > /path/to/dpdk.org/devtools/checkpatches.sh > > Signed-off-by: Olivier Matz Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] net/mlx4: use dynamic log type
On 5/21/2019 10:27 PM, Stephen Hemminger wrote:
> This driver should use dynamic log level not RTE_LOGTYPE_PMD.
> Other drivers were converted back in 18.02.
>
> This is really a bug, all other drivers use dynamic log levels
> by now.
+1, we should switch it to dynamic log much earlier
Matan, Shahaf,
This patch will have problem with "RTE_LOG" usage, need to use rte_log() I
guess, can you (or Stephen, whoever can work on it) please send a new version?
Thanks,
ferruh
>
> Signed-off-by: Stephen Hemminger
> ---
> drivers/net/mlx4/mlx4.c | 8
> drivers/net/mlx4/mlx4_utils.h | 6 --
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
> index fe559c040706..e532dc53738f 100644
> --- a/drivers/net/mlx4/mlx4.c
> +++ b/drivers/net/mlx4/mlx4.c
> @@ -60,6 +60,9 @@ static rte_spinlock_t mlx4_shared_data_lock =
> RTE_SPINLOCK_INITIALIZER;
> /* Process local data for secondary processes. */
> static struct mlx4_local_data mlx4_local_data;
>
> +/** Driver-specific log messages type. */
> +int mlx4_logtype;
> +
> /** Configuration structure for device arguments. */
> struct mlx4_conf {
> struct {
> @@ -1272,6 +1275,11 @@ mlx4_glue_init(void)
> */
> RTE_INIT(rte_mlx4_pmd_init)
> {
> + /* Initialize driver log type. */
> + mlx4_logtype = rte_log_register("pmd.net.mlx4");
> + if (mlx4_logtype >= 0)
> + rte_log_set_level(mlx4_logtype, RTE_LOG_NOTICE);
> +
> /*
>* MLX4_DEVICE_FATAL_CLEANUP tells ibv_destroy functions we
>* want to get success errno value in case of calling them
> diff --git a/drivers/net/mlx4/mlx4_utils.h b/drivers/net/mlx4/mlx4_utils.h
> index 86abb3b7e376..9d3d2a4e32a1 100644
> --- a/drivers/net/mlx4/mlx4_utils.h
> +++ b/drivers/net/mlx4/mlx4_utils.h
> @@ -15,6 +15,8 @@
>
> #include "mlx4.h"
>
> +extern int mlx4_logtype;
> +
> #ifndef NDEBUG
>
> /*
> @@ -35,7 +37,7 @@ pmd_drv_log_basename(const char *s)
> }
>
> #define PMD_DRV_LOG(level, ...) \
> - RTE_LOG(level, PMD, \
> + RTE_LOG(level, mlx4_logtype, \
> RTE_FMT("%s:%u: %s(): " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
> pmd_drv_log_basename(__FILE__), \
> __LINE__, \
> @@ -52,7 +54,7 @@ pmd_drv_log_basename(const char *s)
> */
>
> #define PMD_DRV_LOG(level, ...) \
> - RTE_LOG(level, PMD, \
> + RTE_LOG(level, mlx4_logtype, \
> RTE_FMT(MLX4_DRIVER_NAME ": " \
> RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
> RTE_FMT_TAIL(__VA_ARGS__,)))
>
[dpdk-dev] [PATCH v2 00/10] bnxt patchset
This patchset bsae on top of the previous submission adds the following: 1) Support for vector mode TX and RX. 2) HWRM API update (split into multiple patches). 3) Fixes for RSS reta update and query. It also updates the release notes. v2: * Squashed patches 3 and 4 from v1 patchset. * Added Meson build support for vector mode PMD. * Dropped two unnecessary code style changes from patch 3. Ajit Khaparde (5): net/bnxt: fix RSS reta indirection table update net/bnxt: update HWRM API net/bnxt: update HWRM version net/bnxt: HWRM version update net/bnxt: update release notes for bnxt Lance Richardson (5): net/bnxt: move tx bd checking to header file net/bnxt: compute and store scattered RX status net/bnxt: implement vector mode driver net/bnxt: use reta update mask and translate qid to grp id net/bnxt: fix reta query op config/common_base |1 + doc/guides/rel_notes/release_19_08.rst |6 + drivers/net/bnxt/Makefile |1 + drivers/net/bnxt/bnxt_ethdev.c | 198 +- drivers/net/bnxt/bnxt_hwrm.c |1 + drivers/net/bnxt/bnxt_ring.h |3 +- drivers/net/bnxt/bnxt_rxq.c|5 + drivers/net/bnxt/bnxt_rxq.h|4 + drivers/net/bnxt/bnxt_rxr.h|9 +- drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 481 ++ drivers/net/bnxt/bnxt_txr.c| 15 - drivers/net/bnxt/bnxt_txr.h| 20 + drivers/net/bnxt/hsi_struct_def_dpdk.h | 7573 drivers/net/bnxt/meson.build |5 + 14 files changed, 7217 insertions(+), 1105 deletions(-) create mode 100644 drivers/net/bnxt/bnxt_rxtx_vec_sse.c -- 2.17.1
[dpdk-dev] [PATCH v2 01/10] net/bnxt: move tx bd checking to header file
To allow sharing of tx_bds_in_hw() and bnxt_tx_avail() between
vector-mode and non-vector transmit functions, move these functions
into bnxt_txr.h.
Signed-off-by: Lance Richardson
Reviewed-by: Ajit Khaparde
Reviewed-by: Maxime Coquelin
---
drivers/net/bnxt/bnxt_txr.c | 15 ---
drivers/net/bnxt/bnxt_txr.h | 15 +++
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_txr.c b/drivers/net/bnxt/bnxt_txr.c
index 9de12e0d0..16598ba63 100644
--- a/drivers/net/bnxt/bnxt_txr.c
+++ b/drivers/net/bnxt/bnxt_txr.c
@@ -103,21 +103,6 @@ int bnxt_init_tx_ring_struct(struct bnxt_tx_queue *txq,
unsigned int socket_id)
return 0;
}
-static inline uint32_t bnxt_tx_bds_in_hw(struct bnxt_tx_queue *txq)
-{
- return ((txq->tx_ring->tx_prod - txq->tx_ring->tx_cons) &
- txq->tx_ring->tx_ring_struct->ring_mask);
-}
-
-static inline uint32_t bnxt_tx_avail(struct bnxt_tx_queue *txq)
-{
- /* Tell compiler to fetch tx indices from memory. */
- rte_compiler_barrier();
-
- return ((txq->tx_ring->tx_ring_struct->ring_size -
-bnxt_tx_bds_in_hw(txq)) - 1);
-}
-
static uint16_t bnxt_start_xmit(struct rte_mbuf *tx_pkt,
struct bnxt_tx_queue *txq,
uint16_t *coal_pkts,
diff --git a/drivers/net/bnxt/bnxt_txr.h b/drivers/net/bnxt/bnxt_txr.h
index f802d5080..13ca04676 100644
--- a/drivers/net/bnxt/bnxt_txr.h
+++ b/drivers/net/bnxt/bnxt_txr.h
@@ -37,6 +37,21 @@ struct bnxt_sw_tx_bd {
unsigned short nr_bds;
};
+static inline uint32_t bnxt_tx_bds_in_hw(struct bnxt_tx_queue *txq)
+{
+ return ((txq->tx_ring->tx_prod - txq->tx_ring->tx_cons) &
+ txq->tx_ring->tx_ring_struct->ring_mask);
+}
+
+static inline uint32_t bnxt_tx_avail(struct bnxt_tx_queue *txq)
+{
+ /* Tell compiler to fetch tx indices from memory. */
+ rte_compiler_barrier();
+
+ return ((txq->tx_ring->tx_ring_struct->ring_size -
+bnxt_tx_bds_in_hw(txq)) - 1);
+}
+
void bnxt_free_tx_rings(struct bnxt *bp);
int bnxt_init_one_tx_ring(struct bnxt_tx_queue *txq);
int bnxt_init_tx_ring_struct(struct bnxt_tx_queue *txq, unsigned int
socket_id);
--
2.17.1
[dpdk-dev] [PATCH v2 02/10] net/bnxt: compute and store scattered RX status
In preparation for a bnxt vector-mode driver, compute and store
scattered_rx status for the device when started.
Signed-off-by: Lance Richardson
Reviewed-by: Ajit Khaparde
Reviewed-by: Maxime Coquelin
---
drivers/net/bnxt/bnxt_ethdev.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index da0de211d..e0e0b72c6 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -624,6 +624,27 @@ static int bnxt_dev_lsc_intr_setup(struct rte_eth_dev
*eth_dev)
return 0;
}
+/*
+ * Determine whether the current configuration requires support for scattered
+ * receive; return 1 if scattered receive is required and 0 if not.
+ */
+static int bnxt_scattered_rx(struct rte_eth_dev *eth_dev)
+{
+ uint16_t buf_size;
+ int i;
+
+ for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
+ struct bnxt_rx_queue *rxq = eth_dev->data->rx_queues[i];
+
+ buf_size = (uint16_t)(rte_pktmbuf_data_room_size(rxq->mb_pool) -
+ RTE_PKTMBUF_HEADROOM);
+ if (eth_dev->data->dev_conf.rxmode.max_rx_pkt_len +
+ VLAN_TAG_SIZE * BNXT_NUM_VLANS > buf_size)
+ return 1;
+ }
+ return 0;
+}
+
static int bnxt_dev_start_op(struct rte_eth_dev *eth_dev)
{
struct bnxt *bp = (struct bnxt *)eth_dev->data->dev_private;
@@ -642,6 +663,8 @@ static int bnxt_dev_start_op(struct rte_eth_dev *eth_dev)
if (rc)
goto error;
+ eth_dev->data->scattered_rx = bnxt_scattered_rx(eth_dev);
+
bnxt_link_update_op(eth_dev, 1);
if (rx_offloads & DEV_RX_OFFLOAD_VLAN_FILTER)
--
2.17.1
[dpdk-dev] [PATCH v2 03/10] net/bnxt: implement vector mode driver
Introduce vector mode support for the bnxt pmd.
Signed-off-by: Lance Richardson
Signed-off-by: Ajit Khaparde
---
v2:
* Squashed with v1 patch 4 ("fix double counting VLAN tags").
* Dropped two unnecessary coding style changes from bnxt_txr.h.
config/common_base | 1 +
drivers/net/bnxt/Makefile| 1 +
drivers/net/bnxt/bnxt_ethdev.c | 95 +-
drivers/net/bnxt/bnxt_ring.h | 3 +-
drivers/net/bnxt/bnxt_rxq.c | 5 +
drivers/net/bnxt/bnxt_rxq.h | 4 +
drivers/net/bnxt/bnxt_rxr.h | 9 +-
drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 481 +++
drivers/net/bnxt/bnxt_txr.h | 5 +
drivers/net/bnxt/meson.build | 5 +
10 files changed, 600 insertions(+), 9 deletions(-)
create mode 100644 drivers/net/bnxt/bnxt_rxtx_vec_sse.c
diff --git a/config/common_base b/config/common_base
index 6b96e0e80..1bbb7c10b 100644
--- a/config/common_base
+++ b/config/common_base
@@ -212,6 +212,7 @@ CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
# Compile burst-oriented Broadcom BNXT PMD driver
#
CONFIG_RTE_LIBRTE_BNXT_PMD=y
+CONFIG_RTE_LIBRTE_BNXT_INC_VECTOR=n
#
# Compile burst-oriented Chelsio Terminator (CXGBE) PMD
diff --git a/drivers/net/bnxt/Makefile b/drivers/net/bnxt/Makefile
index 8be3cb0e4..9e006b5d1 100644
--- a/drivers/net/bnxt/Makefile
+++ b/drivers/net/bnxt/Makefile
@@ -41,6 +41,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_vnic.c
SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_irq.c
SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_util.c
SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += rte_pmd_bnxt.c
+SRCS-$(CONFIG_RTE_LIBRTE_BNXT_INC_VECTOR) += bnxt_rxtx_vec_sse.c
#
# Export include files
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index e0e0b72c6..52a6b94e0 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -638,13 +638,73 @@ static int bnxt_scattered_rx(struct rte_eth_dev *eth_dev)
buf_size = (uint16_t)(rte_pktmbuf_data_room_size(rxq->mb_pool) -
RTE_PKTMBUF_HEADROOM);
- if (eth_dev->data->dev_conf.rxmode.max_rx_pkt_len +
- VLAN_TAG_SIZE * BNXT_NUM_VLANS > buf_size)
+ if (eth_dev->data->dev_conf.rxmode.max_rx_pkt_len > buf_size)
return 1;
}
return 0;
}
+static eth_rx_burst_t
+bnxt_receive_function(__rte_unused struct rte_eth_dev *eth_dev)
+{
+#ifdef RTE_LIBRTE_BNXT_INC_VECTOR
+ /*
+* Vector mode receive can be enabled only if scatter rx is not
+* in use and rx offloads are limited to VLAN stripping and
+* CRC stripping.
+*/
+ if (!eth_dev->data->scattered_rx &&
+ !(eth_dev->data->dev_conf.rxmode.offloads &
+ ~(DEV_RX_OFFLOAD_VLAN_STRIP |
+ DEV_RX_OFFLOAD_KEEP_CRC |
+ DEV_RX_OFFLOAD_JUMBO_FRAME |
+ DEV_RX_OFFLOAD_IPV4_CKSUM |
+ DEV_RX_OFFLOAD_UDP_CKSUM |
+ DEV_RX_OFFLOAD_TCP_CKSUM |
+ DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM |
+ DEV_RX_OFFLOAD_VLAN_FILTER))) {
+ PMD_DRV_LOG(INFO, "Using vector mode receive for port %d\n",
+ eth_dev->data->port_id);
+ return bnxt_recv_pkts_vec;
+ }
+ PMD_DRV_LOG(INFO, "Vector mode receive disabled for port %d\n",
+ eth_dev->data->port_id);
+ PMD_DRV_LOG(INFO,
+ "Port %d scatter: %d rx offload: %" PRIX64 "\n",
+ eth_dev->data->port_id,
+ eth_dev->data->scattered_rx,
+ eth_dev->data->dev_conf.rxmode.offloads);
+#endif
+ return bnxt_recv_pkts;
+}
+
+static eth_tx_burst_t
+bnxt_transmit_function(__rte_unused struct rte_eth_dev *eth_dev)
+{
+#ifdef RTE_LIBRTE_BNXT_INC_VECTOR
+ /*
+* Vector mode receive can be enabled only if scatter tx is not
+* in use and tx offloads other than VLAN insertion are not
+* in use.
+*/
+ if (!eth_dev->data->scattered_rx &&
+ !(eth_dev->data->dev_conf.txmode.offloads &
+ ~DEV_TX_OFFLOAD_VLAN_INSERT)) {
+ PMD_DRV_LOG(INFO, "Using vector mode transmit for port %d\n",
+ eth_dev->data->port_id);
+ return bnxt_xmit_pkts_vec;
+ }
+ PMD_DRV_LOG(INFO, "Vector mode transmit disabled for port %d\n",
+ eth_dev->data->port_id);
+ PMD_DRV_LOG(INFO,
+ "Port %d scatter: %d tx offload: %" PRIX64 "\n",
+ eth_dev->data->port_id,
+ eth_dev->data->scattered_rx,
+ eth_dev->data->dev_conf.txmode.offloads);
+#endif
+ return bnxt_xmit_pkts;
+}
+
static int bnxt_dev_start_op(struct rte_eth_dev *eth_dev)
{
struct bnxt *bp = (struct bnxt *)eth_dev->data->dev_private;
@@ -675,6 +735,8 @@ static int bnxt_dev_start_op(
[dpdk-dev] [PATCH v2 04/10] net/bnxt: fix RSS reta indirection table update
From: Ajit Khaparde
We are trying to update the indirection table for all the VNICs.
We should update the table only for the default vnic0.
This patch fixes the above issue.
Fixes: d819382543f3 ("net/bnxt: add RSS redirection table operations")
Signed-off-by: Ajit Khaparde
Reviewed-by: Rahul Gupta
Reviewed-by: Lance Richardson
---
drivers/net/bnxt/bnxt_ethdev.c | 18 ++
drivers/net/bnxt/bnxt_hwrm.c | 1 +
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 52a6b94e0..2d892cd4f 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -983,8 +983,13 @@ static int bnxt_reta_update_op(struct rte_eth_dev *eth_dev,
{
struct bnxt *bp = (struct bnxt *)eth_dev->data->dev_private;
struct rte_eth_conf *dev_conf = &bp->eth_dev->data->dev_conf;
- struct bnxt_vnic_info *vnic;
- int i;
+ struct bnxt_vnic_info *vnic = &bp->vnic_info[0];
+
+ /* Update the default RSS VNIC */
+ if (!vnic)
+ return -EINVAL;
+ if (!vnic->rss_table)
+ return -EINVAL;
if (!(dev_conf->rxmode.mq_mode & ETH_MQ_RX_RSS_FLAG))
return -EINVAL;
@@ -995,12 +1000,9 @@ static int bnxt_reta_update_op(struct rte_eth_dev
*eth_dev,
"(%d)\n", reta_size, HW_HASH_INDEX_SIZE);
return -EINVAL;
}
- /* Update the RSS VNIC(s) */
- for (i = 0; i < bp->max_vnics; i++) {
- vnic = &bp->vnic_info[i];
- memcpy(vnic->rss_table, reta_conf, reta_size);
- bnxt_hwrm_vnic_rss_cfg(bp, vnic);
- }
+
+ memcpy(vnic->rss_table, reta_conf, reta_size);
+ bnxt_hwrm_vnic_rss_cfg(bp, vnic);
return 0;
}
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index eb5c41ebb..8c4fa556d 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -1607,6 +1607,7 @@ int bnxt_hwrm_vnic_rss_cfg(struct bnxt *bp,
req.hash_key_tbl_addr =
rte_cpu_to_le_64(vnic->rss_hash_key_dma_addr);
req.rss_ctx_idx = rte_cpu_to_le_16(vnic->rss_rule);
+ req.vnic_id = rte_cpu_to_le_16(vnic->fw_vnic_id);
rc = bnxt_hwrm_send_message(bp, &req, sizeof(req), BNXT_USE_CHIMP_MB);
--
2.17.1
[dpdk-dev] [PATCH v2 05/10] net/bnxt: use reta update mask and translate qid to grp id
Fix the reta update function to only update table entries that are
selected by the update mask. Translate queue number to firmware
group ID when updating an entry.
Fixes: d819382543f3 ("net/bnxt: add RSS redirection table operations")
Signed-off-by: Lance Richardson
Reviewed-by: Ajit Khaparde
---
drivers/net/bnxt/bnxt_ethdev.c | 39 --
1 file changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 2d892cd4f..d2b89a217 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -977,6 +977,15 @@ static void bnxt_allmulticast_disable_op(struct
rte_eth_dev *eth_dev)
bnxt_hwrm_cfa_l2_set_rx_mask(bp, vnic, 0, NULL);
}
+/* Return bnxt_rx_queue pointer corresponding to a given rxq. */
+static struct bnxt_rx_queue *bnxt_qid_to_rxq(struct bnxt *bp, uint16_t qid)
+{
+ if (qid >= bp->rx_nr_rings)
+ return NULL;
+
+ return bp->eth_dev->data->rx_queues[qid];
+}
+
static int bnxt_reta_update_op(struct rte_eth_dev *eth_dev,
struct rte_eth_rss_reta_entry64 *reta_conf,
uint16_t reta_size)
@@ -984,24 +993,42 @@ static int bnxt_reta_update_op(struct rte_eth_dev
*eth_dev,
struct bnxt *bp = (struct bnxt *)eth_dev->data->dev_private;
struct rte_eth_conf *dev_conf = &bp->eth_dev->data->dev_conf;
struct bnxt_vnic_info *vnic = &bp->vnic_info[0];
+ uint16_t tbl_size = HW_HASH_INDEX_SIZE;
+ uint16_t idx, sft;
+ int i;
- /* Update the default RSS VNIC */
- if (!vnic)
- return -EINVAL;
if (!vnic->rss_table)
return -EINVAL;
if (!(dev_conf->rxmode.mq_mode & ETH_MQ_RX_RSS_FLAG))
return -EINVAL;
- if (reta_size != HW_HASH_INDEX_SIZE) {
+ if (reta_size != tbl_size) {
PMD_DRV_LOG(ERR, "The configured hash table lookup size "
"(%d) must equal the size supported by the hardware "
- "(%d)\n", reta_size, HW_HASH_INDEX_SIZE);
+ "(%d)\n", reta_size, tbl_size);
return -EINVAL;
}
- memcpy(vnic->rss_table, reta_conf, reta_size);
+ for (i = 0; i < reta_size; i++) {
+ struct bnxt_rx_queue *rxq;
+
+ idx = i / RTE_RETA_GROUP_SIZE;
+ sft = i % RTE_RETA_GROUP_SIZE;
+
+ if (!(reta_conf[idx].mask & (1ULL << sft)))
+ continue;
+
+ rxq = bnxt_qid_to_rxq(bp, reta_conf[idx].reta[sft]);
+ if (!rxq) {
+ PMD_DRV_LOG(ERR, "Invalid ring in reta_conf.\n");
+ return -EINVAL;
+ }
+
+ vnic->rss_table[i] =
+ vnic->fw_grp_ids[reta_conf[idx].reta[sft]];
+ }
+
bnxt_hwrm_vnic_rss_cfg(bp, vnic);
return 0;
}
--
2.17.1
[dpdk-dev] [PATCH v2 06/10] net/bnxt: fix reta query op
Fix reta query op to only return table entries as identfied by the
provided mask. Translate firmware group IDs to queue numbers.
Removed extraneous code from bnxt_reta_query_op().
Fixes: d819382543f3 ("net/bnxt: add RSS redirection table operations")
Signed-off-by: Lance Richardson
Reviewed-by: Ajit Khaparde
---
drivers/net/bnxt/bnxt_ethdev.c | 47 +++---
1 file changed, 32 insertions(+), 15 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index d2b89a217..70924d93d 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -618,12 +618,6 @@ static void bnxt_print_link_info(struct rte_eth_dev
*eth_dev)
eth_dev->data->port_id);
}
-static int bnxt_dev_lsc_intr_setup(struct rte_eth_dev *eth_dev)
-{
- bnxt_print_link_info(eth_dev);
- return 0;
-}
-
/*
* Determine whether the current configuration requires support for scattered
* receive; return 1 if scattered receive is required and 0 if not.
@@ -986,6 +980,19 @@ static struct bnxt_rx_queue *bnxt_qid_to_rxq(struct bnxt
*bp, uint16_t qid)
return bp->eth_dev->data->rx_queues[qid];
}
+/* Return rxq corresponding to a given rss table ring/group ID. */
+static uint16_t bnxt_rss_to_qid(struct bnxt *bp, uint16_t fwr)
+{
+ unsigned int i;
+
+ for (i = 0; i < bp->rx_nr_rings; i++) {
+ if (bp->grp_info[i].fw_grp_id == fwr)
+ return i;
+ }
+
+ return INVALID_HW_RING_ID;
+}
+
static int bnxt_reta_update_op(struct rte_eth_dev *eth_dev,
struct rte_eth_rss_reta_entry64 *reta_conf,
uint16_t reta_size)
@@ -1039,8 +1046,8 @@ static int bnxt_reta_query_op(struct rte_eth_dev *eth_dev,
{
struct bnxt *bp = (struct bnxt *)eth_dev->data->dev_private;
struct bnxt_vnic_info *vnic = &bp->vnic_info[0];
- struct rte_intr_handle *intr_handle
- = &bp->pdev->intr_handle;
+ uint16_t tbl_size = HW_HASH_INDEX_SIZE;
+ uint16_t idx, sft, i;
/* Retrieve from the default VNIC */
if (!vnic)
@@ -1048,18 +1055,28 @@ static int bnxt_reta_query_op(struct rte_eth_dev
*eth_dev,
if (!vnic->rss_table)
return -EINVAL;
- if (reta_size != HW_HASH_INDEX_SIZE) {
+ if (reta_size != tbl_size) {
PMD_DRV_LOG(ERR, "The configured hash table lookup size "
"(%d) must equal the size supported by the hardware "
- "(%d)\n", reta_size, HW_HASH_INDEX_SIZE);
+ "(%d)\n", reta_size, tbl_size);
return -EINVAL;
}
- /* EW - need to revisit here copying from uint64_t to uint16_t */
- memcpy(reta_conf, vnic->rss_table, reta_size);
- if (rte_intr_allow_others(intr_handle)) {
- if (eth_dev->data->dev_conf.intr_conf.lsc != 0)
- bnxt_dev_lsc_intr_setup(eth_dev);
+ for (idx = 0, i = 0; i < reta_size; i++) {
+ idx = i / RTE_RETA_GROUP_SIZE;
+ sft = i % RTE_RETA_GROUP_SIZE;
+
+ if (reta_conf[idx].mask & (1ULL << sft)) {
+ uint16_t qid;
+
+ qid = bnxt_rss_to_qid(bp, vnic->rss_table[i]);
+
+ if (qid == INVALID_HW_RING_ID) {
+ PMD_DRV_LOG(ERR, "Inv. entry in rss table.\n");
+ return -EINVAL;
+ }
+ reta_conf[idx].reta[sft] = qid;
+ }
}
return 0;
--
2.17.1
[dpdk-dev] [PATCH v2 07/10] net/bnxt: update HWRM API
From: Ajit Khaparde
Update HWRM API to version 1.10.0.19
Signed-off-by: Ajit Khaparde
Reviewed-by: Lance Richardson
---
drivers/net/bnxt/hsi_struct_def_dpdk.h | 3112 +++-
1 file changed, 2514 insertions(+), 598 deletions(-)
diff --git a/drivers/net/bnxt/hsi_struct_def_dpdk.h
b/drivers/net/bnxt/hsi_struct_def_dpdk.h
index e80057936..ea9a7d40e 100644
--- a/drivers/net/bnxt/hsi_struct_def_dpdk.h
+++ b/drivers/net/bnxt/hsi_struct_def_dpdk.h
@@ -1,5 +1,5 @@
/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright (c) 2014-2018 Broadcom Limited
+ * Copyright (c) 2014-2019 Broadcom Limited
* All rights reserved.
*
* DO NOT MODIFY!!! This file is automatically generated.
@@ -68,9 +68,9 @@ struct hwrm_resp_hdr {
/* RoCE slow path command */
#define TLV_TYPE_ROCE_SP_COMMAND UINT32_C(0x3)
/* RoCE slow path command to query CC Gen1 support. */
-#define TLV_TYPE_QUERY_ROCE_CC_GEN1 UINT32_C(0xcommand 0x0005)
+#define TLV_TYPE_QUERY_ROCE_CC_GEN1 UINT32_C(0x4)
/* RoCE slow path command to modify CC Gen1 support. */
-#define TLV_TYPE_MODIFY_ROCE_CC_GEN1 UINT32_C(0xcommand 0x0005)
+#define TLV_TYPE_MODIFY_ROCE_CC_GEN1 UINT32_C(0x5)
/* Engine CKV - The device's serial number. */
#define TLV_TYPE_ENGINE_CKV_DEVICE_SERIAL_NUMBER UINT32_C(0x8001)
/* Engine CKV - Per-function random nonce data. */
@@ -366,6 +366,7 @@ struct cmd_nums {
#define HWRM_TUNNEL_DST_PORT_QUERYUINT32_C(0xa0)
#define HWRM_TUNNEL_DST_PORT_ALLOCUINT32_C(0xa1)
#define HWRM_TUNNEL_DST_PORT_FREE UINT32_C(0xa2)
+ #define HWRM_STAT_CTX_ENG_QUERY UINT32_C(0xaf)
#define HWRM_STAT_CTX_ALLOC UINT32_C(0xb0)
#define HWRM_STAT_CTX_FREEUINT32_C(0xb1)
#define HWRM_STAT_CTX_QUERY UINT32_C(0xb2)
@@ -442,6 +443,14 @@ struct cmd_nums {
#define HWRM_FW_IPC_MSG UINT32_C(0x110)
#define HWRM_CFA_REDIRECT_TUNNEL_TYPE_INFOUINT32_C(0x111)
#define HWRM_CFA_REDIRECT_QUERY_TUNNEL_TYPE UINT32_C(0x112)
+ /* Experimental */
+ #define HWRM_CFA_FLOW_AGING_TIMER_RESET UINT32_C(0x113)
+ /* Experimental */
+ #define HWRM_CFA_FLOW_AGING_CFG UINT32_C(0x114)
+ /* Experimental */
+ #define HWRM_CFA_FLOW_AGING_QCFG UINT32_C(0x115)
+ /* Experimental */
+ #define HWRM_CFA_FLOW_AGING_QCAPS UINT32_C(0x116)
/* Engine CKV - Ping the device and SRT firmware to get the public key.
*/
#define HWRM_ENGINE_CKV_HELLO UINT32_C(0x12d)
/* Engine CKV - Get the current allocation status of keys provisioned
in the key vault. */
@@ -591,61 +600,79 @@ struct cmd_nums {
struct ret_codes {
uint16_terror_code;
/* Request was successfully executed by the HWRM. */
- #define HWRM_ERR_CODE_SUCCESSUINT32_C(0x0)
+ #define HWRM_ERR_CODE_SUCCESS UINT32_C(0x0)
/* The HWRM failed to execute the request. */
- #define HWRM_ERR_CODE_FAIL UINT32_C(0x1)
+ #define HWRM_ERR_CODE_FAIL UINT32_C(0x1)
/*
* The request contains invalid argument(s) or input
* parameters.
*/
- #define HWRM_ERR_CODE_INVALID_PARAMS UINT32_C(0x2)
+ #define HWRM_ERR_CODE_INVALID_PARAMSUINT32_C(0x2)
/*
* The requester is not allowed to access the requested
* resource. This error code shall be provided in a
* response to a request to query or modify an existing
* resource that is not accessible by the requester.
*/
- #define HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED UINT32_C(0x3)
+ #define HWRM_ERR_CODE_RESOURCE_ACCESS_DENIEDUINT32_C(0x3)
/*
* The HWRM is unable to allocate the requested resource.
* This code only applies to requests for HWRM resource
* allocations.
*/
- #define HWRM_ERR_CODE_RESOURCE_ALLOC_ERROR UINT32_C(0x4)
+ #define HWRM_ERR_CODE_RESOURCE_ALLOC_ERROR UINT32_C(0x4)
/*
* Invalid combination of flags is specified in the
* request.
*/
- #define HWRM_ERR_CODE_INVALID_FLAGS UINT32_C(0x5)
+ #define HWRM_ERR_CODE_INVALID_FLAGS UINT32_C(0x5)
/*
* Invalid combination of enables fields is specified in
* the request.
*/
- #define HWRM_ERR_CODE_INVALID_ENABLESUINT32_C(0x6)
+ #define HWRM_ERR_CODE_INVALID_ENABLES UINT32_C(0x6)
/*
* Request contains a required TLV that is not supported by
* the installed version of firmware.
*/
- #define HWRM_ERR_CODE_UNSUPPORTED_TLV
[dpdk-dev] [PATCH v2 08/10] net/bnxt: update HWRM version
From: Ajit Khaparde
Update HWRM version to 1.10.0.48
Signed-off-by: Ajit Khaparde
Reviewed-by: Lance Richardson
---
drivers/net/bnxt/hsi_struct_def_dpdk.h | 3156 +---
1 file changed, 2874 insertions(+), 282 deletions(-)
diff --git a/drivers/net/bnxt/hsi_struct_def_dpdk.h
b/drivers/net/bnxt/hsi_struct_def_dpdk.h
index ea9a7d40e..00a8ff87e 100644
--- a/drivers/net/bnxt/hsi_struct_def_dpdk.h
+++ b/drivers/net/bnxt/hsi_struct_def_dpdk.h
@@ -260,6 +260,7 @@ struct cmd_nums {
*/
uint16_treq_type;
#define HWRM_VER_GET UINT32_C(0x0)
+ #define HWRM_ERROR_RECOVERY_QCFG UINT32_C(0xc)
#define HWRM_FUNC_DRV_IF_CHANGE UINT32_C(0xd)
#define HWRM_FUNC_BUF_UNRGTR UINT32_C(0xe)
#define HWRM_FUNC_VF_CFG UINT32_C(0xf)
@@ -372,6 +373,8 @@ struct cmd_nums {
#define HWRM_STAT_CTX_QUERY UINT32_C(0xb2)
#define HWRM_STAT_CTX_CLR_STATS UINT32_C(0xb3)
#define HWRM_PORT_QSTATS_EXT UINT32_C(0xb4)
+ #define HWRM_PORT_PHY_MDIO_WRITE UINT32_C(0xb5)
+ #define HWRM_PORT_PHY_MDIO_READ UINT32_C(0xb6)
#define HWRM_FW_RESET UINT32_C(0xc0)
#define HWRM_FW_QSTATUS UINT32_C(0xc1)
#define HWRM_FW_HEALTH_CHECK UINT32_C(0xc2)
@@ -397,6 +400,8 @@ struct cmd_nums {
#define HWRM_WOL_FILTER_QCFG UINT32_C(0xf2)
#define HWRM_WOL_REASON_QCFG UINT32_C(0xf3)
/* Experimental */
+ #define HWRM_CFA_METER_QCAPS UINT32_C(0xf4)
+ /* Experimental */
#define HWRM_CFA_METER_PROFILE_ALLOC UINT32_C(0xf5)
/* Experimental */
#define HWRM_CFA_METER_PROFILE_FREE UINT32_C(0xf6)
@@ -407,6 +412,8 @@ struct cmd_nums {
/* Experimental */
#define HWRM_CFA_METER_INSTANCE_FREE UINT32_C(0xf9)
/* Experimental */
+ #define HWRM_CFA_METER_INSTANCE_CFG UINT32_C(0xfa)
+ /* Experimental */
#define HWRM_CFA_VFR_ALLOCUINT32_C(0xfd)
/* Experimental */
#define HWRM_CFA_VFR_FREE UINT32_C(0xfe)
@@ -451,6 +458,34 @@ struct cmd_nums {
#define HWRM_CFA_FLOW_AGING_QCFG UINT32_C(0x115)
/* Experimental */
#define HWRM_CFA_FLOW_AGING_QCAPS UINT32_C(0x116)
+ /* Experimental */
+ #define HWRM_CFA_CTX_MEM_RGTR UINT32_C(0x117)
+ /* Experimental */
+ #define HWRM_CFA_CTX_MEM_UNRGTR UINT32_C(0x118)
+ /* Experimental */
+ #define HWRM_CFA_CTX_MEM_QCTX UINT32_C(0x119)
+ /* Experimental */
+ #define HWRM_CFA_CTX_MEM_QCAPSUINT32_C(0x11a)
+ /* Experimental */
+ #define HWRM_CFA_COUNTER_QCAPSUINT32_C(0x11b)
+ /* Experimental */
+ #define HWRM_CFA_COUNTER_CFG UINT32_C(0x11c)
+ /* Experimental */
+ #define HWRM_CFA_COUNTER_QCFG UINT32_C(0x11d)
+ /* Experimental */
+ #define HWRM_CFA_COUNTER_QSTATS UINT32_C(0x11e)
+ /* Experimental */
+ #define HWRM_CFA_TCP_FLAG_PROCESS_QCFGUINT32_C(0x11f)
+ /* Experimental */
+ #define HWRM_CFA_EEM_QCAPSUINT32_C(0x120)
+ /* Experimental */
+ #define HWRM_CFA_EEM_CFG UINT32_C(0x121)
+ /* Experimental */
+ #define HWRM_CFA_EEM_QCFG UINT32_C(0x122)
+ /* Experimental */
+ #define HWRM_CFA_EEM_OP UINT32_C(0x123)
+ /* Experimental */
+ #define HWRM_CFA_ADV_FLOW_MGNT_QCAPS UINT32_C(0x124)
/* Engine CKV - Ping the device and SRT firmware to get the public key.
*/
#define HWRM_ENGINE_CKV_HELLO UINT32_C(0x12d)
/* Engine CKV - Get the current allocation status of keys provisioned
in the key vault. */
@@ -469,6 +504,8 @@ struct cmd_nums {
#define HWRM_ENGINE_CKV_RNG_GET UINT32_C(0x134)
/* Engine CKV - Generate and encrypt a new AES key. */
#define HWRM_ENGINE_CKV_KEY_GEN UINT32_C(0x135)
+ /* Engine CKV - Configure a label index with a label value. */
+ #define HWRM_ENGINE_CKV_KEY_LABEL_CFG UINT32_C(0x136)
/* Engine - Query the available queue groups configuration. */
#define HWRM_ENGINE_QG_CONFIG_QUERY UINT32_C(0x13c)
/* Engine - Query the queue groups assigned to a function. */
@@ -523,6 +560,8 @@ struct cmd_nums {
#def
[dpdk-dev] [PATCH v2 10/10] net/bnxt: update release notes for bnxt
From: Ajit Khaparde Update release doc briefly describing updates to bnxt PMD. Signed-off-by: Ajit Khaparde --- doc/guides/rel_notes/release_19_08.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst index b9510f93a..2ff9d4b1c 100644 --- a/doc/guides/rel_notes/release_19_08.rst +++ b/doc/guides/rel_notes/release_19_08.rst @@ -54,6 +54,12 @@ New Features Also, make sure to start the actual text at the margin. = +* **Updated the bnxt PMD.** + + Updated the bnxt PMD. The major enhancements include: + * Update HWRM version to 1.10.74 + * Added vector RX/TX + * Performance optimizations in non-vector Tx path Removed Items - -- 2.17.1
[dpdk-dev] [PATCH v2 09/10] net/bnxt: HWRM version update
From: Ajit Khaparde
Update HWRM API to version 1.10.0.74
Signed-off-by: Ajit Khaparde
Reviewed-by: Lance Richardson
---
drivers/net/bnxt/hsi_struct_def_dpdk.h | 1399
1 file changed, 1168 insertions(+), 231 deletions(-)
diff --git a/drivers/net/bnxt/hsi_struct_def_dpdk.h
b/drivers/net/bnxt/hsi_struct_def_dpdk.h
index 00a8ff87e..305ee09bc 100644
--- a/drivers/net/bnxt/hsi_struct_def_dpdk.h
+++ b/drivers/net/bnxt/hsi_struct_def_dpdk.h
@@ -1,5 +1,5 @@
/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright (c) 2014-2019 Broadcom Limited
+ * Copyright (c) 2014-2019 Broadcom Inc.
* All rights reserved.
*
* DO NOT MODIFY!!! This file is automatically generated.
@@ -27,7 +27,8 @@ struct hwrm_cmd_hdr {
/*
* The target ID of the command:
* * 0x0-0xFFF8 - The function ID
-* * 0xFFF8-0xFFFE - Reserved for internal processors
+* * 0xFFF8-0xFFFC, 0xFFFE - Reserved for internal processors
+* * 0xFFFD - Reserved for user-space HWRM interface
* * 0x - HWRM
*/
uint16_ttarget_id;
@@ -221,8 +222,14 @@ struct hwrm_short_input {
#define HWRM_SHORT_INPUT_SIGNATURE_SHORT_CMD UINT32_C(0x4321)
#define HWRM_SHORT_INPUT_SIGNATURE_LAST \
HWRM_SHORT_INPUT_SIGNATURE_SHORT_CMD
- /* Reserved for future use. */
- uint16_tunused_0;
+ /* The target ID of the command */
+ uint16_ttarget_id;
+ /* Default target_id (0x0) to maintain compatibility with old driver */
+ #define HWRM_SHORT_INPUT_TARGET_ID_DEFAULT UINT32_C(0x0)
+ /* Reserved for user-space HWRM interface */
+ #define HWRM_SHORT_INPUT_TARGET_ID_TOOLS UINT32_C(0xfffd)
+ #define HWRM_SHORT_INPUT_TARGET_ID_LAST \
+ HWRM_SHORT_INPUT_TARGET_ID_TOOLS
/* This value indicates the length of the request. */
uint16_tsize;
/*
@@ -394,6 +401,8 @@ struct cmd_nums {
#define HWRM_FWD_RESP UINT32_C(0xd2)
#define HWRM_FWD_ASYNC_EVENT_CMPL UINT32_C(0xd3)
#define HWRM_OEM_CMD UINT32_C(0xd4)
+ /* Tells the fw to run PRBS test on a given port and lane. */
+ #define HWRM_PORT_PRBS_TEST UINT32_C(0xd5)
#define HWRM_TEMP_MONITOR_QUERY UINT32_C(0xe0)
#define HWRM_WOL_FILTER_ALLOC UINT32_C(0xf0)
#define HWRM_WOL_FILTER_FREE UINT32_C(0xf1)
@@ -486,6 +495,8 @@ struct cmd_nums {
#define HWRM_CFA_EEM_OP UINT32_C(0x123)
/* Experimental */
#define HWRM_CFA_ADV_FLOW_MGNT_QCAPS UINT32_C(0x124)
+ /* Experimental */
+ #define HWRM_CFA_TFLIBUINT32_C(0x125)
/* Engine CKV - Ping the device and SRT firmware to get the public key.
*/
#define HWRM_ENGINE_CKV_HELLO UINT32_C(0x12d)
/* Engine CKV - Get the current allocation status of keys provisioned
in the key vault. */
@@ -506,6 +517,8 @@ struct cmd_nums {
#define HWRM_ENGINE_CKV_KEY_GEN UINT32_C(0x135)
/* Engine CKV - Configure a label index with a label value. */
#define HWRM_ENGINE_CKV_KEY_LABEL_CFG UINT32_C(0x136)
+ /* Engine CKV - Query a label */
+ #define HWRM_ENGINE_CKV_KEY_LABEL_QCFGUINT32_C(0x137)
/* Engine - Query the available queue groups configuration. */
#define HWRM_ENGINE_QG_CONFIG_QUERY UINT32_C(0x13c)
/* Engine - Query the queue groups assigned to a function. */
@@ -587,6 +600,19 @@ struct cmd_nums {
/* Experimental */
#define HWRM_PCIE_QSTATS UINT32_C(0x204)
/* Experimental */
+ #define HWRM_MFG_FRU_WRITE_CONTROLUINT32_C(0x205)
+ /* Returns the current value of a free running counter from the device.
*/
+ #define HWRM_MFG_TIMERS_QUERY UINT32_C(0x206)
+ /* Experimental */
+ #define HWRM_MFG_OTP_CFG UINT32_C(0x207)
+ /* Experimental */
+ #define HWRM_MFG_OTP_QCFG UINT32_C(0x208)
+ /*
+* Tells the fw to run the DMA read from the host and DMA write
+* to the host test.
+*/
+ #define HWRM_MFG_HDMA_TESTUINT32_C(0x209)
+ /* Experimental */
#define HWRM_DBG_READ_DIRECT UINT32_C(0xff10)
/* Experimental */
#define HWRM_DBG_READ_INDIRECTUINT32_C(0xff11)
@@ -643,67 +669,85 @@ struct cmd_nums {
struct ret_codes {
uint16_terror_code;
/* Request was successfully executed by the HWRM. */
- #define HWRM_ERR_CODE_SUCCESS UINT32_C(0x0)
+ #define HWRM_ERR_CODE_SUCCESS
[dpdk-dev] [PATCH] net: fix encapsulation markers for inner L3 offset
The API to prepare checksum offloads employs outer
IP checksum flag to tell regular IPv4 packets from
tunnel packets with outer IPv4 encapsulation. This
flag cannot serve as a marker for the said purpose
because a packet can have outer IPv4 encapsulation
and may not have outer IP checksum offload request.
Fix the API by changing the said criterion to test
outer IPv4 flag rather than outer IP checksum flag.
Use simpler spelling of the conditional expression.
Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
Cc: Tomasz Kulasek
Cc: sta...@dpdk.org
Signed-off-by: Ivan Malov
Reviewed-by: Andrew Rybchenko
---
lib/librte_net/rte_net.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/librte_net/rte_net.h b/lib/librte_net/rte_net.h
index 1697071..c15b518 100644
--- a/lib/librte_net/rte_net.h
+++ b/lib/librte_net/rte_net.h
@@ -128,8 +128,7 @@ uint32_t rte_net_get_ptype(const struct rte_mbuf *m,
return 0;
#endif
- if ((ol_flags & PKT_TX_OUTER_IP_CKSUM) ||
- (ol_flags & PKT_TX_OUTER_IPV6))
+ if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6))
inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
#ifdef RTE_LIBRTE_ETHDEV_DEBUG
--
1.8.3.1
[dpdk-dev] [PATCH v2] net/mlx4: use dynamic log type
From: Stephen Hemminger
This driver should use dynamic log level not RTE_LOGTYPE_PMD.
Other drivers were converted back in 18.02.
This is really a bug, all other drivers use dynamic log levels
by now.
Signed-off-by: Stephen Hemminger
---
v2 - use rte_log and fix debug logs
drivers/net/mlx4/mlx4.c | 8
drivers/net/mlx4/mlx4_utils.h | 6 --
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index fe559c040706..e532dc53738f 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -60,6 +60,9 @@ static rte_spinlock_t mlx4_shared_data_lock =
RTE_SPINLOCK_INITIALIZER;
/* Process local data for secondary processes. */
static struct mlx4_local_data mlx4_local_data;
+/** Driver-specific log messages type. */
+int mlx4_logtype;
+
/** Configuration structure for device arguments. */
struct mlx4_conf {
struct {
@@ -1272,6 +1275,11 @@ mlx4_glue_init(void)
*/
RTE_INIT(rte_mlx4_pmd_init)
{
+ /* Initialize driver log type. */
+ mlx4_logtype = rte_log_register("pmd.net.mlx4");
+ if (mlx4_logtype >= 0)
+ rte_log_set_level(mlx4_logtype, RTE_LOG_NOTICE);
+
/*
* MLX4_DEVICE_FATAL_CLEANUP tells ibv_destroy functions we
* want to get success errno value in case of calling them
diff --git a/drivers/net/mlx4/mlx4_utils.h b/drivers/net/mlx4/mlx4_utils.h
index 86abb3b7e376..a49190252fe1 100644
--- a/drivers/net/mlx4/mlx4_utils.h
+++ b/drivers/net/mlx4/mlx4_utils.h
@@ -15,6 +15,8 @@
#include "mlx4.h"
+extern int mlx4_logtype;
+
#ifndef NDEBUG
/*
@@ -35,7 +37,7 @@ pmd_drv_log_basename(const char *s)
}
#define PMD_DRV_LOG(level, ...) \
- RTE_LOG(level, PMD, \
+ rte_log(RTE_LOG_ ## level, mlx4_logtype, \
RTE_FMT("%s:%u: %s(): " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
pmd_drv_log_basename(__FILE__), \
__LINE__, \
@@ -52,7 +54,7 @@ pmd_drv_log_basename(const char *s)
*/
#define PMD_DRV_LOG(level, ...) \
- RTE_LOG(level, PMD, \
+ rte_log(RTE_LOG_ ## level, mlx4_logtype, \
RTE_FMT(MLX4_DRIVER_NAME ": " \
RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
RTE_FMT_TAIL(__VA_ARGS__,)))
--
2.20.1
[dpdk-dev] [PATCH] meson: Update flags and values for ppc_64
Setting RTE_MAX_LCORE to reflect the largest available configuration.
Adding defines for missing RTE_MACHINE_CPUFLAGs.
Signed-off-by: David Wilder
---
config/ppc_64/meson.build | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/config/ppc_64/meson.build b/config/ppc_64/meson.build
index 7ceae1d..0e65f9d 100644
--- a/config/ppc_64/meson.build
+++ b/config/ppc_64/meson.build
@@ -8,6 +8,8 @@ dpdk_conf.set('RTE_ARCH', 'ppc_64')
dpdk_conf.set('RTE_ARCH_PPC_64', 1)
# overrides specific to ppc64
-dpdk_conf.set('RTE_MAX_LCORE', 256)
+dpdk_conf.set('RTE_MAX_LCORE', 1536)
dpdk_conf.set('RTE_MAX_NUMA_NODES', 32)
dpdk_conf.set('RTE_CACHE_LINE_SIZE', 128)
+dpdk_conf.set('RTE_MACHINE_CPUFLAG_ALTIVEC', 1)
+dpdk_conf.set('RTE_MACHINE_CPUFLAG_VSX', 1)
--
1.8.3.1
Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
On Fri, 24 May 2019 14:26:40 +0100
Ferruh Yigit wrote:
> On 5/23/2019 11:01 PM, Stephen Hemminger wrote:
> > Several users have run into problems where the MLX drivers were not
> > enabled in their build. And then trying to run their DPDK
> > application on Azure. What happens is that all packets
> > go over the slow path, and failsafe repeatedly probes for never
> > existing sub-device.
> >
> > Both Mellanox drivers should be checked. MLX4 for current versions,
> > and MLX5 for future upgrades. This code is only called if Hyper-V/Azure
> > is detected.
> >
> > Signed-off-by: Stephen Hemminger
> > ---
> > drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > index 801f54c96e01..64f9dbf66e18 100644
> > --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > @@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
> > struct rte_devargs *devargs;
> > struct rte_bus *vbus = rte_bus_find_by_name("vdev");
> >
> > +#ifndef RTE_LIBRTE_MLX4_PMD
> > + DRV_LOG(WARNING, "Mellanox MLX4 not configured.");
> > +#endif
> > +#ifndef RTE_LIBRTE_MLX5_PMD
> > + DRV_LOG(WARNING, "Mellanox MLX5 not configured.");
> > +#endif
>
> Is it OK a virtual PMD being this much aware of another PMD?
> Can it be an option to add this check into build system? And if there is
> direct
> dependency perhaps even don't compile the 'vdev_netvsc' when none mlx PMD is
> enabled.
vdev_netvsc is not a device, it is really just a hack to start other
device drivers on Hyper-V/Azure. If the build system supported dependencies
(like Linux kbuild) this would not be necessary. Meson only does dynamic
dependencies
so that doesn't help.
This is a warning and not fatal only because application will still at
least run, and somebody may want to run with SR-IOV with Intel NIC's on Hyper-V.
The warning is just to give users better immediate feedback rather than
trying to diagnose poor performance or mystery device not found messages.
Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
24/05/2019 18:07, Stephen Hemminger:
> On Fri, 24 May 2019 14:26:40 +0100
> Ferruh Yigit wrote:
>
> > On 5/23/2019 11:01 PM, Stephen Hemminger wrote:
> > > Several users have run into problems where the MLX drivers were not
> > > enabled in their build. And then trying to run their DPDK
> > > application on Azure. What happens is that all packets
> > > go over the slow path, and failsafe repeatedly probes for never
> > > existing sub-device.
> > >
> > > Both Mellanox drivers should be checked. MLX4 for current versions,
> > > and MLX5 for future upgrades. This code is only called if Hyper-V/Azure
> > > is detected.
> > >
> > > Signed-off-by: Stephen Hemminger
> > > ---
> > > drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > index 801f54c96e01..64f9dbf66e18 100644
> > > --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > @@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
> > > struct rte_devargs *devargs;
> > > struct rte_bus *vbus = rte_bus_find_by_name("vdev");
> > >
> > > +#ifndef RTE_LIBRTE_MLX4_PMD
> > > + DRV_LOG(WARNING, "Mellanox MLX4 not configured.");
> > > +#endif
> > > +#ifndef RTE_LIBRTE_MLX5_PMD
> > > + DRV_LOG(WARNING, "Mellanox MLX5 not configured.");
> > > +#endif
> >
> > Is it OK a virtual PMD being this much aware of another PMD?
> > Can it be an option to add this check into build system? And if there is
> > direct
> > dependency perhaps even don't compile the 'vdev_netvsc' when none mlx PMD is
> > enabled.
>
> vdev_netvsc is not a device, it is really just a hack to start other
> device drivers on Hyper-V/Azure. If the build system supported dependencies
> (like Linux kbuild) this would not be necessary. Meson only does dynamic
> dependencies
> so that doesn't help.
>
> This is a warning and not fatal only because application will still at
> least run, and somebody may want to run with SR-IOV with Intel NIC's on
> Hyper-V.
>
>
> The warning is just to give users better immediate feedback rather than
> trying to diagnose poor performance or mystery device not found messages.
It really looks strange to me.
What you need is to fail at compilation if requested PMD is not built.
I would advise to work on a script to configure meson.
Re: [dpdk-dev] [dpdk-stable] 18.11.2 (LTS) patches review and test
Hi Kevin- I tested 8.11.2 RC1 on IBM Power9 hardware. No issues or performance degradation were observed. Tests run: * Single port stability test using l3fwd (16 cpus) and TRex, tested 64 and 1500 byte packets at a 0.0% drop rate for 4 hours each. System tested: - IBM Power9 Model 8335-101 CPU: 2.3 (pvr 004e 1203) Tested NICs: - ConnectX-5 (fw 16.23.1020). OS Tested - Ubuntu 18.04.2 LTS (kernel 4.15.0-47-generic) Regards, Dave On 2019-05-21 07:01, Kevin Traynor wrote: Hi all, Here is a list of patches targeted for LTS release 18.11.2. The planned date for the final release is 11th June. Please help with testing and validation of your use cases and report any issues/results. For the final release I will update the release notes with fixes and reported validations. A release candidate tarball can be found at: https://urldefense.proofpoint.com/v2/url?u=https-3A__dpdk.org_browse_dpdk-2Dstable_tag_-3Fid-3Dv18.11.2-2Drc1&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=7ndxyKjH9UrBD68Us2WP1wI4BwEBQbeAyz8i_vwCCaI&m=_uELDTGd8N4r6nMedCtB7BZ7smk16u_gOekVjKO__nM&s=A2p-8kC3tA0EjBPnJwZ03RdD9-qTfAkg2Z135xdJ78k&e= These patches are located at branch 18.11 of dpdk-stable repo: https://urldefense.proofpoint.com/v2/url?u=https-3A__dpdk.org_browse_dpdk-2Dstable_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=7ndxyKjH9UrBD68Us2WP1wI4BwEBQbeAyz8i_vwCCaI&m=_uELDTGd8N4r6nMedCtB7BZ7smk16u_gOekVjKO__nM&s=wxF_Eze1ZxjaJ6I_lQ9_wT9IafwwECHlKcDIEIgkGP8&e= Thanks. Kevin Traynor --- Aaron Conole (4): net/virtio: fix dangling pointer on failure ci: enable ccache in Travis ci: add a distinguisher to the extra Travis builds ipc: unlock on failure Abhinandan Gujjar (1): eventdev: fix crypto adapter Agalya Babu RadhaKrishnan (2): doc: fix interactive commands in testpmd guide app/testpmd: fix help info for interactive commands Akhil Goyal (3): crypto/dpaa2_sec: fix session clearing crypto/dpaa2_sec: fix offset calculation for GCM crypto/dpaa: fix session destroy Alejandro Lucero (5): net/nfp: fix RSS query net/nfp: fix file descriptor check net/nfp: fix potential integer overflow net/nfp: check return value net/nfp: fix memory leak Anatoly Burakov (11): malloc: fix documentation of realloc function vfio: document multiprocess limitation for container API malloc: fix IPC message initialization mem: warn user when running without NUMA support eal: fix cleanup in no-shconf mode ipc: fix send error handling ipc: harden message receive ipc: handle more invalid parameter cases doc: fix typo in IPC guide ipc: add warnings about not using IPC with memory API ipc: add warnings about correct API usage Andrew Rybchenko (3): net/sfc: remove control path logging from Rx queue count net/sfc: fix logging from secondary process net/sfc: fix speed capabilities reported in device info Andrius Sirvys (4): drivers/net: fix shifting 32-bit signed variable 31 times acl: fix compiler flags with meson and AVX2 runtime net/virtio: fix duplicate naming of include guard bitrate: fix unchecked return value Andy Pei (1): raw/ifpga: modify log output Anoob Joseph (2): common/cpt: fix null auth only cryptodev: fix driver name comparison Arek Kusztal (2): crypto/openssl: fix big numbers after computations crypto/openssl: fix modexp Beilei Xing (2): net/i40e: fix logging on VF close net/i40e: fix link speed for X722 Bernard Iremonger (1): examples/ipsec-secgw: fix debug logs Bill Hong (1): net: fix Tx VLAN flag for offload emulation Bruce Richardson (24): test/compress: fix missing header include examples/ip_pipeline: disable build when no epoll examples/vhost_crypto: fix dependency on vhost library devtools: fix build test on FreeBSD eal: support strlcat function telemetry: fix mapping of statistics eal: tighten permissions on shared memory files net/bonding: fix buffer length when printing strings devtools: skip meson build for missing compilers devtools: support older compilers with meson test examples/l2fwd-cat: fix build on FreeBSD app/crypto-perf: check range of socket id examples/vhost_scsi: fix null-check for parameter net/i40e: fix dereference before null check in mbuf release net/i40e: fix dereference before check when getting EEPROM app/testpmd: fix variable use before null check crypto/snow3g: add to meson build crypto/kasumi: fix dependency check crypto/zuc: fix dependency check net/ixgbe: fix warning with GCC 9 bus/fslmc: fix warning with GCC 9 raw/skeleton: fix warnings with GCC 9 raw/dpaa2_cmdif: fix warnings with GCC 9 build: fix ninja install on FreeBSD Chaitanya Babu Talluri (3): drivers/net: fix possible overflow using strlcat test/cr
Re: [dpdk-dev] [PATCH] kni: remove ethtool support
On Fri, 24 May 2019 17:29:22 +0100 Ferruh Yigit wrote: > From: Thomas Monjalon > > Current design requires kernel drivers and they need to be probed by > Linux up to some level so that they can be usable by DPDK for ethtool > support, this requires maintaining the Linux drivers in DPDK. > > Also ethtool support is limited and hard, if not impossible, to expand > to other PMDs. > > Since KNI ethtool support is not used commonly, if not used at all, > removing the support for the sake of simplicity and maintenance. > > Signed-off-by: Ferruh Yigit Acked-by: Stephen Hemminger
Re: [dpdk-dev] [PATCH] kni: remove ethtool support
On 5/24/2019 5:29 PM, Ferruh Yigit wrote: > From: Thomas Monjalon I don't know what I did wrong to manage this, I am sending a new version. > > Current design requires kernel drivers and they need to be probed by > Linux up to some level so that they can be usable by DPDK for ethtool > support, this requires maintaining the Linux drivers in DPDK. > > Also ethtool support is limited and hard, if not impossible, to expand > to other PMDs. > > Since KNI ethtool support is not used commonly, if not used at all, > removing the support for the sake of simplicity and maintenance. > > Signed-off-by: Ferruh Yigit > --- > Cc: Igor Ryzhov > Cc: Stephen Hemminger <...>
Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
On Fri, 24 May 2019 18:38:53 +0200
Thomas Monjalon wrote:
> 24/05/2019 18:07, Stephen Hemminger:
> > On Fri, 24 May 2019 14:26:40 +0100
> > Ferruh Yigit wrote:
> >
> > > On 5/23/2019 11:01 PM, Stephen Hemminger wrote:
> > > > Several users have run into problems where the MLX drivers were not
> > > > enabled in their build. And then trying to run their DPDK
> > > > application on Azure. What happens is that all packets
> > > > go over the slow path, and failsafe repeatedly probes for never
> > > > existing sub-device.
> > > >
> > > > Both Mellanox drivers should be checked. MLX4 for current versions,
> > > > and MLX5 for future upgrades. This code is only called if Hyper-V/Azure
> > > > is detected.
> > > >
> > > > Signed-off-by: Stephen Hemminger
> > > > ---
> > > > drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++
> > > > 1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > index 801f54c96e01..64f9dbf66e18 100644
> > > > --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > @@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
> > > > struct rte_devargs *devargs;
> > > > struct rte_bus *vbus = rte_bus_find_by_name("vdev");
> > > >
> > > > +#ifndef RTE_LIBRTE_MLX4_PMD
> > > > + DRV_LOG(WARNING, "Mellanox MLX4 not configured.");
> > > > +#endif
> > > > +#ifndef RTE_LIBRTE_MLX5_PMD
> > > > + DRV_LOG(WARNING, "Mellanox MLX5 not configured.");
> > > > +#endif
> > >
> > > Is it OK a virtual PMD being this much aware of another PMD?
> > > Can it be an option to add this check into build system? And if there is
> > > direct
> > > dependency perhaps even don't compile the 'vdev_netvsc' when none mlx PMD
> > > is
> > > enabled.
> >
> > vdev_netvsc is not a device, it is really just a hack to start other
> > device drivers on Hyper-V/Azure. If the build system supported dependencies
> > (like Linux kbuild) this would not be necessary. Meson only does dynamic
> > dependencies
> > so that doesn't help.
> >
> > This is a warning and not fatal only because application will still at
> > least run, and somebody may want to run with SR-IOV with Intel NIC's on
> > Hyper-V.
> >
> >
> > The warning is just to give users better immediate feedback rather than
> > trying to diagnose poor performance or mystery device not found messages.
>
>
> It really looks strange to me.
> What you need is to fail at compilation if requested PMD is not built.
> I would advise to work on a script to configure meson.
None of the people that ran into this were using meson build.
For example, VPP doesn't use meson.
Re: [dpdk-dev] [dpdk-stable] 18.11.2 (LTS) patches review and test
On 24/05/2019 17:46, dwilder wrote: > Hi Kevin- > > I tested 8.11.2 RC1 on IBM Power9 hardware. No issues or performance > degradation were observed. > Thanks David. Good news on a Friday is always welcome :-) > Tests run: > * Single port stability test using l3fwd (16 cpus) and TRex, tested 64 > and 1500 byte packets at a 0.0% drop rate for 4 hours each. > > System tested: > - IBM Power9 Model 8335-101 CPU: 2.3 (pvr 004e 1203) > > Tested NICs: > - ConnectX-5 (fw 16.23.1020). > > OS Tested > - Ubuntu 18.04.2 LTS (kernel 4.15.0-47-generic) > I will add it to the release notes, thanks, Kevin. > Regards, > Dave
Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
24/05/2019 18:48, Stephen Hemminger:
> On Fri, 24 May 2019 18:38:53 +0200
> Thomas Monjalon wrote:
> > 24/05/2019 18:07, Stephen Hemminger:
> > > On Fri, 24 May 2019 14:26:40 +0100
> > > Ferruh Yigit wrote:
> > >
> > > > On 5/23/2019 11:01 PM, Stephen Hemminger wrote:
> > > > > Several users have run into problems where the MLX drivers were not
> > > > > enabled in their build. And then trying to run their DPDK
> > > > > application on Azure. What happens is that all packets
> > > > > go over the slow path, and failsafe repeatedly probes for never
> > > > > existing sub-device.
> > > > >
> > > > > Both Mellanox drivers should be checked. MLX4 for current versions,
> > > > > and MLX5 for future upgrades. This code is only called if
> > > > > Hyper-V/Azure
> > > > > is detected.
> > > > >
> > > > > Signed-off-by: Stephen Hemminger
> > > > > ---
> > > > > drivers/net/vdev_netvsc/vdev_netvsc.c | 7 +++
> > > > > 1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > > b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > > index 801f54c96e01..64f9dbf66e18 100644
> > > > > --- a/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > > +++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
> > > > > @@ -812,6 +812,13 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
> > > > > struct rte_devargs *devargs;
> > > > > struct rte_bus *vbus = rte_bus_find_by_name("vdev");
> > > > >
> > > > > +#ifndef RTE_LIBRTE_MLX4_PMD
> > > > > + DRV_LOG(WARNING, "Mellanox MLX4 not configured.");
> > > > > +#endif
> > > > > +#ifndef RTE_LIBRTE_MLX5_PMD
> > > > > + DRV_LOG(WARNING, "Mellanox MLX5 not configured.");
> > > > > +#endif
> > > >
> > > > Is it OK a virtual PMD being this much aware of another PMD?
> > > > Can it be an option to add this check into build system? And if there
> > > > is direct
> > > > dependency perhaps even don't compile the 'vdev_netvsc' when none mlx
> > > > PMD is
> > > > enabled.
> > >
> > > vdev_netvsc is not a device, it is really just a hack to start other
> > > device drivers on Hyper-V/Azure. If the build system supported
> > > dependencies
> > > (like Linux kbuild) this would not be necessary. Meson only does dynamic
> > > dependencies
> > > so that doesn't help.
> > >
> > > This is a warning and not fatal only because application will still at
> > > least run, and somebody may want to run with SR-IOV with Intel NIC's on
> > > Hyper-V.
> > >
> > >
> > > The warning is just to give users better immediate feedback rather than
> > > trying to diagnose poor performance or mystery device not found messages.
> > >
> >
> >
> > It really looks strange to me.
> > What you need is to fail at compilation if requested PMD is not built.
> > I would advise to work on a script to configure meson.
>
> None of the people that ran into this were using meson build.
> For example, VPP doesn't use meson.
They will use meson when makefile will be removed :)
Anyway, no matter the build system, what we want is a way
to guide users to a proper DPDK installation.
Your solution is to add some very specific logs.
My proposal is to guide the user with a script and some
specific parameters so it will fail if a required dependency is not met.
Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
On Fri, 24 May 2019 19:05:20 +0200 Thomas Monjalon wrote: > > > > device drivers on Hyper-V/Azure. If the build system supported > > > > dependencies > > > > (like Linux kbuild) this would not be necessary. Meson only does > > > > dynamic dependencies > > > > so that doesn't help. > > > > > > > > This is a warning and not fatal only because application will still at > > > > least run, and somebody may want to run with SR-IOV with Intel NIC's on > > > > Hyper-V. > > > > > > > > > > > > The warning is just to give users better immediate feedback rather than > > > > trying to diagnose poor performance or mystery device not found > > > > messages. > > > > > > > > > It really looks strange to me. > > > What you need is to fail at compilation if requested PMD is not built. > > > I would advise to work on a script to configure meson. > > > > None of the people that ran into this were using meson build. > > For example, VPP doesn't use meson. > > They will use meson when makefile will be removed :) > > Anyway, no matter the build system, what we want is a way > to guide users to a proper DPDK installation. > Your solution is to add some very specific logs. > My proposal is to guide the user with a script and some > specific parameters so it will fail if a required dependency is not met. Not familiar enough with meson magic syntax to make vdev_netvsc not build without MLX. But that would just be pushing the mystery failure further down the road. Another alternative would be to drop vdev_netvsc from the default Linux build. That way users would have to enable it manually. My preferred solution would be to just kill vdev_netvsc and go to only netvsc PMD but that is a couple releases away.
Re: [dpdk-dev] [PATCH v2] net/mlx4: use dynamic log type
On 5/24/2019 5:03 PM, Stephen Hemminger wrote: > From: Stephen Hemminger > > This driver should use dynamic log level not RTE_LOGTYPE_PMD. > Other drivers were converted back in 18.02. > > This is really a bug, all other drivers use dynamic log levels > by now. > > Signed-off-by: Stephen Hemminger Reviewed-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
24/05/2019 19:11, Stephen Hemminger: > On Fri, 24 May 2019 19:05:20 +0200 > Thomas Monjalon wrote: > > > > > > device drivers on Hyper-V/Azure. If the build system supported > > > > > dependencies > > > > > (like Linux kbuild) this would not be necessary. Meson only does > > > > > dynamic dependencies > > > > > so that doesn't help. > > > > > > > > > > This is a warning and not fatal only because application will still at > > > > > least run, and somebody may want to run with SR-IOV with Intel NIC's > > > > > on Hyper-V. > > > > > > > > > > > > > > > The warning is just to give users better immediate feedback rather > > > > > than > > > > > trying to diagnose poor performance or mystery device not found > > > > > messages. > > > > > > > > > > > > It really looks strange to me. > > > > What you need is to fail at compilation if requested PMD is not built. > > > > I would advise to work on a script to configure meson. > > > > > > None of the people that ran into this were using meson build. > > > For example, VPP doesn't use meson. > > > > They will use meson when makefile will be removed :) > > > > Anyway, no matter the build system, what we want is a way > > to guide users to a proper DPDK installation. > > Your solution is to add some very specific logs. > > My proposal is to guide the user with a script and some > > specific parameters so it will fail if a required dependency is not met. > > Not familiar enough with meson magic syntax to make vdev_netvsc not build > without MLX. But that would just be pushing the mystery failure further > down the road. I think you did not understand my proposal. Let's take an example. You give this instruction to build DPDK: buildtools/build-require.sh vdev_netvsc mlx4 If mlx4 is not built then it will fail with this message: librte_pmd_mlx4 failed to build So the user knows what went wrong. No mystery. > Another alternative would be to drop vdev_netvsc from the default Linux > build. That way users would have to enable it manually. > > My preferred solution would be to just kill vdev_netvsc and go to only netvsc > PMD > but that is a couple releases away.
Re: [dpdk-dev] [PATCH 3/3] net/i40e: fix inadvertent override of vector RX allowance
Hi, > > > > i40e_rx_vec_dev_conf_condition_check_default(struct rte_eth_dev *dev) > > > > if (rxmode->offloads & DEV_RX_OFFLOAD_VLAN_EXTEND) > > > > return -1; > > > > > > > > + /* Should not override if vector was already disallowed */ > > > > > > It is possible a device be reconfigured between dev_stop/dev_start, > > > vector mode may fit for the new configure, so the old rx_vec_allowd > > > should be ignored, > > > > > > > i40e_dev_configure would reset rx_vec_allowed already. Am I missing another > > reconfiguration path? > > Look at below scenario, > > 1. dev_configure (rx_vec_allowed is reset to true) > 2. queue_setup (the ring size is not power of 2) > 3. dev_start (vector will not be selected due to ring size, rx_vec_allowed > set to > false) > 4. dev_stop > 5. queue_setup (this time, with power of 2 ring size) > 6. dev_start (assume vector path should be selected, and rx_vec_allowed should > be overwrite to true, but your patch will prevent it) > > Also, I may not get the point of the gap you observed, would you share more > detail scenario? > > Regards > Qi It seems like queue setup should reset vector_allowed flag, too. Because i40e_dev_rx_queue_setup_runtime is already doing it, though covering only half of the state space (i.e. device already started). Do you think this patch plus that would be a preferred approach? > > > > > Mesut > > > > > Regards > > > Qi > > > > > > > + if (!ad->rx_vec_allowed) > > > > + return -1; > > > > + > > > > /** > > > > * Vector mode is allowed only when number of Rx queue > > > > * descriptor is power of 2. > > > > -- > > > > 2.7.4
Re: [dpdk-dev] [PATCH v2] kni: remove ethtool support
On Fri, May 24, 2019 at 05:55:20PM +0100, Ferruh Yigit wrote: > Current design requires kernel drivers and they need to be probed by > Linux up to some level so that they can be usable by DPDK for ethtool > support, this requires maintaining the Linux drivers in DPDK. > > Also ethtool support is limited and hard, if not impossible, to expand > to other PMDs. > > Since KNI ethtool support is not used commonly, if not used at all, > removing the support for the sake of simplicity and maintenance. > > Signed-off-by: Ferruh Yigit > Acked-by: Stephen Hemminger Acked-by: Neil Horman
Re: [dpdk-dev] [PATCH] net/vdev_netvsc: print warning if Mellanox devices are not configured
On Fri, 24 May 2019 19:32:14 +0200 Thomas Monjalon wrote: > 24/05/2019 19:11, Stephen Hemminger: > > On Fri, 24 May 2019 19:05:20 +0200 > > Thomas Monjalon wrote: > > > > > > > > device drivers on Hyper-V/Azure. If the build system supported > > > > > > dependencies > > > > > > (like Linux kbuild) this would not be necessary. Meson only does > > > > > > dynamic dependencies > > > > > > so that doesn't help. > > > > > > > > > > > > This is a warning and not fatal only because application will still > > > > > > at > > > > > > least run, and somebody may want to run with SR-IOV with Intel > > > > > > NIC's on Hyper-V. > > > > > > > > > > > > > > > > > > The warning is just to give users better immediate feedback rather > > > > > > than > > > > > > trying to diagnose poor performance or mystery device not found > > > > > > messages. > > > > > > > > > > > > > > > It really looks strange to me. > > > > > What you need is to fail at compilation if requested PMD is not built. > > > > > I would advise to work on a script to configure meson. > > > > > > > > None of the people that ran into this were using meson build. > > > > For example, VPP doesn't use meson. > > > > > > They will use meson when makefile will be removed :) > > > > > > Anyway, no matter the build system, what we want is a way > > > to guide users to a proper DPDK installation. > > > Your solution is to add some very specific logs. > > > My proposal is to guide the user with a script and some > > > specific parameters so it will fail if a required dependency is not met. > > > > Not familiar enough with meson magic syntax to make vdev_netvsc not build > > without MLX. But that would just be pushing the mystery failure further > > down the road. > > I think you did not understand my proposal. > Let's take an example. You give this instruction to build DPDK: > buildtools/build-require.sh vdev_netvsc mlx4 There is no build-require.sh now and introducing yet another tool is not going to help. > If mlx4 is not built then it will fail with this message: > librte_pmd_mlx4 failed to build > So the user knows what went wrong. No mystery. > > > > Another alternative would be to drop vdev_netvsc from the default Linux > > build. That way users would have to enable it manually. > > > > My preferred solution would be to just kill vdev_netvsc and go to only > > netvsc PMD > > but that is a couple releases away. Let's just fix the meson.build for now to skip vdev_netvsc unless both mlx4 and mlx5 are present. The Makefile can just remain untouched. The people with problem are on older releases anyway. So any attempt to fix the Makefiles won't help those on 18.02, etc.
Re: [dpdk-dev] [PATCH] net/i40e: Fail rte_flow MARK requests if RX func was vectorized
Hi Qi,
> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, May 23, 2019 7:49 PM
> To: Ergin, Mesut A ; Xing, Beilei
>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH] net/i40e: Fail rte_flow MARK requests if RX func was
> vectorized
>
> Hi Mesut:
>
> > -Original Message-
> > From: Ergin, Mesut A
> > Sent: Friday, May 24, 2019 1:57 AM
> > To: Xing, Beilei ; Zhang, Qi Z
> > Cc: dev@dpdk.org; Ergin, Mesut A
> > Subject: [PATCH] net/i40e: Fail rte_flow MARK requests if RX func was
> > vectorized
> >
> > Runtime requests to install an rte_flow with MARK action should fail if a
> > vector
> > RX function was already chosen for the device during configuration time.
> >
> > Currently, i40e rte_flow driver would successfully install the flow with
> > MARK
> > action, even when vector RX functions are in use. However, those vector RX
> > functions will fail to retrieve the MARK data from the device descriptor
> > into
> > the mbuf. The original app installing the flow would never know what went
> > wrong. The change introduced in this patch must be reverted if/when vector
> > RX functions start supporting correct FDIR processing for MARK actions.
> >
> > Signed-off-by: Mesut Ali Ergin
> > ---
> > drivers/net/i40e/i40e_flow.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c
> > index
> > 3afd779..9a14a1c 100644
> > --- a/drivers/net/i40e/i40e_flow.c
> > +++ b/drivers/net/i40e/i40e_flow.c
> > @@ -22,6 +22,7 @@
> > #include "base/i40e_type.h"
> > #include "base/i40e_prototype.h"
> > #include "i40e_ethdev.h"
> > +#include "i40e_rxtx.h"
> >
> > #define I40E_IPV6_TC_MASK (0xFF << I40E_FDIR_IPv6_TC_OFFSET)
> > #define I40E_IPV6_FRAG_HEADER 44
> > @@ -3079,6 +3080,16 @@ i40e_flow_parse_fdir_action(struct rte_eth_dev
> > *dev,
> > filter->action.behavior = I40E_FDIR_PASSTHRU;
> > break;
> > case RTE_FLOW_ACTION_TYPE_MARK:
> > + if (dev->rx_pkt_burst == i40e_recv_scattered_pkts_vec ||
> > + dev->rx_pkt_burst == i40e_recv_pkts_vec ||
> > + dev->rx_pkt_burst == i40e_recv_scattered_pkts_vec_avx2 ||
> > + dev->rx_pkt_burst == i40e_recv_pkts_vec_avx2) {
> > + /* Vector RX Functions do not support MARK*/
> > + rte_flow_error_set(error, EINVAL,
> > + RTE_FLOW_ERROR_TYPE_ACTION,
> act,
> > + "Action not supported when vector
> RX is in use.");
> > + return -rte_errno;
> > + }
>
> We may not need to prevent this if the device is already stopped (check dev-
> >data->dev_started),
> since with the fdir flow be created here, vector path will not be selected in
> following dev_start.
Makes sense, sending a v2 in a bit.
>
> > filter->action.behavior = I40E_FDIR_PASSTHRU;
> > mark_spec = act->conf;
> > filter->action.report_status = I40E_FDIR_REPORT_ID; @@ -
> 3103,6
> > +3114,16 @@ i40e_flow_parse_fdir_action(struct rte_eth_dev *dev,
> >"Invalid action.");
> > return -rte_errno;
> > }
> > + if (dev->rx_pkt_burst == i40e_recv_scattered_pkts_vec ||
> > + dev->rx_pkt_burst == i40e_recv_pkts_vec ||
> > + dev->rx_pkt_burst == i40e_recv_scattered_pkts_vec_avx2 ||
> > + dev->rx_pkt_burst == i40e_recv_pkts_vec_avx2) {
> > + /* Vector RX Functions do not support MARK*/
> > + rte_flow_error_set(error, EINVAL,
> > + RTE_FLOW_ERROR_TYPE_ACTION,
> act,
> > + "Action not supported when vector
> RX is in use.");
> > + return -rte_errno;
> > + }
> > mark_spec = act->conf;
> > filter->action.report_status = I40E_FDIR_REPORT_ID;
> > filter->soft_id = mark_spec->id;
> > --
> > 2.7.4
[dpdk-dev] [PATCH v2] net/i40e: Fail rte_flow MARK requests if RX func was vectorized
Runtime requests to install an rte_flow with MARK action should fail
if a vector RX function was already chosen for the device during
configuration time.
Currently, i40e rte_flow driver would successfully install the flow
with MARK action, even when vector RX functions are in use. However,
those vector RX functions will fail to retrieve the MARK data from the
device descriptor into the mbuf. The original app installing the flow
would never know what went wrong. The change introduced in this patch
must be reverted if/when vector RX functions start supporting correct
FDIR processing for MARK actions.
Signed-off-by: Mesut Ali Ergin
v2:
- Check added to fail MARK request only if the device was started
---
drivers/net/i40e/i40e_flow.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c
index 3afd779..d1233ed 100644
--- a/drivers/net/i40e/i40e_flow.c
+++ b/drivers/net/i40e/i40e_flow.c
@@ -22,12 +22,20 @@
#include "base/i40e_type.h"
#include "base/i40e_prototype.h"
#include "i40e_ethdev.h"
+#include "i40e_rxtx.h"
#define I40E_IPV6_TC_MASK (0xFF << I40E_FDIR_IPv6_TC_OFFSET)
#define I40E_IPV6_FRAG_HEADER 44
#define I40E_TENANT_ARRAY_NUM 3
#define I40E_TCI_MASK 0x
+/* Check whether device RX function is vectorized */
+#define I40E_RX_IS_VECTOR(dev) \
+ (dev->rx_pkt_burst == i40e_recv_scattered_pkts_vec || \
+dev->rx_pkt_burst == i40e_recv_pkts_vec || \
+dev->rx_pkt_burst == i40e_recv_scattered_pkts_vec_avx2 || \
+dev->rx_pkt_burst == i40e_recv_pkts_vec_avx2)
+
static int i40e_flow_validate(struct rte_eth_dev *dev,
const struct rte_flow_attr *attr,
const struct rte_flow_item pattern[],
@@ -3079,6 +3087,13 @@ i40e_flow_parse_fdir_action(struct rte_eth_dev *dev,
filter->action.behavior = I40E_FDIR_PASSTHRU;
break;
case RTE_FLOW_ACTION_TYPE_MARK:
+ if (I40E_RX_IS_VECTOR(dev) && dev->data->dev_started) {
+ /* MARK not supported w/ Vector RX on a started device*/
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ACTION, act,
+ "Action not supported: Vector RX has
been active.");
+ return -rte_errno;
+ }
filter->action.behavior = I40E_FDIR_PASSTHRU;
mark_spec = act->conf;
filter->action.report_status = I40E_FDIR_REPORT_ID;
@@ -3103,6 +3118,13 @@ i40e_flow_parse_fdir_action(struct rte_eth_dev *dev,
"Invalid action.");
return -rte_errno;
}
+ if (I40E_RX_IS_VECTOR(dev) && dev->data->dev_started) {
+ /* MARK not supported w/ Vector RX on a started device*/
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ACTION, act,
+ "Action not supported: Vector RX has
been active.");
+ return -rte_errno;
+ }
mark_spec = act->conf;
filter->action.report_status = I40E_FDIR_REPORT_ID;
filter->soft_id = mark_spec->id;
--
2.7.4
[dpdk-dev] AF_XDP PMD cannot use with software NICs
Hello, In current AF_XDP PMD implementation, we cannot use it with software NICs like VETH. Because it allocates umem with RTE_MEMZONE_IOVA_CONTIG. Since AF_XDP itself is usable with any network devices, I think it is better to have option to take umem with RTE_MEMZONE_SIZE_HINT_ONLY. It is also useful for testing perpose or using DPDK from containers. Any thought or future plan for this problem? Thanks, Yutaro
