In order to deprecate the rte_atomic and rte_smp barrier APIs [1], prevent
the patches from using these APIs and __sync builtins in new code.
Please use __atomic builtins instead of __sync builtins, rte_atomicNN_xxx
and rte_smp_[r/w]mb APIs.
On x86 the __atomic_thread_fence(__ATOMIC_SEQ_CST) is quite expensive for
SMP case. Flag the new code which use __atomic_thread_fence API.
Please use rte_thread_fence API instead of __atomic_thread_fence builtins.
1: Refer to the locks-and-atomic-operations section in
https://doc.dpdk.org/guides/prog_guide/writing_efficient_code.html
Signed-off-by: Phil Yang <phil.yang@arm.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Provide a wrapper for __atomic_thread_fence builtins to support
optimized code for __ATOMIC_SEQ_CST memory order for x86 platforms.
Suggested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Signed-off-by: Phil Yang <phil.yang@arm.com>
Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Add information about possible optimizations using C11 atomic builtins.
Signed-off-by: Phil Yang <phil.yang@arm.com>
Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
If Jansson was found, the headers list is overwritten when including
rte_metrics_telemetry.h, which prevents rte_metrics.h from being
installed. This is now fixed to add to headers, rather than overwrite,
to allow both headers be installed when Jansson is present.
Fixes: c5b7197f662e ("telemetry: move some functions to metrics library")
Cc: stable@dpdk.org
Signed-off-by: Ciara Power <ciara.power@intel.com>
Acked-by: David Marchand <david.marchand@redhat.com>
This change is required to allow the branch ratio algorithm to
power manage cores with no workload running on them. This is
useful both when idle cores don't use C-states and for a number of
hyperthreading scenarios.
Signed-off-by: Rory Sexton <rory.sexton@intel.com>
Reviewed-by: David Hunt <david.hunt@intel.com>
Acked-by: Reshma Pattan <reshma.pattan@intel.com>
This modification allows for the branch ratio threshold to be set
per core rather than system wide. This gives greater flexibility to
the branch ratio monitoring allowing it to manage different
workloads with different characteristics on the same system.
Signed-off-by: Rory Sexton <rory.sexton@intel.com>
Reviewed-by: David Hunt <david.hunt@intel.com>
Acked-by: Reshma Pattan <reshma.pattan@intel.com>
Change the log level for RTE_TEST_ASSERT macro to error to help
log errors while running test cases.
Suggested-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Acked-by: Lukasz Wojciechowski <l.wojciechow@partner.samsung.com>
abidiff can provide some more information about the ABI difference it
detected.
In all cases, a discussion on the mailing must happen but we can give
some hints to know if this is a problem with the script calling abidiff,
a potential ABI breakage or an unambiguous ABI breakage.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Aaron Conole <aconole@redhat.com>
'librte_rcu' is now dependency to 'librte_lpm' library, this dependency
should be reflected to build system.
Fixes: 8a9f8564e9f9 ("lpm: implement RCU rule reclamation")
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
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>
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>
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>
During probe, driver issues HWRM_CFA_ADV_FLOW_MGNT_QCAPS command.
But it is not using the command response anywhere which makes the
fw call redundant.
Remove the unnecessary HWRM_CFA_ADV_FLOW_MGNT_QCAPS call to fw.
Remove the redundant flow_flags in bnxt struct.
Fixes: afef822b2e1b ("net/bnxt: support creating SMAC and inner DMAC filters")
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>
"enum bnxt_hw_context" is defined in the header file, but is not
used anywhere.
Fixes: 9738793f28ec ("net/bnxt: add VNIC functions and structs")
Cc: stable@dpdk.org
Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
VFs are not privileged to issue HWRM_PORT_LED_QCFG/CFG.
There is no need to allocate "bp->leds" memory.
Fixes: 205b74295282 ("net/bnxt: fix allocation of LED config info")
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>
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.
usage: --forward-mode=5tswap
Signed-off-by: Shiri Kuzin <shirik@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
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.
Fixes: ffc905f3b856 ("ethdev: separate driver APIs")
Fixes: ec0dec44ecb9 ("net/atlantic: enable MACsec configuration")
Cc: stable@dpdk.org
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
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>
