From: Shahaf Shuler <shahafs@mellanox.com>
To: Mordechay Haimovsky <motih@mellanox.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v3] net/mlx5: support e-switch TCP-flags flow filter
Date: Thu, 11 Oct 2018 05:22:32 +0000 [thread overview]
Message-ID: <DB7PR05MB44262A960805CD7479C26716C3E10@DB7PR05MB4426.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <1539182589-10533-1-git-send-email-motih@mellanox.com>
Hi Moti,
Wednesday, October 10, 2018 5:44 PM, Mordechay Haimovsky:
> Subject: [PATCH v3] net/mlx5: support e-switch TCP-flags flow filter
>
> This patch adds support for offloading flow rules with TCP-flags filter to mlx5
> eswitch Hardwrae.
>
> With mlx5 it is possible to offload a limited set of flow rules to the mlxsw (or
> e-switch) using the DPDK flow commands using the "transfer" attribute. This
> set of flow rules also supports filtering according to the values found in the
> TCP flags.
> This patch implements this offload capability in the mlx5 PMD under transfer
> attribute.
>
> Signed-off-by: Moti Haimovsky <motih@mellanox.com>
> ---
> v3:
> Changes according to review inputs.
> * Modified commit header.
> * Modified mason build to resemble the changes in Makefile.
> * Corrected TCP flags default support mask.
>
> v2:
> * Code rebase on latest upstream updates.
> ---
> drivers/net/mlx5/Makefile | 10 ++++++++++
> drivers/net/mlx5/meson.build | 4 ++++
> drivers/net/mlx5/mlx5_flow.c | 12 +++++++++++-
> drivers/net/mlx5/mlx5_flow.h | 1 +
> drivers/net/mlx5/mlx5_flow_dv.c | 3 ++-
> drivers/net/mlx5/mlx5_flow_tcf.c | 26 ++++++++++++++++++++++++--
> drivers/net/mlx5/mlx5_flow_verbs.c | 3 ++-
> 7 files changed, 54 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile index
> ca1de9f..9097456 100644
> --- a/drivers/net/mlx5/Makefile
> +++ b/drivers/net/mlx5/Makefile
> @@ -342,6 +342,16 @@ mlx5_autoconf.h.new: $(RTE_SDK)/buildtools/auto-
> config-h.sh
> enum TCA_FLOWER_KEY_VLAN_ETH_TYPE \
> $(AUTOCONF_OUTPUT)
> $Q sh -- '$<' '$@' \
> + HAVE_TCA_FLOWER_KEY_TCP_FLAGS \
> + linux/pkt_cls.h \
> + enum TCA_FLOWER_KEY_TCP_FLAGS \
> + $(AUTOCONF_OUTPUT)
> + $Q sh -- '$<' '$@' \
> + HAVE_TCA_FLOWER_KEY_TCP_FLAGS_MASK \
> + linux/pkt_cls.h \
> + enum TCA_FLOWER_KEY_TCP_FLAGS_MASK \
> + $(AUTOCONF_OUTPUT)
> + $Q sh -- '$<' '$@' \
> HAVE_TC_ACT_VLAN \
> linux/tc_act/tc_vlan.h \
> enum TCA_VLAN_PUSH_VLAN_PRIORITY \
> diff --git a/drivers/net/mlx5/meson.build b/drivers/net/mlx5/meson.build
> index fd93ac1..f562f30 100644
> --- a/drivers/net/mlx5/meson.build
> +++ b/drivers/net/mlx5/meson.build
> @@ -180,6 +180,10 @@ if build
> 'TCA_FLOWER_KEY_VLAN_PRIO' ],
> [ 'HAVE_TCA_FLOWER_KEY_VLAN_ETH_TYPE',
> 'linux/pkt_cls.h',
> 'TCA_FLOWER_KEY_VLAN_ETH_TYPE' ],
> + [ 'HAVE_TCA_FLOWER_KEY_TCP_FLAGS', 'linux/pkt_cls.h',
> + 'TCA_FLOWER_KEY_TCP_FLAGS' ],
> + [ 'HAVE_TCA_FLOWER_KEY_TCP_FLAGS_MASK',
> 'linux/pkt_cls.h',
> + 'TCA_FLOWER_KEY_TCP_FLAGS_MASK' ],
> [ 'HAVE_TC_ACT_VLAN', 'linux/tc_act/tc_vlan.h',
> 'TCA_VLAN_PUSH_VLAN_PRIORITY' ],
> [ 'HAVE_RDMA_NL_NLDEV', 'rdma/rdma_netlink.h', diff --git
> a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c index
> ed60c40..74e7251 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -1226,6 +1226,8 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> * Bit-fields that holds the items detected until now.
> * @param[in] target_protocol
> * The next protocol in the previous item.
> + * @param[in] flow_mask
> + * mlx5 flow-specific (TCF, DV, verbs, etc.) supported header fields mask.
> * @param[out] error
> * Pointer to error structure.
> *
> @@ -1236,9 +1238,17 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority, mlx5_flow_validate_item_tcp(const
> struct rte_flow_item *item,
> uint64_t item_flags,
> uint8_t target_protocol,
> + const struct tcp_hdr *flow_mask,
This is not what I meant.
Have a look on the different flow engines we have. To validate TCP each one of them is calling the general, fits all, mlx5_flow_validate_item_tcp. if there is a specific, engine unique, logic for the validation it
Is done after it. See example on the TCF engine.
The same should be with the TCP flags. The mlx5_flow_validate_item_tcp remains the same as today, just checks the common stuff.
The verbs and dv flow engine should have an extra check after it that the TCP flags are not part of the mask.
The TCF should not check it, as it is supported.
> struct rte_flow_error *error)
> {
> const struct rte_flow_item_tcp *mask = item->mask;
> + const struct tcp_hdr default_mask = {
> + .src_port = RTE_BE16(0xffff),
> + .dst_port = RTE_BE16(0xffff),
> + };
> + const struct rte_flow_item_tcp nic_mask = {
> + .hdr = flow_mask ? *flow_mask : default_mask,
> + };
> const int tunnel = !!(item_flags & MLX5_FLOW_LAYER_TUNNEL);
> int ret;
>
> @@ -1261,7 +1271,7 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> mask = &rte_flow_item_tcp_mask;
> ret = mlx5_flow_item_acceptable
> (item, (const uint8_t *)mask,
> - (const uint8_t *)&rte_flow_item_tcp_mask,
> + (const uint8_t *)&nic_mask,
> sizeof(struct rte_flow_item_tcp), error);
> if (ret < 0)
> return ret;
> diff --git a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h
> index 12de841..da114ca 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -314,6 +314,7 @@ int mlx5_flow_validate_item_mpls(const struct
> rte_flow_item *item, int mlx5_flow_validate_item_tcp(const struct
> rte_flow_item *item,
> uint64_t item_flags,
> uint8_t target_protocol,
> + const struct tcp_hdr *flow_mask,
> struct rte_flow_error *error);
> int mlx5_flow_validate_item_udp(const struct rte_flow_item *item,
> uint64_t item_flags,
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index 3bb462c..b878cc0 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -180,7 +180,8 @@
> break;
> case RTE_FLOW_ITEM_TYPE_TCP:
> ret = mlx5_flow_validate_item_tcp(items,
> item_flags,
> - next_protocol,
> error);
> + next_protocol,
> + NULL, error);
> if (ret < 0)
> return ret;
> item_flags |= tunnel ?
> MLX5_FLOW_LAYER_INNER_L4_TCP :
> diff --git a/drivers/net/mlx5/mlx5_flow_tcf.c
> b/drivers/net/mlx5/mlx5_flow_tcf.c
> index 91f6ef6..22b23a4 100644
> --- a/drivers/net/mlx5/mlx5_flow_tcf.c
> +++ b/drivers/net/mlx5/mlx5_flow_tcf.c
> @@ -148,6 +148,12 @@ struct tc_vlan {
> #ifndef HAVE_TCA_FLOWER_KEY_VLAN_ETH_TYPE #define
> TCA_FLOWER_KEY_VLAN_ETH_TYPE 25 #endif
> +#ifndef HAVE_TCA_FLOWER_KEY_TCP_FLAGS
> +#define TCA_FLOWER_KEY_TCP_FLAGS 71
> +#endif
> +#ifndef HAVE_TCA_FLOWER_KEY_TCP_FLAGS_MASK
> +#define TCA_FLOWER_KEY_TCP_FLAGS_MASK 72 #endif
>
> #ifndef IPV6_ADDR_LEN
> #define IPV6_ADDR_LEN 16
> @@ -204,6 +210,7 @@ struct tc_vlan {
> .tcp.hdr = {
> .src_port = RTE_BE16(0xffff),
> .dst_port = RTE_BE16(0xffff),
> + .tcp_flags = 0xff,
> },
> .udp.hdr = {
> .src_port = RTE_BE16(0xffff),
> @@ -626,8 +633,11 @@ struct flow_tcf_ptoi {
> return -rte_errno;
> break;
> case RTE_FLOW_ITEM_TYPE_TCP:
> - ret = mlx5_flow_validate_item_tcp(items,
> item_flags,
> - next_protocol,
> error);
> + ret = mlx5_flow_validate_item_tcp
> + (items, item_flags,
> + next_protocol,
> +
> &flow_tcf_mask_supported.tcp.hdr,
> + error);
> if (ret < 0)
> return ret;
> item_flags |= MLX5_FLOW_LAYER_OUTER_L4_TCP;
> @@ -1289,6 +1299,18 @@ struct flow_tcf_ptoi {
>
> TCA_FLOWER_KEY_TCP_DST_MASK,
> mask.tcp->hdr.dst_port);
> }
> + if (mask.tcp->hdr.tcp_flags) {
> + mnl_attr_put_u16
> + (nlh,
> + TCA_FLOWER_KEY_TCP_FLAGS,
> + rte_cpu_to_be_16
> + (spec.tcp->hdr.tcp_flags));
> + mnl_attr_put_u16
> + (nlh,
> +
> TCA_FLOWER_KEY_TCP_FLAGS_MASK,
> + rte_cpu_to_be_16
> + (mask.tcp->hdr.tcp_flags));
> + }
> break;
> default:
> return rte_flow_error_set(error, ENOTSUP, diff --git
> a/drivers/net/mlx5/mlx5_flow_verbs.c
> b/drivers/net/mlx5/mlx5_flow_verbs.c
> index 6964476..3d68f8b 100644
> --- a/drivers/net/mlx5/mlx5_flow_verbs.c
> +++ b/drivers/net/mlx5/mlx5_flow_verbs.c
> @@ -1057,7 +1057,8 @@
> break;
> case RTE_FLOW_ITEM_TYPE_TCP:
> ret = mlx5_flow_validate_item_tcp(items,
> item_flags,
> - next_protocol,
> error);
> + next_protocol,
> + NULL, error);
> if (ret < 0)
> return ret;
> item_flags |= tunnel ?
> MLX5_FLOW_LAYER_INNER_L4_TCP :
> --
> 1.8.3.1
next prev parent reply other threads:[~2018-10-11 5:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-13 10:30 [dpdk-dev] [PATCH] " Moti Haimovsky
2018-10-09 11:17 ` [dpdk-dev] [PATCH v2] " Mordechay Haimovsky
2018-10-09 13:08 ` Shahaf Shuler
2018-10-10 14:43 ` [dpdk-dev] [PATCH v3] " Mordechay Haimovsky
2018-10-11 5:22 ` Shahaf Shuler [this message]
2018-10-11 10:48 ` [dpdk-dev] [PATCH v4] " Mordechay Haimovsky
2018-10-11 12:30 ` Shahaf Shuler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DB7PR05MB44262A960805CD7479C26716C3E10@DB7PR05MB4426.eurprd05.prod.outlook.com \
--to=shahafs@mellanox.com \
--cc=dev@dpdk.org \
--cc=motih@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).