From: Tariq Toukan <tariqt@nvidia.com>
To: Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>
Cc: Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Tariq Toukan <tariqt@nvidia.com>, Mark Bloch <mbloch@nvidia.com>,
<netdev@vger.kernel.org>, <linux-rdma@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, Gal Pressman <gal@nvidia.com>,
Moshe Shemesh <moshe@nvidia.com>,
Breno Leitao <leitao@debian.org>,
Alexandre Cassen <acassen@corp.free.fr>,
Jianbo Liu <jianbol@nvidia.com>
Subject: [PATCH net 7/9] net/mlx5e: Trigger neighbor resolution for unresolved destinations
Date: Tue, 9 Dec 2025 14:56:15 +0200 [thread overview]
Message-ID: <1765284977-1363052-8-git-send-email-tariqt@nvidia.com> (raw)
In-Reply-To: <1765284977-1363052-1-git-send-email-tariqt@nvidia.com>
From: Jianbo Liu <jianbol@nvidia.com>
When initializing the MAC addresses for an outbound IPsec packet offload
rule in mlx5e_ipsec_init_macs, the call to dst_neigh_lookup is used to
find the next-hop neighbor (typically the gateway in tunnel mode).
This call might create a new neighbor entry if one doesn't already
exist. This newly created entry starts in the INCOMPLETE state, as the
kernel hasn't yet sent an ARP or NDISC probe to resolve the MAC
address. In this case, neigh_ha_snapshot will correctly return an
all-zero MAC address.
IPsec packet offload requires the actual next-hop MAC address to
program the rule correctly. If the neighbor state is INCOMPLETE when
the rule is created, the hardware rule is programmed with an all-zero
destination MAC address. Packets sent using this rule will be
subsequently dropped by the receiving network infrastructure or host.
This patch adds a check specifically for the outbound offload path. If
neigh_ha_snapshot returns an all-zero MAC address, it proactively
calls neigh_event_send(n, NULL). This ensures the kernel immediately
sends the initial ARP or NDISC probe if one isn't already pending,
accelerating the resolution process. This helps prevent the hardware
rule from being programmed with an invalid MAC address and avoids
packet drops due to unresolved neighbors.
Fixes: 71670f766b8f ("net/mlx5e: Support routed networks during IPsec MACs initialization")
Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
index 6c79b9cea2ef..a8fb4bec369c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
@@ -358,6 +358,9 @@ static void mlx5e_ipsec_init_macs(struct mlx5e_ipsec_sa_entry *sa_entry,
neigh_ha_snapshot(addr, n, netdev);
ether_addr_copy(dst, addr);
+ if (attrs->dir == XFRM_DEV_OFFLOAD_OUT &&
+ is_zero_ether_addr(addr))
+ neigh_event_send(n, NULL);
dst_release(rt_dst_entry);
neigh_release(n);
return;
--
2.31.1
next prev parent reply other threads:[~2025-12-09 12:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-09 12:56 [PATCH net 0/9] mlx5 misc fixes 2025-12-09 Tariq Toukan
2025-12-09 12:56 ` [PATCH net 1/9] net/mlx5: fw reset, clear reset requested on drain_fw_reset Tariq Toukan
2025-12-09 12:56 ` [PATCH net 2/9] net/mlx5: Drain firmware reset in shutdown callback Tariq Toukan
2025-12-09 12:56 ` [PATCH net 3/9] net/mlx5: fw_tracer, Validate format string parameters Tariq Toukan
2025-12-09 12:56 ` [PATCH net 4/9] net/mlx5: fw_tracer, Handle escaped percent properly Tariq Toukan
2025-12-09 12:56 ` [PATCH net 5/9] net/mlx5: Serialize firmware reset with devlink Tariq Toukan
2025-12-09 12:56 ` [PATCH net 6/9] net/mlx5e: Use ip6_dst_lookup instead of ipv6_dst_lookup_flow for MAC init Tariq Toukan
2025-12-09 12:56 ` Tariq Toukan [this message]
2025-12-09 12:56 ` [PATCH net 8/9] net/mlx5e: Do not update BQL of old txqs during channel reconfiguration Tariq Toukan
2025-12-09 12:56 ` [PATCH net 9/9] net/mlx5e: Don't include PSP in the hard MTU calculations Tariq Toukan
2025-12-18 13:00 ` [PATCH net 0/9] mlx5 misc fixes 2025-12-09 patchwork-bot+netdevbpf
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=1765284977-1363052-8-git-send-email-tariqt@nvidia.com \
--to=tariqt@nvidia.com \
--cc=acassen@corp.free.fr \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=jianbol@nvidia.com \
--cc=kuba@kernel.org \
--cc=leitao@debian.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=moshe@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@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
all inboxes | Powered by JetHome®