From: Saeed Mahameed <saeed@kernel.org>
To: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, Tariq Toukan <tariqt@nvidia.com>,
Paul Blakey <paulb@nvidia.com>,
Saeed Mahameed <saeedm@nvidia.com>
Subject: [net-next V2 02/15] net/mlx5: CT: Avoid reusing modify header context for natted entries
Date: Thu, 27 May 2021 11:56:11 -0700 [thread overview]
Message-ID: <20210527185624.694304-3-saeed@kernel.org> (raw)
In-Reply-To: <20210527185624.694304-1-saeed@kernel.org>
From: Paul Blakey <paulb@nvidia.com>
Currently the driver is designed to reuse header modify context entries.
Natted entries will always have a unique modify header, as such the
modify header hashtable lookup is introducing an overhead. When the
hashtable size exceeded 200k entries the tested insertion rate dropped
from ~10k entries/sec to ~300 entries/sec.
Don't use the re-use mechanism when creating modify headers
for natted tuples.
Signed-off-by: Paul Blakey <paulb@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
.../ethernet/mellanox/mlx5/core/en/tc_ct.c | 50 ++++++++++++++-----
1 file changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c
index edf19f1c19ff..e3b0fd78184e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c
@@ -150,6 +150,11 @@ struct mlx5_ct_entry {
unsigned long flags;
};
+static void
+mlx5_tc_ct_entry_destroy_mod_hdr(struct mlx5_tc_ct_priv *ct_priv,
+ struct mlx5_flow_attr *attr,
+ struct mlx5e_mod_hdr_handle *mh);
+
static const struct rhashtable_params cts_ht_params = {
.head_offset = offsetof(struct mlx5_ct_entry, node),
.key_offset = offsetof(struct mlx5_ct_entry, cookie),
@@ -458,8 +463,7 @@ mlx5_tc_ct_entry_del_rule(struct mlx5_tc_ct_priv *ct_priv,
ct_dbg("Deleting ct entry rule in zone %d", entry->tuple.zone);
mlx5_tc_rule_delete(netdev_priv(ct_priv->netdev), zone_rule->rule, attr);
- mlx5e_mod_hdr_detach(ct_priv->dev,
- ct_priv->mod_hdr_tbl, zone_rule->mh);
+ mlx5_tc_ct_entry_destroy_mod_hdr(ct_priv, zone_rule->attr, zone_rule->mh);
mlx5_put_label_mapping(ct_priv, attr->ct_attr.ct_labels_id);
kfree(attr);
}
@@ -686,15 +690,27 @@ mlx5_tc_ct_entry_create_mod_hdr(struct mlx5_tc_ct_priv *ct_priv,
if (err)
goto err_mapping;
- *mh = mlx5e_mod_hdr_attach(ct_priv->dev,
- ct_priv->mod_hdr_tbl,
- ct_priv->ns_type,
- &mod_acts);
- if (IS_ERR(*mh)) {
- err = PTR_ERR(*mh);
- goto err_mapping;
+ if (nat) {
+ attr->modify_hdr = mlx5_modify_header_alloc(ct_priv->dev, ct_priv->ns_type,
+ mod_acts.num_actions,
+ mod_acts.actions);
+ if (IS_ERR(attr->modify_hdr)) {
+ err = PTR_ERR(attr->modify_hdr);
+ goto err_mapping;
+ }
+
+ *mh = NULL;
+ } else {
+ *mh = mlx5e_mod_hdr_attach(ct_priv->dev,
+ ct_priv->mod_hdr_tbl,
+ ct_priv->ns_type,
+ &mod_acts);
+ if (IS_ERR(*mh)) {
+ err = PTR_ERR(*mh);
+ goto err_mapping;
+ }
+ attr->modify_hdr = mlx5e_mod_hdr_get(*mh);
}
- attr->modify_hdr = mlx5e_mod_hdr_get(*mh);
dealloc_mod_hdr_actions(&mod_acts);
return 0;
@@ -705,6 +721,17 @@ mlx5_tc_ct_entry_create_mod_hdr(struct mlx5_tc_ct_priv *ct_priv,
return err;
}
+static void
+mlx5_tc_ct_entry_destroy_mod_hdr(struct mlx5_tc_ct_priv *ct_priv,
+ struct mlx5_flow_attr *attr,
+ struct mlx5e_mod_hdr_handle *mh)
+{
+ if (mh)
+ mlx5e_mod_hdr_detach(ct_priv->dev, ct_priv->mod_hdr_tbl, mh);
+ else
+ mlx5_modify_header_dealloc(ct_priv->dev, attr->modify_hdr);
+}
+
static int
mlx5_tc_ct_entry_add_rule(struct mlx5_tc_ct_priv *ct_priv,
struct flow_rule *flow_rule,
@@ -767,8 +794,7 @@ mlx5_tc_ct_entry_add_rule(struct mlx5_tc_ct_priv *ct_priv,
return 0;
err_rule:
- mlx5e_mod_hdr_detach(ct_priv->dev,
- ct_priv->mod_hdr_tbl, zone_rule->mh);
+ mlx5_tc_ct_entry_destroy_mod_hdr(ct_priv, zone_rule->attr, zone_rule->mh);
mlx5_put_label_mapping(ct_priv, attr->ct_attr.ct_labels_id);
err_mod_hdr:
kfree(attr);
--
2.31.1
next prev parent reply other threads:[~2021-05-27 18:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-27 18:56 [pull request][net-next V2 00/15] mlx5 misc updates 2021-05-26 Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 01/15] net/mlx5e: CT, Remove newline from ct_dbg call Saeed Mahameed
2021-05-28 0:30 ` patchwork-bot+netdevbpf
2021-05-27 18:56 ` Saeed Mahameed [this message]
2021-05-27 18:56 ` [net-next V2 03/15] net/mlx5e: TC: Use bit counts for register mapping Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 04/15] net/mlx5e: TC: Reserved bit 31 of REG_C1 for IPsec offload Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 05/15] net/mlx5e: IPsec/rep_tc: Fix rep_tc_update_skb drops IPsec packet Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 06/15] net/mlx5e: RX, Remove unnecessary check in RX CQE compression handling Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 07/15] net/mlx5: DR, Remove unused field of send_ring struct Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 08/15] net/mlx5: Add case for FS_FT_NIC_TX FT in MLX5_CAP_FLOWTABLE_TYPE Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 09/15] net/mlx5: Move table size calculation to steering cmd layer Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 10/15] net/mlx5: Move chains ft pool to be used by all firmware steering Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 11/15] net/mlx5: DR, Set max table size to 2G entries Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 12/15] net/mlx5: Cap the maximum flow group size to 16M entries Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 13/15] net/mlx5: Remove unnecessary spin lock protection Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 14/15] net/mlx5: Use boolean arithmetic to evaluate roce_lag Saeed Mahameed
2021-05-27 18:56 ` [net-next V2 15/15] net/mlx5: Fix lag port remapping logic Saeed Mahameed
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=20210527185624.694304-3-saeed@kernel.org \
--to=saeed@kernel.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulb@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.