In order to verify offloading of eCPRI protocol via flow rules, the
command line of flow creation should support the parsing of the eCPRI
pattern.
Based on the specification, one eCPRI message will have the common
header and payload. Payload format is various based on the type field
of the common header. Fixed strings will be used instead of integer
to make the CLI easy for auto-completion.
The testpmd command line examples of flow to match eCPRI item are
listed below:
1. flow create 0 ... pattern eth / ecpri / end actions ...
This is to match all eCPRI messages.
2. flow create 0 ... pattern eth / ecpri common type rtc_ctrl / end actions ...
This is to match all eCPRI messages with the type #2 - "Real-Time
Control Data".
3. flow create 0 ... pattern eth / ecpri common type iq_data pc_id is [U16Int] / end actions ...
This is to match eCPRI messages with the type #0 - "IQ Data", and
the physical channel ID 'pc_id' of the messages is a specific
value. Since the sequence ID is changeable, there is no need to
match that field in the flow.
Currently, only type #0, #2 and #5 will be supported.
Since eCPRI could be over Ethernet layer (or after .1Q) and UDP
layer, it is the PMD driver's responsibility to check whether eCPRI
is supported and which protocol stack is supported. Network byte
order should be used for eCPRI header, the same as other headers.
Signed-off-by: Bing Zhao <bingz@mellanox.com> Acked-by: Ori Kam <orika@mellanox.com>
Add a new item "rte_flow_item_ecpri" in order to match eCRPI header.
eCPRI is a packet based protocol used in the fronthaul interface of
5G networks. Header format definition could be found in the
specification via the link below:
https://www.gigalight.com/downloads/standards/ecpri-specification.pdf
eCPRI message can be over Ethernet layer (.1Q supported also) or over
UDP layer. Message header formats are the same in these two variants.
Signed-off-by: Bing Zhao <bingz@mellanox.com> Acked-by: Ori Kam <orika@mellanox.com> Acked-by: Olivier Matz <olivier.matz@6wind.com>
Kalesh AP [Thu, 9 Jul 2020 09:38:32 +0000 (15:08 +0530)]
net/bnxt: fix freeing filters on flow creation failure
This patch does following things:
1. Added a wrapper function bnxt_clear_one_vnic_filter()
for destroying the filters in hw. This will avoid duplicate
code in many places.
2. When flow create fails due to an already existing mark id
for the new flow id created, fixed to destroy the hw
filter created.
3. Re-arranged code to move a log and list update to right place.
Fixes: 9db66782bd06 ("net/bnxt: fix supporting zero mark ID with RSS action") Fixes: 5ef3b79fdfe6 ("net/bnxt: support flow filter ops") Cc: stable@dpdk.org Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Kalesh AP [Thu, 9 Jul 2020 09:38:31 +0000 (15:08 +0530)]
net/bnxt: fix flow error on filter creation
If set_em_filter/set_ntuple_filter cmds fails for some reason,
driver is not filling the "rte_flow_error" string buffer.
Same is the case when flow create fails due to an already
existing mark id for the new flow id created.
This leads to a crash in testpmd while trying to print the
error message.
Fixes: 5c1171c97216 ("net/bnxt: refactor filter/flow") Fixes: 9db66782bd06 ("net/bnxt: fix supporting zero mark ID with RSS action") Cc: stable@dpdk.org Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Yicai Lu [Fri, 10 Jul 2020 03:29:35 +0000 (11:29 +0800)]
net/bonding: fix LACP negotiation
When two host is connected directly without any devices like switch,
rx_machine_update would receiving partner LACP negotiation packets,
and partner's port mac is filled with zeros in this packet, which is
different with internal's mode4 mac. So in this situation, it would
never go rx_machine branch and then execute mac swap for negotiation!
Thus bond mode 4 will negotiation failed.
Fixes: 56cbc0817399 ("net/bonding: fix LACP negotiation") Cc: stable@dpdk.org Signed-off-by: Yicai Lu <luyicai@huawei.com> Reviewed-by: Wei Hu (Xavier) <xavier.huwei@huawei.com>
The new 5-tuple swap engine swaps:
source and destination mac address,
source and destination address in ipv4/ipv6,
source and destination port in UDP/TCP.
The forwarding engine will parse each layer
and swap it, and will stop when the next
layer doesn't match.
The mentioned headers of ICMP/ARP/Multicast
packets will be swapped as well according to
matching layers.
Using '__rte_internal' tag in 'rte_ethdev_driver.h' causing build error
for applications and examples. Because they don't define
'ALLOW_INTERNAL_API' flag and '__rte_internal' causes the error.
This patch is preparation for future '__rte_internal' usage.
At first place, applications/examples should not include
'rte_ethdev_driver.h', this is happening because of PMD public header
files include 'rte_ethdev_driver.h' by mistake.
Updated PMD public header files to not include internal header files.
But for unit test application, 'app/test', enable accessing internal
APIs, since some unit tests need them.
Heinrich Kuhn [Fri, 10 Jul 2020 14:28:46 +0000 (16:28 +0200)]
net/nfp: fix RSS hash configuration reporting
Prior to this fix the NFP PMD implementation of the .rss_hash_conf_get
callback did not propagate the current hardware state of rss_hf back up
to the caller. Users of the hash_conf_get callback would receive an
incorrect representation of what the RSS configuration currently is in
hardware.
Fixes: 934e4c60fbff ("nfp: add RSS") Cc: stable@dpdk.org Signed-off-by: Heinrich Kuhn <heinrich.kuhn@netronome.com> Signed-off-by: Simon Horman <simon.horman@netronome.com>
This command enables the packet send scheduling on timestamps if
the first parameter is not zero, generic format:
testpmd> set txtimes (inter),(intra)
where:
inter - is the delay between the bursts in the device clock units.
If "intra" (next parameter) is zero, this is the time between the
beginnings of the first packets in the neighbour bursts, if "intra"
is not zero, "inter" specifies the time between the beginning of
the first packet of the current burst and the beginning of the last
packet of the previous burst. If "inter"parameter is zero the send
scheduling on timestamps is disabled (default).
intra - is the delay between the packets within the burst specified
in the device clock units. The number of packets in the burst is
defined by regular burst setting. If "intra" parameter is zero no
timestamps provided in the packets excepting the first one in the
burst.
As the result the bursts of packet will be transmitted with
specific delay between the packets within the burst and specific
delay between the bursts. The rte_eth_read_clock() is supposed to
be engaged to get the current device clock value and provide the
reference for the timestamps. If there is no supported
rte_eth_read_clock() there will be no provided send scheduling on
the device.
- show txtimes, displays the timing settings
- txonly burst time pattern
There is the requirement on some networks for precise traffic timing
management. The ability to send (and, generally speaking, receive)
the packets at the very precisely specified moment of time provides
the opportunity to support the connections with Time Division
Multiplexing using the contemporary general purpose NIC without involving
an auxiliary hardware. For example, the supporting of O-RAN Fronthaul
interface is one of the promising features for potentially usage of the
precise time management for the egress packets.
The main objective of this patchset is to specify the way how applications
can provide the moment of time at what the packet transmission must be
started and to describe in preliminary the supporting this feature
from mlx5 PMD side [1].
The new dynamic timestamp field is proposed, it provides some timing
information, the units and time references (initial phase) are not
explicitly defined but are maintained always the same for a given port.
Some devices allow to query rte_eth_read_clock() that will return
the current device timestamp. The dynamic timestamp flag tells whether
the field contains actual timestamp value. For the packets being sent
this value can be used by PMD to schedule packet sending.
The device clock is opaque entity, the units and frequency are
vendor specific and might depend on hardware capabilities and
configurations. If might (or not) be synchronized with real time
via PTP, might (or not) be synchronous with CPU clock (for example
if NIC and CPU share the same clock source there might be no
any drift between the NIC and CPU clocks), etc.
After PKT_RX_TIMESTAMP flag and fixed timestamp field supposed
deprecation and obsoleting, these dynamic flag and field might be
used to manage the timestamps on receiving datapath as well. Having
the dedicated flags for Rx/Tx timestamps allows applications not
to perform explicit flags reset on forwarding and not to promote
received timestamps to the transmitting datapath by default.
The static PKT_RX_TIMESTAMP is considered as candidate to become
the dynamic flag and this move should be discussed.
When PMD sees the "rte_dynfield_timestamp" set on the packet being sent
it tries to synchronize the time of packet appearing on the wire with
the specified packet timestamp. If the specified one is in the past it
should be ignored, if one is in the distant future it should be capped
with some reasonable value (in range of seconds). These specific cases
("too late" and "distant future") can be optionally reported via
device xstats to assist applications to detect the time-related
problems.
There is no any packet reordering according timestamps is supposed,
neither within packet burst, nor between packets, it is an entirely
application responsibility to generate packets and its timestamps
in desired order. The timestamps can be put only in the first packet
in the burst providing the entire burst scheduling.
PMD reports the ability to synchronize packet sending on timestamp
with new offload flag:
This is palliative and might be replaced with new eth_dev API
about reporting/managing the supported dynamic flags and its related
features. This API would break ABI compatibility and can't be introduced
at the moment, so is postponed to 20.11.
For testing purposes it is proposed to update testpmd "txonly"
forwarding mode routine. With this update testpmd application generates
the packets and sets the dynamic timestamps according to specified time
pattern if it sees the "rte_dynfield_timestamp" is registered.
The new testpmd command is proposed to configure sending pattern:
set tx_times <burst_gap>,<intra_gap>
<intra_gap> - the delay between the packets within the burst
specified in the device clock units. The number
of packets in the burst is defined by txburst parameter
<burst_gap> - the delay between the bursts in the device clock units
As the result the bursts of packet will be transmitted with specific
delays between the packets within the burst and specific delay between
the bursts. The rte_eth_read_clock is supposed to be engaged to get the
current device clock value and provide the reference for the timestamps.
Ivan Malov [Fri, 19 Jun 2020 09:21:15 +0000 (10:21 +0100)]
net: use named constants for deprecated QinQ TPIDs
Add named constants for deprecated QinQ TPIDs.
Update drivers which have already been using existing
TPID named constants from librte_net to use the
new named constants rather than magic numbers.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Phil Yang [Mon, 22 Jun 2020 09:04:42 +0000 (17:04 +0800)]
app/testpmd: fix CPU cycles per packet stats on Tx modes
In txonly and flowgen forwarding mode, calculating CPU per packets with
total received packets is not accurate. Use total transmitted packets
for these cases.
The error output under txonly mode:
testpmd> show fwd stats all
---------------------- Forward statistics for port 0 -------------------
RX-packets: 0 RX-dropped: 0 RX-total: 0
TX-packets: 3582891927 TX-dropped: 401965824 TX-total: 3984857751
TX-bursts : 86381636 [0% of 0 pkts + 85% of 64 pkts + 15% of 32 pkts]
-------------------------------------------------------------------------
---------------------- Forward statistics for port 1 -------------------
RX-packets: 1 RX-dropped: 394351696 RX-total: 394351697
TX-packets: 3582890632 TX-dropped: 401965568 TX-total: 3984856200
TX-bursts : 86381679 [0% of 0 pkts + 85% of 64 pkts + 15% of 32 pkts]
-------------------------------------------------------------------------
+++++++++++++++ Accumulated forward statistics for all ports+++++++++++++
RX-packets: 1 RX-dropped: 394351696 RX-total: 394351697
TX-packets: 7165782559 TX-dropped: 803931392 TX-total: 7969713951
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CPU cycles/packet=54984156291.00 \
(total cycles=54984156291 / total RX packets=1) at 200 MHz Clock
Fixes: 53324971a14e ("app/testpmd: display/clear forwarding stats on demand") Cc: stable@dpdk.org Signed-off-by: Phil Yang <phil.yang@arm.com> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com> Tested-by: Ferruh Yigit <ferruh.yigit@intel.com>
Jasvinder Singh [Tue, 23 Jun 2020 09:32:59 +0000 (10:32 +0100)]
app/testpmd: remove softnic forward mode
Softnic can be used like other virtual devices without
needing any special mode. Therefore, remove softnic mode
from testpmd app. Documentation is updated as well.
RSS for IPv6 prefix fields are supported in this patch, so that we
can use prefixes instead of full IPv6 address for RSS. These prefixes
include the first 32, 48, 64 bits of both SRC and DST IPv6 address.
This patch defines new RSS offload types for IPv6 prefix with 32, 40,
48, 56, 64, 96 bits of both SRC and DST IPv6 address.
Ref https://tools.ietf.org/html/rfc6052.
Xiaoyun Wang [Thu, 9 Jul 2020 13:43:02 +0000 (21:43 +0800)]
net/hinic/base: convert error value to ETIMEDOUT
Following commit updated the error codes:
commit 2ae8e130cf21 ("net/hinic/base: modify returned error values")
In that commit 'ETIME' errors are not used because it is not supported
by FreeBSD, instead in this patch converting relevant error codes to
'ETIMEDOUT'.
Signed-off-by: Xiaoyun Wang <cloud.wangxiaoyun@huawei.com> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
ethdev: fix VLAN offloads set if no relative capabilities
Currently, there is a potential problem that calling the API function
rte_eth_dev_set_vlan_offload to start VLAN hardware offloads which the
driver does not support. If the PMD driver does not support certain VLAN
hardware offloads and does not check for it, the hardware setting will
not change, but the VLAN offloads in dev->data->dev_conf.rxmode.offloads
will be turned on.
It is supposed to check the hardware capabilities to decide whether the
relative callback needs to be called just like the behavior in the API
function named rte_eth_dev_configure. And it is also needed to cleanup
duplicated checks which are done in some PMDs. Also, note that it is
behaviour change for some PMDs which simply ignore (with error/warning
log message) unsupported VLAN offloads, but now it will fail.
Fixes: a4996bd89c42 ("ethdev: new Rx/Tx offloads API") Fixes: 0ebce6129bc6 ("net/dpaa2: support new ethdev offload APIs") Fixes: f9416bbafd98 ("net/enic: remove VLAN filter handler") Fixes: 4f7d9e383e5c ("fm10k: update vlan offload features") Fixes: fdba3bf15c7b ("net/hinic: add VLAN filter and offload") Fixes: b96fb2f0d22b ("net/i40e: handle QinQ strip") Fixes: d4a27a3b092a ("nfp: add basic features") Fixes: 56139e85abec ("net/octeontx: support VLAN filter offload") Fixes: ba1b3b081edf ("net/octeontx2: support VLAN offloads") Fixes: d87246a43759 ("net/qede: enable and disable VLAN filtering") Cc: stable@dpdk.org Signed-off-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com> Acked-by: Hyong Youb Kim <hyonkim@cisco.com> Acked-by: Sachin Saxena <sachin.saxena@nxp.com> Acked-by: Xiaoyun Wang <cloud.wangxiaoyun@huawei.com> Acked-by: Harman Kalra <hkalra@marvell.com> Acked-by: Jeff Guo <jia.guo@intel.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
ethdev: fix data room size verification in Rx queue setup
In the rte_eth_rx_queue_setup API function, the local variable named
mbp_buf_size, which is the data room size of the input parameter mp,
is checked to guarantee that each memory chunk used for net device
in the mbuf is bigger than the min_rx_bufsize. But if mbp_buf_size is
less than RTE_PKTMBUF_HEADROOM, the value of the following statement
will be a large number since the mbp_buf_size is a unsigned value.
mbp_buf_size - RTE_PKTMBUF_HEADROOM
As a result, it will cause a segment fault in this situation.
This patch fixes it by modify the check condition to guarantee that the
local variable named mbp_buf_size is bigger than RTE_PKTMBUF_HEADROOM.
Fixes: af75078fece3 ("first public release") Cc: stable@dpdk.org Signed-off-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Wei Hu (Xavier) <xavier.huwei@huawei.com> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com> Acked-by: Sachin Saxena <sachin.saxena@nxp.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
common/mlx5: fix physical port name pattern recognition
This patch makes the Infiniband device physical port name
recognition more strict. Currently mlx5 PMD might recognize
the names like "pf0sf0" erroneously as "pf0" and the wrong
device type (host PF representor) is reported.
The names like "pf0sf0" belong to PCI subfunctions which
is currently not supported by mlx5 PMD and this false
recognition must be eliminated.
RSS for GTP with outer & inner ipv4 & ipv6 combination are supported
in this patch, so that we can process RSS based on inner 5 tuples or
3 tuples of all the cases below of GTP packets:
1. ipv4 (outer) + ipv4 (inner)
2. ipv4 (outer) + ipv6 (inner)
3. ipv6 (outer) + ipv4 (inner)
4. ipv6 (outer) + ipv6 (inner)
RSS for GTP with outer & inner ipv4 & ipv6 combination are supported
in this patch, so that we can process RSS based on inner 5 tuples or
3 tuples of all the cases below of GTP packets:
1. ipv4 (outer) + ipv4 (inner)
2. ipv4 (outer) + ipv6 (inner)
3. ipv6 (outer) + ipv4 (inner)
4. ipv6 (outer) + ipv6 (inner)
Simei Su [Thu, 9 Jul 2020 06:21:28 +0000 (14:21 +0800)]
net/ice: fix protocol header for PPPoE
When adding a RSS rule with pattern MAC_PPPOE_IPV4_UDP and input
set SRC/DST IPV4, because of incomplete protocol header fields,
the rule can't do hash with inner src/dst ipv4. PPPOE_IPV4_TCP/SCTP
and PPPOE_IPV6_UDP/TCP/SCTP also have similar issues. This patch
complements protocol header fields for PPPOE data packets.
Guinan Sun [Thu, 9 Jul 2020 08:00:41 +0000 (08:00 +0000)]
net/ixgbe/base: improve log about autoneg being disabled
On ESXi OS, when user disables auto negotiation, the following log
appears: "(unsupported) Flow control autoneg is disabled".
It is true that auto negotiation is disabled but it is
not necessarily true that it is not supported.
Signed-off-by: Jakub Chylkowski <jakubx.chylkowski@intel.com> Signed-off-by: Guinan Sun <guinanx.sun@intel.com> Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Guinan Sun [Thu, 9 Jul 2020 08:00:40 +0000 (08:00 +0000)]
net/ixgbe/base: initialize data field in struct buffer
While sending request using ixgbe_hic_unlocked() the data field in
buffer struct is not used. It is set when the struct is overwritten by
FW to deliver the response. To not pass random data to FW the whole
structure should be zeroed before use.
Signed-off-by: Krzysztof Galazka <krzysztof.galazka@intel.com> Signed-off-by: Piotr Pietruszewski <piotr.pietruszewski@intel.com> Signed-off-by: Guinan Sun <guinanx.sun@intel.com> Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Guinan Sun [Thu, 9 Jul 2020 08:00:39 +0000 (08:00 +0000)]
net/ixgbe/base: remove log message FC autoneg
The function ixgbe_device_supports_autoneg_fc is checking whether
a particular device and medium configuration is supporting
Flow Control Autonegotiation. In case of non-support, the message
is always logged which is confusing.
The fix is removing unnecessary log entry.
Guinan Sun [Thu, 9 Jul 2020 08:00:35 +0000 (08:00 +0000)]
net/ixgbe/base: move increments after evaluations
The retry variable was being incremented before it was evaluated by the
subsequent conditional against the maximum retries to figure out which
message to print. So we'll move the increment op to the end.
Signed-off-by: Jeb Cramer <jeb.j.cramer@intel.com> Signed-off-by: Guinan Sun <guinanx.sun@intel.com> Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Guinan Sun [Thu, 9 Jul 2020 08:00:33 +0000 (08:00 +0000)]
net/ixgbe/base: cleanup spelling mistakes in comments
Several functions in the driver code have a weird function comment
formatting which uses two spaces instead of only one space for the main
function body.
This formatting will be mechanically fixed by sed in a future patch, but
doing so leads to some spelling warnings on that patch. Cleanup the
spelling mistakes that will be detected first. This way, it is easier to
verify the mechanical transformation done by sed in the following patch.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Guinan Sun <guinanx.sun@intel.com> Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Guinan Sun [Thu, 9 Jul 2020 08:00:31 +0000 (08:00 +0000)]
net/ixgbe/base: fix infinite recursion on PCIe link down
In some corner cases the functions ixgbe_clear_rar_generic and
ixgbe_clear_vmdq_generic may call one another leading to infinite
recursion.
When ixgbe_clear_vmdq_generic is called with IXGBE_CLEAR_VMDQ_ALL
flag, it's going to clear MPSAR registers, and proceed to call
ixgbe_clear_rar_generic, which in turn will clear the RAR registers,
and recursively call back ixgbe_clear_vmdq_generic. Normally, the
latter would detect that MPSAR registers have already been cleared
and terminate the recursion.
However, when PCIe link is down, and before the driver has had the
opportunity to shut itself down, all register reads return 0xFFFFFFFF,
and all register writes fail silently. In such case, because
ixgbe_clear_vmdq_generic blindly assumes that clearing MPSAR registers
succeeded, it's going to always call ixgbe_clear_rar_generic, which
in turn will always call back ixgbe_clear_vmdq_generic, creating
infinite recursion.
This patch re-reads MPSAR register values after they had been cleared.
In case of PCIe link failure, the values read will be non-zero, which
will terminate the recursion. On the other hand, under normal
circumstances the value read from MPSAR registers is going to be equal
to the value previously written, so this patch is expected not to cause
any regressions.
Fixes: af75078fece3 ("first public release") Cc: stable@dpdk.org Signed-off-by: Robert Konklewski <robertx.konklewski@intel.com> Signed-off-by: Guinan Sun <guinanx.sun@intel.com> Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Guinan Sun [Thu, 9 Jul 2020 08:00:30 +0000 (08:00 +0000)]
net/ixgbe/base: fix x550em 10G NIC link status
With the NVM image for x550em XFI will not report
the auto-negotiation feature correctly. The auto-negotiation
should be "No" for supports and advertised items.
At the same time update speed makes it support 1G and 10G.
Fixes: 833df43399e7 ("net/ixgbe/base: add SGMII link for X550") Cc: stable@dpdk.org Signed-off-by: Piotr Skajewski <piotrx.skajewski@intel.com> Signed-off-by: Guinan Sun <guinanx.sun@intel.com> Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Add support for .get_reg eth_dev ops which will be used to collect the
firmware debug data.
PMD on detecting on some HW errors will collect the FW/HW Dump to a
buffer and then it will save it to a file implemented in
qede_save_fw_dump().
Dump file location and name:
Location: <RTE_SDK> or DPDK root
Name: qede_pmd_dump_mm-dd-yy_hh-mm-ss.bin
DPDK applications can initiate a debug data collection by invoking DPDK
library’s rte_eth_dev_get_reg_info() API. This API invokes .get_reg()
interface in the PMD.
PMD implementation of .get_reg() collects the FW/HW Dump, saves it to
data field of rte_dev_reg_info and passes it to the application. It’s
the responsibility of the application to save the FW/HW Dump to a file.
We recommendation using the file name format used by qede_save_fw_dump().
Signed-off-by: Rasesh Mody <rmody@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
net/qede: add infrastructure for debug data collection
The patch adds QEDE PMD ops and APIs to calculate the size and collect
the debug dump for various firmware components. The patch adds new files
qede_debug.[ch] that has all the firmware debug data collection
infrastructure changes.
Signed-off-by: Rasesh Mody <rmody@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
net/qede/base: add changes for debug data collection
This patch adds base driver APIs required for debug data collection.
It adds support for dumping internal lookup tables(ilt), reading nvram
image, register definitions.
Signed-off-by: Rasesh Mody <rmody@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
This patch rearranges some of the base driver structures which will be
also used by debug data collection (DDC) implementation. It adds a new
file ecore_hsi_func_common.h with Physical, Virtual memory descriptors.
Signed-off-by: Rasesh Mody <rmody@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
Long Li [Wed, 24 Jun 2020 01:11:45 +0000 (18:11 -0700)]
net/netvsc: fix underflow when Rx external mbuf
When rte_pktmbuf_attach_extbuf() is used, the driver should not decrease
the reference count in its callback function hn_rx_buf_free_cb, because
the reference count is already decreased by rte_pktmbuf. Doing it twice
may result in underflow and driver may never send an ack packet over
vmbus to host.
Also declares rxbuf_outstanding as atomic, because this value is shared
among all receive queues.
Fixes: 4e9c73e96e83 ("net/netvsc: add Hyper-V network device") Cc: stable@dpdk.org Signed-off-by: Long Li <longli@microsoft.com> Acked-by: Stephen Hemminger <stephen@networkplumber.org>
David Marchand [Tue, 16 Jun 2020 09:46:37 +0000 (11:46 +0200)]
net/bonding: fix socket ID check
Caught by code review, rte_eth_dev_socket_id() returns -1 on error.
The code should behave the same, but still, do not use LCORE_ID_ANY for
something that is not a lcore id.
Fixes: c15c5897340d ("net/bonding: avoid allocating mempool on unknown socket") Cc: stable@dpdk.org Signed-off-by: David Marchand <david.marchand@redhat.com> Acked-by: Chas Williams <chas3@att.com>
net/bnxt: avoid hard coded values when reading counters
Instead of using hardcoded values for the byte/pkt value shifts/masks
to read from the HW counters, use the shift/mask values from the device
template params
Added support for set transport port source and destination
rewrite action items. This allows changing the tcp or udp
source/destination ports for a given flow.
net/bnxt: add conditional opcodes for mapper result table
Added support for conditional mapper result opcodes. The conditional
opcodes allows to set the action details in hardware based on the
actions configured for the flow. This allows aggregation of multiple
templates.
Added port configuration changes to support full offload
rules when VF representor ports are used. The direction of
the flow is determined using the configured direction and the
configured match and action ports of the flow create.
Added support for the PF and VF port action items in the flow
create. During flow create the output port action can now be specified
as PF or VF port and those ports are parsed accordingly and converted
to vnic or vport as per the flow direction.
net/bnxt: move VXLAN outer IP protocol ID in encap
The outer ip protocol was not encapsulated in the right location
when ip header is sent by the application. The order of encapsulation
has to be reversed.
net/bnxt: remove VNIC and vport bits from template match
Removed the vnic and vport bitmaps from template matching. It
is assumed that these will be populated implicitly and based
on the direction the appropriate action property shall be used.
The return value of some functions is explicitly ignored
in cases where scope id may not be valid for internal EM
entries.
Additional minor refactoring and cleanups
- Change log level for some log messages to DEBUG instead of ERR.
- Check data size conformity and log appropriate message.
Signed-off-by: Michael Wildt <michael.wildt@broadcom.com> Signed-off-by: Kishore Padmanabha <kishore.padmanabha@broadcom.com> Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Randy Schacher <stuart.schacher@broadcom.com> Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
The bnxt vector mode receive handler does not support the rte_flow
'mark' action. Since we cannot know in advance whether this action
will be required, add support for dynamically switching from vector
to non-vector receive when the first flow create request with a
mark action is processed.
Fixes: 94eb699bc82e ("net/bnxt: support flow mark action") Cc: stable@dpdk.org Suggested-by: Thomas Monjalon <thomas@monjalon.net> Signed-off-by: Lance Richardson <lance.richardson@broadcom.com> Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Jun Yang [Tue, 7 Jul 2020 09:22:42 +0000 (14:52 +0530)]
net/dpaa2: support flow API FS miss action configuration
1) dpni_set_rx_hash_dist and dpni_set_rx_fs_dist used for TC
configuration instead of dpni_set_rx_tc_dist. Otherwise,
re-configuration of default TC of QoS fails.
2) Default miss action is to drop. "export
DPAA2_FLOW_CONTROL_MISS_FLOW=flow_id" is used receive the missed
packets from flow with flow ID specified.
Signed-off-by: Jun Yang <jun.yang@nxp.com> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Jun Yang [Tue, 7 Jul 2020 09:22:35 +0000 (14:52 +0530)]
net/dpaa2: define size of table entry
If entry size is not bigger than 27, MC alloc one TCAM entry,
otherwise, alloc 2 TCAM entries.
Extracts size by HW must be not bigger than TCAM entry size(27 or 54).
So define the flow entry size as 54.
Signed-off-by: Jun Yang <jun.yang@nxp.com> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>