summaryrefslogtreecommitdiff
path: root/drivers/net/mlx5
AgeCommit message (Collapse)Author
2019-11-11net/mlx5: support meter profile updateSuanming Mou
This commit add the meter profile update support. New internal function in rte_mtr_ops callback: 1. meter_profile_update() Signed-off-by: Suanming Mou <suanmingm@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: support meter modification operationsSuanming Mou
This commit add meter enable and disable supoort. New internal functions in rte_mtr_ops callback: 1. meter_enable() 2. meter_disable() The meter_enable() enables the meter action and the meter_disable() disables the meter action. Signed-off-by: Suanming Mou <suanmingm@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: add meter action creation to the glueSuanming Mou
This commit add the meter action creation to the glue code. Signed-off-by: Suanming Mou <suanmingm@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: support basic meter operationsSuanming Mou
This commit add the basic meter operations for meter create and destroy. New internal functions in rte_mtr_ops callback: 1. create() 2. destroy() The create() callback will create the corresponding flow rules on the meter table. The destroy() callback destroys the flow rules on the meter table. Signed-off-by: Suanming Mou <suanmingm@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: add policer rules operationsSuanming Mou
This commit create the color rules on the meter table for the packets. As the prefix flow with meter action colors the packets, the packets are transferred to the meter table with meter color match flows. Here we create the flow rules with green yellow red actions on the meter table. Packets match the color will be processed by the related color flow rule. Signed-off-by: Suanming Mou <suanmingm@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: prepare meter flow tablesSuanming Mou
This commit prepare the meter table and suffix table. A flow with meter will be split to three flows. The three flows are created on differnet tables. The packets transfer between the flows on the tables as below: Prefix flow -> Meter flow -> Suffix flow Prefix flow does the user defined match and the meter action. The meter action colors the packet and set its destination to meter table to be processed by the meter flow. The meter flow judges if the packet can be passed or not. If packet can be passed, it will be transferred to the suffix table. The suffix flow on the suffix table will apply the left user defined actions to the packet. The ingress egress and transfer all have the independent meter and suffix tables. Signed-off-by: Suanming Mou <suanmingm@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: validate meter profileSuanming Mou
The add meter profile should be validated if it is valid or has been add to the list. Invalid and exist profile should not be add to the list. Signed-off-by: Suanming Mou <suanmingm@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: support meter profile operationsSuanming Mou
This commit add the support of meter profile add and delete operations. New internal functions in rte_mtr_ops callback: 1. meter_profile_add() 2. meter_profile_delete() Only RTE_MTR_SRTCM_RFC2697 algorithm is supported and can be added. To add other algorithm will report an error. Signed-off-by: Suanming Mou <suanmingm@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: allocate flow meter registersSuanming Mou
Meter need the metadata REG_C to have the color match between the prefix flow and the meter flow. As the user define or metadata feature will both use the REG_C in the suffix flow, the color match register meter uses will not impact the register use in the later sub flow. Another case is that tag is add before meter flow. In this case, meter should not touch the register the tag action is using. To avoid that case, meter should reserve the REG_C's used by user defined MLX5_APP_TAG. Signed-off-by: Suanming Mou <suanmingm@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: fill meter capabilities using DevXSuanming Mou
This commit add the support of fill and get the meter capabilities from DevX. Support items: 1. The srTCM color bind mode. 2. Meter share with multiple flows. 3. Action drop. The color aware mode and multiple meter chaining in a flow are not supported. New internal function in rte_mtr_ops callback: 1. capabilities_get() Signed-off-by: Suanming Mou <suanmingm@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: add meter operation callbackSuanming Mou
Add the new mlx5_flow_meter.c file for metering support. Signed-off-by: Suanming Mou <suanmingm@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: fix condition to create default ruleDekel Peled
Previous patch added creation of a default flow rule on port start. Rule is created under the condition that device is in eswitch mode, and is not a VF, to make sure rule is created only once. In Bluefield, where PF representor is used, this condition is not sufficient. Rule is created twice, causing loss of traffic. This patch updates this condition, adding check that device is also not a representor. Fixes: b67b4ecbde22 ("net/mlx5: skip table zero to improve insertion rate") Signed-off-by: Dekel Peled <dekelp@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-11net/mlx5: allow jump to group lower than currentDekel Peled
In current implementation, jump action is allowed only if target group is higher than the current flow group, This patch updates function flow_dv_validate_action_jump() to allow jump action if target group is higher or lower than the current flow group. Target group equal to current flow group is still rejected. Signed-off-by: Dekel Peled <dekelp@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-11net/mlx5: add metadata register copy tableViacheslav Ovsiienko
While reg_c[meta] can be copied to reg_b simply by modify-header action (it is supported by hardware), it is not possible to copy reg_c[mark] to the STE flow_tag as flow_tag is not a metadata register and this is not supported by hardware. Instead, it should be manually set by a flow per each unique MARK ID. For this purpose, there should be a dedicated flow table - RX_CP_TBL and all the Rx flow should pass by the table to properly copy values from the register to flow tag field. And for each MARK action, a copy flow should be added to RX_CP_TBL according to the MARK ID like: (if reg_c[mark] == mark_id), flow_tag := mark_id / reg_b := reg_c[meta] / jump to RX_ACT_TBL For SET_META action, there can be only one default flow like: reg_b := reg_c[meta] / jump to RX_ACT_TBL Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: split Rx flows to provide metadata copyViacheslav Ovsiienko
Values set by MARK and SET_META actions should be carried over to the VF representor in case of flow miss on Tx path. However, as not all metadata registers are preserved across the different domains (NIC Rx/Tx and E-Switch FDB), as a workaround, those values should be carried by reg_c's which are preserved across domains and copied to STE flow_tag (MARK) and reg_b (META) fields in the last stage of flow steering, in order to scatter those values to flow_tag and flow_table_metadata of CQE. While reg_c[meta] can be copied to reg_b simply by modify-header action (it is supported by hardware), it is not possible to copy reg_c[mark] to the STE flow_tag as flow_tag is not a metadata register and this is not supported by hardware. Instead, it should be manually set by a flow per MARK ID. For this purpose, there should be a dedicated flow table - RX_CP_TBL and all the Rx flow should pass by the table to properly copy values. As the last action of Rx flow steering must be a terminal action such as QUEUE, RSS or DROP, if a user flow has Q/RSS action, the flow must be split in order to pass by the RX_CP_TBL. And the remained Q/RSS action will be performed by another dedicated action table - RX_ACT_TBL. For example, for an ingress flow: pattern, actions_having_QRSS it must be split into two flows. The first one is, pattern, actions_except_QRSS / copy (reg_c[2] := flow_id) / jump to RX_CP_TBL and the second one in RX_ACT_TBL. (if reg_c[2] == flow_id), action_QRSS where flow_id is uniquely allocated and managed identifier. This patch implements the Rx flow splitting and build the RX_ACT_TBL. Also, per each egress flow on NIC Tx, a copy action (reg_c[]= reg_a) should be added in order to transfer metadata from WQE. Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: introduce flow splitters chainViacheslav Ovsiienko
The mlx5 hardware has some limitations and flow might require to be split into multiple internal subflows. For example this is needed to provide the meter object sharing between multiple flows or to provide metadata register copying before final queue/rss action. The multiple features might require several level of splitting. For example, hairpin feature splits the original flow into two ones - rx and tx parts. Then RSS feature should split rx part into multiple subflows with extended item sets. Then, metering feature might require splitting each RSS subflow into meter jump chain, and then metadata extensive support might require the final subflows splitting. So, we have to organize the chain of splitting subroutines to abstract each level of splitting. Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: add metadata support to Rx datapathViacheslav Ovsiienko
This patch moves metadata from completion descriptor to appropriate dynamic mbuf field. Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: extend flow metadata supportViacheslav Ovsiienko
META item is supported on both Rx and Tx. 'transfer' attribute is also supported. SET_META action is also added. Due to restriction on reg_c[meta], various bit width might be available. If devarg parameter dv_xmeta_en=1, the META uses metadata register reg_c[0], which may be required for internal kernel or firmware needs. In this case PMD queries kernel about available fields in reg_c[0] and restricts the register usage accordingly. If devarg parameter dv_xmeta_en=2, the META feature uses reg_c[1], there should be no limitations on the data width. However, extensive MEAT feature is currently disabled until register copy on loopback is supported by forthcoming patches. Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: extend flow mark supportViacheslav Ovsiienko
Flow MARK item is newly supported along with MARK action. MARK action and item are supported on both Rx and Tx. It works on the metadata reg_c[] only if extensive flow metadata register is supported. Without the support, MARK action behaves same as before - valid only on Rx and no MARK item is valid. FLAG action is also modified accordingly. FLAG action is supported on both Rx and Tx via reg_c[] if extensive flow metadata register is supported. However, the new MARK/FLAG item and action are currently disabled until register copy on loopback is supported by forthcoming patches. The actual index of engaged metadata reg_c[] register to support FLAG/MARK actions depends on dv_xmeta_en devarg value. For extensive metadata mode 1 the reg_c[1] is used and transitive MARK data width is 24. For extensive metadata mode 2 the reg_c[0] is used and transitive MARK data width might be restricted to 0 or 16 bits, depending on kernel usage of reg_c[0]. The actual supported width can be discovered by series of trials with rte_flow_validate(). Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: support flow tagViacheslav Ovsiienko
Add support of new rte_flow item and action - TAG and SET_TAG. TAG is a transient value which can be kept during flow matching. This is supported through device metadata register reg_c[]. Although there are 8 registers are available on the current mlx5 device, some of them can be reserved for firmware or kernel purposes. The availability should be queried by iterative trial-and-error mlx5_flow_discover_mreg_c() routine. Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: update metadata register ID queryViacheslav Ovsiienko
The NIC might support up to 8 extensive metadata registers. These registers are supposed to be used by multiple features. There is register id query routine to allow determine which register is actually used by specified feature. Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: check maximum modify actions numberViacheslav Ovsiienko
If the extensive metadata registers are supported, it can be regarded inclusively that the extensive metadata support is possible. E.g. metadata register copy action, supporting 16 modify header actions, reserving register across different steering domain (FDB and NIC) and so on. This patch handles the maximal amount of header modify actions depending on discovered metadata registers support. Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: adjust shared register according to maskViacheslav Ovsiienko
The metadata register reg_c[0] might be used by kernel or firmware for their internal purposes. The actual used mask can be queried from the kernel. The remaining bits can be used by PMD to provide META or MARK feature. The code queries the mask of reg_c[0] and adjust the resource usage dynamically. Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: add devarg for extensive metadata supportViacheslav Ovsiienko
The PMD parameter dv_xmeta_en is added to control extensive metadata support. A nonzero value enables extensive flow metadata support if device is capable and driver supports it. This can enable extensive support of MARK and META item of rte_flow. The newly introduced SET_TAG and SET_META actions do not depend on dv_xmeta_en parameter, because there is no compatibility issue for new entities. The dv_xmeta_en is disabled by default. There are some possible configurations, depending on parameter value: - 0, this is default value, defines the legacy mode, the MARK and META related actions and items operate only within NIC Tx and NIC Rx steering domains, no MARK and META information crosses the domain boundaries. The MARK item is 24 bits wide, the META item is 32 bits wide. - 1, this engages extensive metadata mode, the MARK and META related actions and items operate within all supported steering domains, including FDB, MARK and META information may cross the domain boundaries. The ``MARK`` item is 24 bits wide, the META item width depends on kernel and firmware configurations and might be 0, 16 or 32 bits. Within NIC Tx domain META data width is 32 bits for compatibility, the actual width of data transferred to the FDB domain depends on kernel configuration and may be vary. The actual supported width can be retrieved in runtime by series of rte_flow_validate() trials. - 2, this engages extensive metadata mode, the MARK and META related actions and items operate within all supported steering domains, including FDB, MARK and META information may cross the domain boundaries. The META item is 32 bits wide, the MARK item width depends on kernel and firmware configurations and might be 0, 16 or 24 bits. The actual supported width can be retrieved in runtime by series of rte_flow_validate() trials. If there is no E-Switch configuration the ``dv_xmeta_en`` parameter is ignored and the device is configured to operate in legacy mode (0). Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: check metadata registers availabilityViacheslav Ovsiienko
The metadata registers reg_c provide support for TAG and SET_TAG features. Although there are 8 registers are available on the current mlx5 devices, some of them can be reserved. The availability should be queried by iterative trial-and-error implemented by mlx5_flow_discover_mreg_c() routine. If reg_c is available, it can be regarded inclusively that the extensive metadata support is possible. E.g. metadata register copy action, supporting 16 modify header actions (instead of 8 by default) preserving register across different domains (FDB and NIC) and so on. Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: rename structure and functionViacheslav Ovsiienko
There are some renaming: - in the DV flow engine overall: flow_d_* -> flow_dv_* - in flow_dv_translate(): res -> mhdr_res Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: update meta register matcher setViacheslav Ovsiienko
Introduce the dedicated matcher register field setup routine. Update the code to use this unified one. Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: update flow functionsViacheslav Ovsiienko
Update flow creation/destroy functions for future reuse. List operations can be skipped inside functions and done separately out of flow creation. Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: refactor flow structureViacheslav Ovsiienko
Some rte_flow fields which are local to subflows have been moved to mlx5_flow structure. RSS attributes are grouped by mlx5_flow_rss structure. tag_resource is moved to mlx5_flow_dv structure. Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: add metadata register copyViacheslav Ovsiienko
Add flow metadata register copy action which is supported through modify header command. As it is an internal action, not exposed to users, item type (MLX5_RTE_FLOW_ACTION_TYPE_COPY_MREG) is negative value. This can be used when creating PMD internal subflows. Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: update modify header action translatorViacheslav Ovsiienko
When composing device command for modify header action, provided mask should be taken more accurate into account thus length and offset in action should be set accordingly at precise bit-wise boundaries. For the future use, metadata register copy action is also added. Signed-off-by: Yongseok Koh <yskoh@mellanox.com> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: convert internal tag endiannessViacheslav Ovsiienko
Public API RTE_FLOW_ACTION_TYPE_TAG and RTE_FLOW_ITEM_TYPE_TAG present data in host-endian format, as all metadata related entities. The internal mlx5 tag related action and item should use the same endianness to be conformed. Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-11net/mlx5: introduce hash listBing Zhao
Introduce simple hash list to the mlx5 utilities. User can define its own data structure containing the mlx5_hlist_entry and create the hash list table via the creation interface. Then the entry will be inserted into the table and linked to the corresponding list head. User should guarantee there is no collision of the key and provide a callback function to handle all the remaining entries in the table when destroying the hash list. User should define a proper number of the list heads in the table in order to get a better performance. The LSB of the 'key' is used to calculate the index of the head in the list heads array. This implementation is not multi-threads safe right now. Signed-off-by: Bing Zhao <bingz@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: add missing packet type for GENEVEWisam Jaddo
HW ptype are missing TUNNEL_GENEVE support Fixes: e59a5dbcfd07 ("net/mlx5: add flow match on GENEVE item") Signed-off-by: Wisam Jaddo <wisamm@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: allow pattern start from IPXiaoyu Min
Some applications, i.e. OVS, have rule like: [1] pattern ipv4 / end actions ... which intends to match ipv4 only on non-vlan ethernet and MLX5 NIC supports this. So PMD should accept this. Fixes: 906a2efae8da ("net/mlx5: validate flow rule item order") 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>
2019-11-08net/mlx5: improve flow item IP validationXiaoyu Min
Currently PMD doesn't check whether the user specified ethernet type is conflicting with the followed IPv4/IPv6 items, which leads to HW refuse to create rule, for example: ... pattern eth type is 0x86dd / ipv4 / end ... ethernet type is IPv6 but IPv4 is following, this should be validated as failure and report corresponding error in detail. Fixes: 23c1d42c7138 ("net/mlx5: split flow validation to dedicated function") Cc: stable@dpdk.org Signed-off-by: Xiaoyu Min <jackmin@mellanox.com> Acked-by: Ori Kam <orika@mellanox.com>
2019-11-08net/mlx5: add ConnectX6-DX device IDRaslan Darawsheh
This adds new device id to the list of Mellanox devices that runs mlx5 PMD. - ConnectX-6DX device ID - ConnectX-6DX SRIOV device ID Signed-off-by: Raslan Darawsheh <rasland@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08ethdev: move egress metadata to dynamic fieldViacheslav Ovsiienko
The dynamic mbuf fields were introduced by [1]. The egress metadata is good candidate to be moved from statically allocated field tx_metadata to dynamic one. Because mbufs are used in half-duplex fashion only, it is safe to share this dynamic field with ingress metadata. The shared dynamic field contains either egress (if application going to transmit mbuf with tx_burst) or ingress (if mbuf is received with rx_burst) metadata and can be accessed by RTE_FLOW_DYNF_METADATA() macro or with rte_flow_dynf_metadata_set() and rte_flow_dynf_metadata_get() helper routines. PKT_TX_DYNF_METADATA/PKT_RX_DYNF_METADATA flag will be set along with the data. The mbuf dynamic field must be registered by calling rte_flow_dynf_metadata_register() prior accessing the data. The availability of dynamic mbuf metadata field can be checked with rte_flow_dynf_metadata_avail() routine. DEV_TX_OFFLOAD_MATCH_METADATA offload and configuration flag is removed. The metadata support in PMDs is engaged on dynamic field registration. Metadata feature is getting complex. We might have some set of actions and items that might be supported by PMDs in multiple combinations, the supported values and masks are the subjects to query by perfroming trials (with rte_flow_validate). [1] http://patches.dpdk.org/patch/62040/ Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com> Acked-by: Olivier Matz <olivier.matz@6wind.com> Acked-by: Ori Kam <orika@mellanox.com>
2019-11-08net/mlx5: check port ID and VLAN actions orderingXiaoyu Min
Rdma-core needs the dst_vport (port_id) action be after push/pop VLAN and modify hdr actions otherwise it will reject to create rule. This pach validates the port_id is after push/pop VLAN and set VLAN VID/PCP otherwise PMD spits out errors. Fixes: 5f163d520cff ("net/mlx5: support modify VLAN ID on existing VLAN header") Signed-off-by: Xiaoyu Min <jackmin@mellanox.com> Acked-by: Matan Azrad <matan@mellanox.com>
2019-11-08net/mlx5: fix set VLAN ID/PCP in new headerXiaoyu Min
Currently if user want to set VLAN id/pcp on an about to be pushed VLAN header, the of_set_vlan_vid/of_set_vlan_pcp must be present _before_ action of_push_vlan: [1] ... actions of_set_vlan_vid vlan_vid 2 / of_push_vlan ... This is misleading because people think rule [1] intends to set VLAN id on the existing VLAN header and then push one new VLAN header on top of it. A more natual way to set VLAN id/pcp on an to be pushed VLAN header should be: [2] ... actions of_push_vlan / of_set_vlan_vid vlan_vid 2 / ... Fixes: a5f2da0b816b ("net/mlx5: support modify VLAN ID on new VLAN header") Fixes: 68fad3635042 ("net/mlx5: support modifying VLAN priority on VLAN header") Signed-off-by: Xiaoyu Min <jackmin@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: remove redundant new line in logsDekel Peled
DRV_LOG macro is used to print log messages, one per line. In several locations this macro is used with redundant '\n' character at the end of the log message, causing blank lines between log lines. This patch removes the '\n' character where it is redundant. Signed-off-by: Dekel Peled <dekelp@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: split hairpin flowsOri Kam
Since the encap action is not supported in RX, we need to split the hairpin flow into RX and TX. Signed-off-by: Ori Kam <orika@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: add default flows for hairpinOri Kam
When using hairpin all traffic from TX hairpin queues should jump to dedecated table where matching can be done using regesters. Signed-off-by: Ori Kam <orika@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: add ID generationOri Kam
When splitting flows for example in hairpin / metering, there is a need to combine the flows. This is done using ID. This commit introduce a simple way to generate such IDs. The reason why bitmap was not used is due to fact that the release and allocation are O(n) while in the chosen approch the allocation and release are O(1) Signed-off-by: Ori Kam <orika@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: add internal tag item and actionOri Kam
This commit introduce the setting and matching on registers. This item and and action will be used with number of different features like hairpin, metering, metadata. Signed-off-by: Ori Kam <orika@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: support RSS on hairpinOri Kam
Add support for rss on hairpin queues. Signed-off-by: Ori Kam <orika@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: add hairpin binding functionOri Kam
When starting the port, in addition to creating the queues we need to bind the hairpin queues. Signed-off-by: Ori Kam <orika@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: get hairpin capabilitiesOri Kam
This commits adds the hairpin get capabilities function. Signed-off-by: Ori Kam <orika@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: support Tx hairpin queuesOri Kam
This commit adds the support for creating Tx hairpin queues. Hairpin queue is a queue that is created using DevX and only used by the HW. Signed-off-by: Ori Kam <orika@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
2019-11-08net/mlx5: prepare Tx queues to have different typesOri Kam
Currently all Tx queues are created using Verbs. This commit modify the naming so it will not include verbs, since in next commit a new type will be introduce (hairpin) Signed-off-by: Ori Kam <orika@mellanox.com> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>