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 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).