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 commit adds testpmd capability to provide timestamps on the packets
being sent in the txonly mode. This includes:
- SEND_ON_TIMESTAMP support
new device Tx offload capability support added, example:
testpmd> port config 0 tx_offload send_on_timestamp on
- set txtimes, registers field and flag, example:
testpmd> set txtimes 1000000,0
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
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
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.
[1] http://patches.dpdk.org/patch/73714/
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
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>
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>
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.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
The APIs are marked in the doxygen comment but better to mark the
symbols too. This is planned for v20.11 release.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
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.
Signed-off-by: Junfeng Guo <junfeng.guo@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
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>
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>
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>
Avoids recalculation of DPAA2_IOVA_TO_VADDR, since this is somewhat
costly function on no-IOMMU setups.
Brings about 0.5 Gbps improvement at 19 Gbps speeds on LX2160 with 512b
packets.
Signed-off-by: Roman Kapl <rka@sysgo.com>
Reviewed-by: Hemant Agrawal <hemant.agrawal@nxp.com>
The following commit introduced several new actions. Make the dump
function to print those actions.
commit 6faf81f1d2c3 ("net/enic: update flow manager API")
Signed-off-by: Hyong Youb Kim <hyonkim@cisco.com>
Reviewed-by: John Daley <johndale@cisco.com>
Flow manager API includes push/pop actions, so support corresponding
DPDK flow actions.
Signed-off-by: Hyong Youb Kim <hyonkim@cisco.com>
Reviewed-by: John Daley <johndale@cisco.com>
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.
Fixes: 420bbdae89f2 ("net/mlx5: fix host physical function representor naming")
Cc: stable@dpdk.org
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
This adds the ConnectX-6 Lx device id to the list of supported
Mellanox devices that run the MLX5 PMD.
The device is still in development stage.
Signed-off-by: Ali Alnubani <alialnu@mellanox.com>
Acked-by: Raslan Darawsheh <rasland@mellanox.com>
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)
Signed-off-by: Junfeng Guo <junfeng.guo@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
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)
Signed-off-by: Junfeng Guo <junfeng.guo@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
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.
Fixes: 0b952714e9c1 ("net/ice: refactor PF hash flow")
Signed-off-by: Simei Su <simei.su@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Writing to read-only fields returns a non-OK Return Status
for shadow RAM write command for X550.
This information was previously discarded.
Signed-off-by: Stanislaw Grzeszczak <stanislaw.a.grzeszczak@intel.com>
Signed-off-by: Guinan Sun <guinanx.sun@intel.com>
Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
The codes has been exposed correctly, so remove pre-processor tags.
Signed-off-by: Guinan Sun <guinanx.sun@intel.com>
Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
We are seeing interoperability issues with switches when 2.5G and 5G
in x550 are advertised by default, so default to off.
Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
Signed-off-by: Guinan Sun <guinanx.sun@intel.com>
Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Write FDIRIP6M register to allow flow director filter
to set ipv6 rules without setting ipv6 source/destination address.
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>
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>
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>
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.
Signed-off-by: Zalfresso-Jundzillo <marekx.zalfresso-jundzillo@intel.com>
Signed-off-by: Guinan Sun <guinanx.sun@intel.com>
Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Add typecast for type mismatch.
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>
This patch is for restarting auto negotiation on PHY.
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>
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>
Remove unnecessary extra whitespace on all function comments, replacing
' * ' with ' * '.
This was done automatically via sed using the following transformation:
sed 's/^ \* / * /'
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>
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>
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>
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>
For the "Apply Update" command the firmware does not
given an response. For this command, success should
be return.
Signed-off-by: Mateusz Kowalski <mateusz.kowalski@intel.com>
Signed-off-by: Guinan Sun <guinanx.sun@intel.com>
Reviewed-by: Wei Zhao <wei.zhao1@intel.com>
Host interface Shadow RAM Read (0x31) command response
buffer length should be stored in two bytes, instead of one byte.
This patch fixes it.
Fixes: e6102361b1d4 ("net/ixgbe/base: use 2 bytes for flash read command")
Cc: stable@dpdk.org
Signed-off-by: Mateusz Kowalski <mateusz.kowalski@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>
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>
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>
When external buffer is used, driver should detach it if it doesn't make
it successfully to the queue.
Signed-off-by: Long Li <longli@microsoft.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
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>
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>
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
Reviewed-by: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
Signed-off-by: Somnath Kotur <somnath.kotur@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>