Add the create/del policy CLIs to support actions per color.
The CLIs are:
Create: add port meter policy (port_id) (policy_id) g_actions (actions)
y_actions (actions) r_actions (actions)
Delete: del port meter policy (port_id) (policy_id)
Examples:
testpmd> add port meter policy 0 1 g_actions rss / end y_actions end
r_actions drop / end
testpmd> del port meter policy 0 1
Signed-off-by: Haifei Luo <haifeil@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
The command line for testing connection tracking is added. To create
a conntrack object, 3 parts are needed.
set conntrack com peer ...
set conntrack orig scale ...
set conntrack rply scale ...
This will create a full conntrack action structure for the indirect
action. After the indirect action handle of "conntrack" created, it
could be used in the flow creation. Before updating, the same
structure is also needed together with the update command
"conntrack_update" to update the "dir" or "ctx".
After the flow with conntrack action created, the packet should jump
to the next flow for the result checking with conntrack item. The
state is defined with bits and a valid combination could be
supported.
Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Add the new items to support the flow configuration for IP fragment
packets.
Signed-off-by: Ting Xu <ting.xu@intel.com>
Signed-off-by: Jeff Guo <jia.guo@intel.com>
Acked-by: Ori Kam <orika@nvidia.com>
The integrity item allows the application to match
on the integrity of a packet.
Usage example:
match that packet integrity checks are OK. The checks depend on
packet layers. For example ICMP packet will not check L4 level.
flow create 0 ingress pattern integrity value mask 0x01 value spec 0x01
Match that L4 packet is OK - check L2 & L3 & L4 layers:
flow create 0 ingress pattern integrity value mask 0xfe value spec 0xfe
Signed-off-by: Ori Kam <orika@nvidia.com>
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Right now, rte_flow_shared_action_* APIs are used for some shared
actions, like RSS, count. The shared action should be created before
using it inside a flow. These shared actions sometimes are not
really shared but just some indirect actions decoupled from a flow.
The new functions rte_flow_action_handle_* are added to replace
the current shared functions rte_flow_shared_action_*.
There are two types of flow actions:
1. the direct (normal) actions that could be created and stored
within a flow rule. Such action is tied to its flow rule and
cannot be reused.
2. the indirect action, in the past, named shared_action. It is
created from a direct actioni, like count or rss, and then used
in the flow rules with an object handle. The PMD will take care
of the retrieve from indirect action to the direct action
when it is referenced.
The indirect action is accessed (update / query) w/o any flow rule,
just via the action object handle. For example, when querying or
resetting a counter, it could be done out of any flow using this
counter, but only the handle of the counter action object is
required.
The indirect action object could be shared by different flows or
used by a single flow, depending on the direct action type and
the real-life requirements.
The handle of an indirect action object is opaque and defined in
each driver and possibly different per direct action type.
The old name "shared" is improper in a sense and should be replaced.
Since the APIs are changed from "rte_flow_shared_action*" to the new
"rte_flow_action_handle*", the testpmd application code and command
line interfaces also need to be updated to do the adaption.
The testpmd application user guide is also updated. All the "shared
action" related parts are replaced with "indirect action" to have a
correct explanation.
The parameter of "update" interface is also changed. A general
pointer will replace the rte_flow_action struct pointer due to the
facts:
1. Some action may not support fields updating. In the example of a
counter, the only "update" supported should be the reset. So
passing a rte_flow_action struct pointer is meaningless and
there is even no such corresponding action struct. What's more,
if more than one operations should be supported, for some other
action, such pointer parameter may not meet the need.
2. Some action may need conditional or partial update, the current
parameter will not provide the ability to indicate which part(s)
to update.
For different types of indirect action objects, the pointer could
either be the same of rte_flow_action* struct - in order not to
break the current driver implementation, or some wrapper
structures with bits as masks to indicate which part to be
updated, depending on real needs of the corresponding direct
action. For different direct actions, the structures of indirect
action objects updating will be different.
All the underlayer PMD callbacks will be moved to these new APIs.
The RTE_FLOW_ACTION_TYPE_SHARED is kept for now in order not to
break the ABI. All the implementations are changed by using
RTE_FLOW_ACTION_TYPE_INDIRECT.
Since the APIs are changed from "rte_flow_shared_action*" to the new
"rte_flow_action_handle*" and the "update" interface's 3rd input
parameter is changed to generic pointer, the mlx5 PMD that uses these
APIs needs to do the adaption to the new APIs as well.
Signed-off-by: Bing Zhao <bingz@nvidia.com>
Acked-by: Andrey Vesnovaty <andreyv@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Add support for single flow dump.
The CLIs to dump one rule: flow dump PORT rule ID
to dump all: flow dump PORT all
Examples:
testpmd> flow dump 0 all
testpmd> flow dump 0 rule 0
Signed-off-by: Haifei Luo <haifeil@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Add support for rte_flow_action_nvge_encap as a sample action.
The example of test-pmd command:
1. set nvgre ip-version ... tni ... ip-src ... ip-dst ...
set raw_encap 1 eth src... / ipv4... /...
set sample_actions 2 nvgre / port_id id 0 / end
flow create 0 ... pattern eth / end actions
sample ratio 1 index 2 / raw_encap index 1 / port_id id 0...
The flow will result in all the matched egress packets will be
encapsulated and sent to wire, and also mirrored the packets
using NVGRE encapsulation data and sent to wire.
Signed-off-by: Salem Sol <salems@nvidia.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Add support for rte_flow_action_vxlan_encap as a sample action.
The example of test-pmd command:
1. set vxlan ip-version ... vni ... udp-src ...
set raw_encap 1 eth src.../ ipv4.../...
set sample_actions 2 vxlan_encap / port_id id 0 / end
flow create 0 ... pattern eth / end actions
sample ratio 1 index 2 / raw_encap index 1 / port_id id 0...
The flow will result in all the matched egress packets will be
encapsulated and sent to wire, and also mirrored the packets
using VXLAN encapsulation data and sent to wire.
Signed-off-by: Salem Sol <salems@nvidia.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
With the current code the VXLAN/NVGRE parsing routine
stored the configuration of the header on stack, this
might lead to overwriting the data on the stack.
Currently having VXLAN/NVGRE encap as sample actions
is done using RAW_ENCAP, for example:
1. set raw_encap 1 eth src.../ vxlan vni.../ ipv4.../ ...
set sample_actions 0 raw_encap / port_id id 0 / end
flow create 0 ... pattern eth / end actions
sample ration 1 index 0 / jump group 1 / end
The goal is to utilize the rte_flow_action_vxlan_encap
and rte_flow_action_nvgre_encap for sample actions.
This patch prepares storing the external data of vxlan and
nvgre encap into global data as a pre-step to supporting
vxlan and nvgre encap as a sample actions.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
For NVGRE protocol, the default value of 'c_k_s_rsvd0_ver'
must be 0x2000, and protocol type must be 0x6558 in the NVGRE
header.
This patch updates these two configurations while parsing the nvgre
encap.
Fixes: dcd962fc6b4e ("app/testpmd: add NVGRE encap/decap")
Cc: stable@dpdk.org
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Add support to specify PF or VF as targets in "set sample_actions"
command.
Signed-off-by: Satheesh Paul <psatheesh@marvell.com>
Acked-by: Ori Kam <orika@nvidia.com>
When the RSS with null key was set in sample actions list, it
caused the segmentation fault since the RSS key pointer was
NULL while did the memory copy.
This patch adds the RSS key NULL pointer checking before copying
to fix the segmentation fault issue.
Fixes: 11b1b0eddade ("app/testpmd: support RSS in sample action")
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
IPv6 DSCP field ID is missing from the original list of Field IDs
for MODIFY_FIELD action. Add it to support IPv6 header fully.
Add ipv6_dscp option for the corresponding header field in testpmd.
Fixes: 73b68f4c54a0 ("ethdev: introduce generic modify flow action")
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Since the patch '1848b117' has initialized the variable 'key' in
'struct rte_flow_action_rss' with 'NULL', the PMD cannot get the
RSS key now. Details as bellow:
testpmd> flow create 0 ingress pattern eth / ipv4 / end actions
rss types ipv4-other end key
1234567890123456789012345678901234567890FFFFFFFFFFFF123
4567890123456789012345678901234567890FFFFFFFFFFFF
queues end / end
Flow rule #1 created
testpmd> show port 0 rss-hash key
RSS functions:
all ipv4-other ip
RSS key:
4439796BB54C5023B675EA5B124F9F30B8A2C03DDFDC4D02A08C9B3
34AF64A4C05C6FA343958D8557D99583AE138C92E81150366
This patch sets offset and size of the 'key' variable as the first
parameter of the token 'key'. Later, the address of the RSS key will
be copied to 'key' variable.
Fixes: 1848b117cca1 ("app/testpmd: fix RSS key for flow API RSS rule")
Cc: stable@dpdk.org
Signed-off-by: Alvin Zhang <alvinx.zhang@intel.com>
Tested-by: Jun W Zhou <junx.w.zhou@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Support rss action in the sample sub-actions list.
The examples for the sample flow use case and result as below:
set sample_actions 0 mark id 0x12 / rss queues 0 1 2 3 end / end
flow create 0 ingress group 1 pattern eth / end actions
sample ratio 1 index 0 / jump group 2 / end
This flow will result in all the matched ingress packets will be
jumped to next table, and the each packet will be marked with 0x12
and duplicated to rss queues of the control application.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Add support for the RTE_FLOW_ACTION_MODIFY_FIELD to the testpmd.
Implement CLI to create the modify_field action and supply all the
needed parameters to modify an arbitrary packet field (as well as
mark, tag or metadata) with data from another field or immediate
value.
Example of the flow is the following:
flow create 0 egress group 1 pattern eth / ipv4 / udp / end
actions modify_field op set dst_type tag dst_level 2 dst_offset 8
src_type gtp_teid src_level 0 src_offset 0 width 16 / end
This flow copies 16 bits from the second Tag in the Tags array
into the outermost GTP TEID packet header field. 8 bits of the
Tag are skipped as indicated by the dst_offset action parameter.
op, dst_type, src_type and width are the mandatory parameters to
specify. Levels and offset are 0 by default if they are not
overridden by a user. The operation can be set, add or sub.
Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
The patch adds the GENEVE rte flow option length support to
command line interpreter. The flow command with GENEVE
option items looks like:
flow create 0 ingress pattern eth / ipv4 / udp / geneve vni
is 100 optlen is 2 / end actions drop / end
The option length should be specified in 32-bit words, this
value specifies the all options length in the GENEVE header.
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
The patch adds the GENEVE option rte flow item support to
command line interpreter. The flow command with GENEVE
option items looks like:
flow create 0 ingress pattern eth / ipv4 / udp / geneve vni is 100 /
geneve-opt class is 99 length is 1 type is 0 data is 0x669988 /
end actions drop / end
The option length should be specified in 32-bit words, this
value specifies the length of the data pattern/mask arrays (should be
multiplied by sizeof(uint32_t) to be expressed in bytes. If match
on the length itself is not needed the mask should be set to zero, in
this case length is used to specify the pattern/mask array lengths only.
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
This patch add support for generating GTP PDU container
session option for the raw encap and raw decap sets.
The generated options is single 32-bit word with
minimal length specified as 4, no extra fields in the
option are supported. The option item must be preceded
with the GTP item itself, and GTP item flags must be
set accordingly:
- E flag must be set, we are going to provide extension
- S flag must be reset, because GTP item does not
provide the value for SQN field, we can't fill this one
- PN flag must be reset, no N-PDU value provided by
GTP item either
The raw set example:
set raw_encap 2 eth / ipv4 / udp /
gtp v_pt_rsv_flags is 0x34 / gtp_psc / end_set
Please, note - value 0x34 provides the required flag combination.
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
testpmd provides commands to test tunnel offload rte_flow
capabilities. Testpmd tunnel commands allow to configure new ofloaded
tunnel types, list existing offloaded tunnels and destroy existing
offloaded tunnels.
Tunnel offload commands allowed parameters repetition. For example,
the following commands were accepted:
testpmd> flow tunnel create 0 create 1 type vxlan
or
testpmd> flow tunnel list 0 list 1
Current patch fixed that fault. Correct tunnel commands syntax is:
testpmd> flow tunnel create <port> type <tunnel type>
testpmd> flow tunnel list <port>
testpmd> flow tunnel destroy <port> id <tunnel id>
Fixes: 1b9f274623b8 ("app/testpmd: add commands for tunnel offload")
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
cmdline_numtype member names clash with Windows system identifiers.
Add RTE_ prefix to cmdline constants to avoid this and possible
future conflicts.
Suggested-by: Ranjit Menon <ranjit.menon@intel.com>
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Ranjit Menon <ranjit.menon@intel.com>
Acked-by: Jie Zhou <jizh@microsoft.com>
Tested-by: Jie Zhou <jizh@microsoft.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
The rte_flow_item_eth and rte_flow_item_vlan items are refined.
The structs do not exactly represent the packet bits captured on the
wire anymore so set raw_encap/decap commands should only copy real
header instead of the whole struct.
Replace the rte_flow_item_* with the existing corresponding rte_*_hdr.
Fixes: 09315fc83861 ("ethdev: add VLAN attributes to ethernet and VLAN items")
Signed-off-by: Xiaoyu Min <jackmin@nvidia.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
This attribute helps PMDs to tell actions supposed to work
on the so-called hardware e-switch level from regular ones.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
In the current implementation of eCPRI flow item parsing of the CLI,
the token items in the list are not connected properly.
A command containing "rtc_ctrl rtc_id spec 14857 rtc_id mask 0xff00"
will be considered invalid. In order to support spec with mask, the
common entry needs to be typed twice and the whole command will be
too long.
By changing the token lists, it could support spec with mask without
backing from the entry of the item.
Fixes: 17d103cc9365 ("app/testpmd: add eCPRI in flow creation patterns")
Cc: stable@dpdk.org
Signed-off-by: Bing Zhao <bingz@nvidia.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
When a flow API RSS rule is issued in testpmd, device RSS key is changed
unexpectedly, device RSS key is changed to the testpmd default RSS key.
Consider the following usage with testpmd:
1. first, startup testpmd:
testpmd> show port 0 rss-hash key
RSS functions: all ipv4-frag ipv4-other ipv6-frag ipv6-other ip
RSS key: 6D5A56DA255B0EC24167253D43A38FB0D0CA2BCBAE7B30B477CB2DA38030F
20C6A42B73BBEAC01FA
2. create a rss rule
testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end \
actions rss types ipv4-udp end queues end / end
3. show rss-hash key
testpmd> show port 0 rss-hash key
RSS functions: all ipv4-udp udp
RSS key: 74657374706D6427732064656661756C74205253532068617368206B65792
C206F76657272696465
This is because testpmd always sends a key with the RSS rule,
if user provides a key as part of the rule that key is used, if user
doesn't provide a key, testpmd default key is sent to the PMDs, which is
causing device programmed RSS key to be changed.
There was a previous attempt to fix the same issue [1], but it has been
reverted back [2] because of the crash when 'key_len' is provided
without 'key'.
This patch follows the same approach with the initial fix [1] but also
addresses the crash.
After change, testpmd RSS key is 'NULL' by default, if user provides a
key as part of rule it is used, if not no key is sent to the PMDs at all
[1]
Commit a4391f8bae85 ("app/testpmd: set default RSS key as null")
[2]
Commit f3698c3d09a6 ("app/testpmd: revert setting default RSS")
Fixes: d0ad8648b1c5 ("app/testpmd: fix RSS flow action configuration")
Cc: stable@dpdk.org
Signed-off-by: Lijun Ou <oulijun@huawei.com>
Signed-off-by: Ophir Munk <ophirmu@mellanox.com>
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
rte_flow update introduced has_vlan field for ETH header item,
and field has_more_vlan for VLAN header item.
The new fields are used to clearly indicate packet tagging chrasteristics.
This patch updates testpmd CLI to support the new fields.
Signed-off-by: Dekel Peled <dekelp@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
rte_flow update, following RFC [1], added to ethdev the rte_flow item
ipv6_frag_ext.
This patch updates testpmd CLI to support the new item and its fields.
To match on fragmented IPv6 packets, this item is added to pattern:
... ipv6 / ipv6_frag_ext ...
[1] http://mails.dpdk.org/archives/dev/2020-March/160255.html
Signed-off-by: Dekel Peled <dekelp@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
rte_flow update, following RFC [1], introduced has_frag_ext field for
IPv6 header item, used to indicate match on fragmented/non-fragmented
packets.
This patch updates testpmd CLI to support the new field.
To match on non-fragmented IPv6 packets, need to use pattern:
... ipv6 has_frag_ext spec 0 has_frag_ext mask 1 ...
To match on fragmented IPv6 packets, need to use pattern:
... ipv6 has_frag_ext spec 1 has_frag_ext mask 1 ...
To match on any IPv6 packets, the has_frag_ext field should
not be specified for match.
[1] https://mails.dpdk.org/archives/dev/2020-August/177257.html
Signed-off-by: Dekel Peled <dekelp@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
This patch updates testpmd CLI to support fragment_offset field of
IPv4 header item.
To match on non-fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 0 fragment_offset mask 0x3fff ...
To match on fragmented IPv4 packets, need to use pattern:
... ipv4 fragment_offset spec 1 fragment_offset last 0x3fff
fragment_offset mask 0x3fff ...
(Use the full available range 1 to 0x3fff to include all possible
values.)
To match on any IPv4 packets, fragmented and non-fragmented,
the fragment_offset field should not be specified for match.
Signed-off-by: Dekel Peled <dekelp@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
This patch adds shared action support to testpmd CLI.
All shared actions created via testpmd CLI assigned ID for further
reference in other CLI commands. Shared action ID supplied as CLI
argument or assigned by testpmd is similar to flow ID & limited to
scope of testpdm CLI.
Create shared action syntax:
flow shared_action {port_id} create [action_id {shared_action_id}]
[ingress] [egress] action {action} / end
Create shared action examples:
flow shared_action 0 create action_id 100 \
ingress action rss queues 1 2 end / end
This creates shared rss action with id 100 on port 0.
flow shared_action 0 create action_id \
ingress action rss queues 0 1 end / end
This creates shared rss action with id assigned by testpmd
on port 0.
Update shared action syntax:
flow shared_action {port_id} update {shared_action_id}
action {action} / end
Update shared action example:
flow shared_action 0 update 100 \
action rss queues 0 3 end / end
This updates shared rss action having id 100 on port 0
with rss to queues 0 3 (in create example rss queues were
1 & 2).
Destroy shared action syntax:
flow shared_action {port_id} destroy action_id {shared_action_id} [...]
Destroy shared action example:
flow shared_action 0 destroy action_id 100 action_id 101
This destroys shared actions having id 100 & 101
Query shared action syntax:
flow shared_action {port} query {shared_action_id}
Query shared action example:
flow shared_action 0 query 100
This queries shared actions having id 100
Use shared action as flow action syntax:
flow create {port_id} ... / end actions [action / [...]]
shared {action_id} / [action / [...]] end
Use shared action as flow action example:
flow create 0 ingress pattern ... / end \
actions shared 100 / end
This creates flow rule where rss action is shared rss action
having id 100.
All shared action CLIs report status of the command.
Shared action query CLI output depends on action type.
Signed-off-by: Andrey Vesnovaty <andreyv@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Use sample action with ratio is 1 for mirroring flow, add
supports to set the different port or encap action for mirrored
packets.
The example of test-pmd command:
1. set sample_actions 1 port_id id 1 / end
flow create 0 ... pattern eth / end actions
sample ratio 1 index 1 / port_id id 2...
The flow will result in all the matched ingress packets will be sent to
port 2, and also mirrored the packets and sent to port 1.
2. set raw_encap 0 eth src.../ ipv4.../...
set raw_encap 1 eth src.../ ipv4.../...
set sample_actions 2 raw_encap index 0 / port_id id 0 / end
flow create 0 ... pattern eth / end actions
sample ratio 1 index 2 / raw_encap index 1 / port_id id 0...
The flow will result in all the matched egress packets will be
encapsulated and sent to wire, and also mirrored the packets and with
the different encapsulated data and sent to wire.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Add a new testpmd command 'set sample_actions' that supports the
multiple sample actions list configuration by using the index:
set sample_actions <index> <actions list>
The examples for the sample flow use case and result as below:
1. set sample_actions 0 mark id 0x8 / queue index 2 / end
.. pattern eth / end actions sample ratio 2 index 0 / jump group 2 ...
This flow will result in all the matched ingress packets will be
jumped to next flow table, and the each second packet will be
marked and sent to queue 2 of the control application.
2. ...pattern eth / end actions sample ratio 2 / port_id id 2 ...
The flow will result in all the matched ingress packets will be
duplicated and sent to the representor peer (VF or wire) on DPDK port 2,
and the each second packet will also be sent to E-Switch manager vport.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
This is a cleanup commit.
It assembles all tunnel outer updates into one function call to avoid
code duplications.
It defines RTE_VXLAN_GPE_DEFAULT_PORT (4790) in accordance with all
other tunnel protocol definitions.
It replaces all numeric values 4789 in their corresponding definition
RTE_VXLAN_GPE_DEFAULT_PORT.
It updates the 'csum parse-tunnel' documentation.
Signed-off-by: Ophir Munk <ophirmu@mellanox.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Ability to distinguish ICMP identifier fields in packets.
Distinguish ICMP sequence number field too.
Already supports ICMP code and type fields in current version.
Existing fields in ICMP header contain the required information.
ICMP header already is supported and no code change in RTE FLOW.
Extend testpmd CLI to include the fields of ident and sequence number.
One example:
flow create 0 ingress pattern eth / ipv4 /
icmp code is 1 ident is 5 seq is 6 /
end actions count / queue index 0 / end
The ICMP packet with code 1, identifier 5 and
sequence number 6 will be matched.
It will implement action counter and forward to queue 0.
Signed-off-by: Li Zhang <lizh@nvidia.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
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>
Currently, there is no way to check the aging event or to get the
current aged flows in testpmd, this patch include those implements, it's
included:
- Add new item "flow_aged" to the current print event command arguments.
- Add new command to list all aged flows, meanwhile, we can set
parameter to destroy it.
Signed-off-by: Dong Zhou <dongz@mellanox.com>
Acked-by: Matan Azrad <matan@mellanox.com>
Acked-by: Ori Kam <orika@mellanox.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
One of the reasons to destroy a flow is the fact that no packet matches
the flow for "timeout" time.
For example, when TCP\UDP sessions are suddenly closed.
Currently, there is not any DPDK mechanism for flow aging and the
applications use their own ways to detect and destroy aged-out flows.
The flow aging implementation need include:
- A new rte_flow action: RTE_FLOW_ACTION_TYPE_AGE to set the timeout and
the application flow context for each flow.
- A new ethdev event: RTE_ETH_EVENT_FLOW_AGED for the driver to report
that there are new aged-out flows.
- A new rte_flow API: rte_flow_get_aged_flows to get the aged-out flows
contexts from the port.
- Support input flow aging command line in Testpmd.
The new event type addition in the enum is flagged as an ABI breakage,
so an ignore rule is added for these reasons:
- It is not changing value of existing types (except MAX)
- The new value is not used by existing API if the event is not
registered
In general, it is safe adding new ethdev event types at the end of the
enum, because of event callback registration mechanism.
Signed-off-by: Dong Zhou <dongz@mellanox.com>
Acked-by: Ori Kam <orika@mellanox.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Matan Azrad <matan@mellanox.com>
The command line to create RTE flow for specific proto_id of PPPOES can
not work.
It was:
testpmd> flow create 0 ingress pattern proto_id
proto_id [TOKEN]: match PPPoE session protocol identifier
testpmd> flow create 0 ingress pattern proto_id proto_id
proto_id [TOKEN]: match PPPoE session protocol identifier
testpmd> flow create 0 ingress pattern proto_id proto_id proto_id
proto_id [TOKEN]: match PPPoE session protocol identifier
The proto_id can not be set with previous implementation.
This patch is to fix this issue, and change the command line to:
testpmd> flow create 0 pattern pppoe_proto_id is xxxx
Fixes: 226c6e60c35b ("ethdev: add PPPoE to flow API")
Cc: stable@dpdk.org
Signed-off-by: Xiao Zhang <xiao.zhang@intel.com>
Acked-by: Ori Kam <orika@mellanox.com>
This patch adds CLI option to enter the v_pt_rsv_flags value for GTP
flow pattern item.
It also adds GTP as valid item in raw_encap and raw_decap setting.
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Acked-by: Ori Kam <orika@mellanox.com>
This patch adds the new flow item RTE_FLOW_ITEM_TYPE_PFCP to flow API to
match a PFCP header.
Add sample PFCP rules for testpmd guide. Since Session Endpoint
Identifier (SEID) only will be present in PFCP Session header and PFCP
Session headers shall be identified when the S field is equal to 1, when
create rules for PFCP Session header with certain SEID the S field need
be set 1.
Signed-off-by: Xiao Zhang <xiao.zhang@intel.com>
Acked-by: Ori Kam <orika@mellanox.com>
Add AH and AH SPI to testpmd rte flow command line.
Add note and sample AH rules in testpmd guide.
Signed-off-by: Xiao Zhang <xiao.zhang@intel.com>
Acked-by: Ori Kam <orika@mellanox.com>
Some of the members of the MPLS struct are not initialized.
This commit init the uninitialized members.
Coverity issue: 325735
Fixes: 3e77031be855 ("app/testpmd: add MPLSoGRE encapsulation")
Cc: stable@dpdk.org
Signed-off-by: Ori Kam <orika@mellanox.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
New flow dump CLI to dump device internal representation information
of flows into screen.
Signed-off-by: Xueming Li <xuemingl@mellanox.com>
Signed-off-by: Xiaoyu Min <jackmin@mellanox.com>
Acked-by: Ori Kam <orika@mellanox.com>
This patch adds CLI option to enter the msg_type value for GTP
flow pattern item.
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Acked-by: Ori Kam <orika@mellanox.com>
add ITEM_ESP
add ITEM_ESP_SPI
update release notes for testpmd changes
add sample ESP rules in testpmd guide
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
Acked-by: Ori Kam <orika@mellanox.com>
This patch adds the new flow item RTE_FLOW_ITEM_TYPE_L2TPV3OIP to
flow API to match a L2TPv3 over IP header. This patch supports only
L2TPv3 over IP header format which is different to L2TPv2/L2TPv3
over UDP. The difference in header formats between L2TPv3 over IP
and L2TP over UDP require a separate implementation for each.
Signed-off-by: Rory Sexton <rory.sexton@intel.com>
Signed-off-by: Dariusz Jagus <dariuszx.jagus@intel.com>
Acked-by: Ori Kam <orika@mellanox.com>
Previous patch added support of GENEVE pattern item in flow rule.
Function flow_item_default_mask() was not updated, so using it with
GENEVE item returns null.
Using testpmd command "set raw_decap" or "set raw_encap" with
GENEVE item, without specifying any parameters, results in
segmentation fault.
This patch updates function flow_item_default_mask(),
adding case to handle GENEVE item.
Fixes: 0f4203fe9d18 ("app/testpmd: support GENEVE pattern item in flow rules")
Cc: stable@dpdk.org
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
Acked-by: Ori Kam <orika@mellanox.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
For some overlay network, such as VXLAN, the DSCP field in the new outer
IP header after VXLAN decapsulation may need to be updated accordingly.
This commit introduce the DSCP modify action for IPv4 and IPv6.
Signed-off-by: Suanming Mou <suanmingm@mellanox.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Acked-by: Ori Kam <orika@mellanox.com>
The IP's next protocol will be specified by user when set IP-in-IP
tunnel header via set raw decap/encap commands.
Currently this field is wrongly set to zero if there is no upper layer.
This leads to the encapsulated IP-in-IP tunnel header is not correct.
This next protocol field should be leave it as-is if there is no upper
layer or value is already set.
Fixes: 30626def03d6 ("app/testpmd: support raw encap/decap actions")
Cc: stable@dpdk.org
Signed-off-by: Xiaoyu Min <jackmin@mellanox.com>
Acked-by: Ori Kam <orika@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
