From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D17853DBD54 for ; Tue, 19 May 2026 08:10:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779178206; cv=none; b=W0kA8SnkSHMz1iy+pv51fpVb332SGfiXYW8Mz+PaSTeEDFteCAI3pNco2jZHQs4QRHebqZY5GBbjC2kyrEVnTB8fEdu2QejbIkBmNzYFLoU1QuyKzjj3/Kbg6k+nkjaZpKtTVSc1AkAJWwv9Bcwb+lEsYj9TSvzE1poVrascAkQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779178206; c=relaxed/simple; bh=Nz3rSNu9zVS3yzH3mh9tWAgp4wMrjab4VlPPaO9g/iQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=itMrdW7CJ2kdi/KZu7U6a/6WZOL6EJtsp51CyeLbgAeQvBUcvbw4RCRTEGXiBqU1KCXkDQ+wxkp+jOW0lM+vC1xiRmrICeZAGLMEN4dknxxoAwhXa8h+4G7gzfuotZP6IDT7QE1O84ZRE+5UdE88JCHJif80c9f+O2kwjln1Aek= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=PZg37E4I; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=VPXkKFkO; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="PZg37E4I"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="VPXkKFkO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779178203; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hz4WqFcaJrUTE5OjjN9FY4tws1Nc4Bwkqhu4It5u51A=; b=PZg37E4IjWT/pwLCzC7BlaByPCgVY/QykHenXkM5NRnYNvEt4FWFKbfqhHMgstJ5QMgOhM Hd9u78ftNps8V343VcDdcZxdZS7BzcsLiRmKB8Plv9qb4rVT/RXV/hNCoY1ExoLlNjT9GC 9JPGbOAXIFL6iMfTPdr18zbJMH6n5EE= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-110-cXWEhIIDP96kRjHUu-hzPw-1; Tue, 19 May 2026 04:10:01 -0400 X-MC-Unique: cXWEhIIDP96kRjHUu-hzPw-1 X-Mimecast-MFC-AGG-ID: cXWEhIIDP96kRjHUu-hzPw_1779178201 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-48fdacff6d2so25454575e9.2 for ; Tue, 19 May 2026 01:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1779178201; x=1779783001; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hz4WqFcaJrUTE5OjjN9FY4tws1Nc4Bwkqhu4It5u51A=; b=VPXkKFkOYknpbr5B4+CXMWlB/vLw5QfPwcXDWKRd7omJYRx8JY/Czi9PU8mt0RF1WH FGtmCiyWrVBdMvwIGBjHYLBD0Qx0iEKT/71vqpGeczPd9V3693D7eZ6Ep83mLtjQdPUp +XDnp3rSDqqPkZDPgYn3cbxEMHU27ALye6ZPaDHvVh69HSl6KekSc/zd/vguC/8yPCR6 pLwF23DyHNEqQsLkDwsnAuPnNq19peCsiYfCztRagkdutN6d8Pdl1sjYZrz2KEMhWP5c +Cwr6fKT4RqkspQKtkPJXU7TIi1SMg5O8fHFoQdNIKOZQsdbt0/duBnYboiB4TRp3O7w X9RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779178201; x=1779783001; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hz4WqFcaJrUTE5OjjN9FY4tws1Nc4Bwkqhu4It5u51A=; b=WtGZEObhnOpRXUYWP8ZyLrWtKXcuVFeJscmn+H3qkc0QN+T6VyfzeU9R4FNQxfsZeS UYMvaUwyxRfiCzvql6j/psedyeyZB0Gzo1YbrgjNq2VS/SQv8XBGufT0ISvfnGKXPFy2 8oF8IszN+UrXf+HXvogdKSrXORjscEFD7WbKDHMKyrgX3v7G4GQrcKPV6XFy4Ezn9zqG nQSrQFJ6cPKj231zq6PZQH5C/+++9SFKWGltbVrNpfvraKFUZ+itVvUW0ynR6U/MNqB+ 2CKvofG4m/+4uMUTRsqWu+OjCM7g5SnztEaP0MHgKWOC7FUKsZzEXCFAuc4m8igSXyIR AKzg== X-Forwarded-Encrypted: i=1; AFNElJ+kt/labbMEV44Fmjt85v8v8ffgtrCE/h+b6n/Lsb6RQTXErH2IvVL2DCpDx8HJuaVapwkChqeHdm8PYH4=@vger.kernel.org X-Gm-Message-State: AOJu0YzkUUdyWukb6RjmfytAypzQV+r9tEp/VRRdhAi0lNVcG/p4do2G bBFcXADWHG5OSnhcV1X5/8Z2jKuyrOYgv7Rky2XC7sENyG8qi2znqJXEvtQcXwPdhZ9BdQW/AGj L27iHaXexaTNn2inDvu2VAp5cVCFB4E4Rr3E2VhmgIFQAPutISThLUrwDn1wUfstTbw== X-Gm-Gg: Acq92OExR45KpOwmO0TByW4307KtV9ldB+XGOER+Ju2jQLVuU+YUHfiezCtwAZqhi34 EfoqqAZO1dRNPruVhPU7exGMl4KI/o1Kpn2GNy6Inp1UQJsEN4Nj9KG0qkosrj5bO/Cf6GFETAW 42x0YHGNBQCM3R59bwpBNXxDLhILo7Zf01hgDKkUnXK4fSeuvIUZ+4JyDpGFMwKBYBWnxYtD7Ez 2KyzuVYi4NaLJf3k4tQayHJUhAN+mSsU5t31lnS+DU54zsgAA3ZB46cJ680xe8OCfTdOZHouygL phPcM7DfRJiHw57EQEiMh55YflDaoaMHUjFVNGAfvgJvv404vTY6Kp47NleVUKTOn86+y9CJEPE OAhZk8kZVDvTgJPFz+DcVNevUcQ8HExFfh6a+Kcxo9PjLwI/Fp+vjJsQ= X-Received: by 2002:a05:600c:c087:b0:488:d6eb:e63c with SMTP id 5b1f17b1804b1-48fe61f2768mr209624295e9.15.1779178200620; Tue, 19 May 2026 01:10:00 -0700 (PDT) X-Received: by 2002:a05:600c:c087:b0:488:d6eb:e63c with SMTP id 5b1f17b1804b1-48fe61f2768mr209623505e9.15.1779178200067; Tue, 19 May 2026 01:10:00 -0700 (PDT) Received: from [192.168.88.32] ([150.228.25.33]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45da15a5653sm44145281f8f.35.2026.05.19.01.09.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 May 2026 01:09:59 -0700 (PDT) Message-ID: Date: Tue, 19 May 2026 10:09:57 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net] net/mlx5e: Skip IPsec flow modify when MAC address is unchanged To: Simon Horman , tariqt@nvidia.com Cc: edumazet@google.com, kuba@kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, borisp@nvidia.com, saeedm@nvidia.com, leon@kernel.org, mbloch@nvidia.com, jianbol@nvidia.com, cjubran@nvidia.com, acassen@corp.free.fr, kees@kernel.org, Jason@zx2c4.com, michal.swiatkowski@linux.intel.com, fmancera@suse.de, antonio@openvpn.net, cratiu@nvidia.com, ecree.xilinx@gmail.com, sridhar.samudrala@intel.com, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, gal@nvidia.com, leonro@nvidia.com References: <20260513190226.335562-1-tariqt@nvidia.com> <20260518112710.510979-2-horms@kernel.org> From: Paolo Abeni Content-Language: en-US In-Reply-To: <20260518112710.510979-2-horms@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/18/26 1:27 PM, Simon Horman wrote: > From: 'Simon Horman' > > This is an AI-generated review of your patch. The human sending this > email has considered the AI review valid, or at least plausible. > Full review at: https://sashiko.dev > --- > net/mlx5e: Skip IPsec flow modify when MAC address is unchanged > > When a netdev event fires for an IPsec SA, skip calling > mlx5e_accel_ipsec_fs_modify() if the MAC address has not changed and > the rule is not in drop mode. This avoids redundant hardware updates. > >> 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 a52e12c3c95a2..f567cd801adb3 100644 >> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c >> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c >> @@ -674,19 +674,26 @@ static void mlx5e_ipsec_handle_netdev_event(struct work_struct *_work) >> struct mlx5e_ipsec_sa_entry *sa_entry = work->sa_entry; >> struct mlx5e_ipsec_netevent_data *data = work->data; >> struct mlx5_accel_esp_xfrm_attrs *attrs; > [ ... ] >> + >> + if (ether_addr_equal(mac, data->addr) && !attrs->drop) >> + return; >> + >> + ether_addr_copy(mac, data->addr); >> attrs->drop = false; >> mlx5e_accel_ipsec_fs_modify(sa_entry); > > If mlx5e_accel_ipsec_fs_modify() fails (for example, due to a memory > allocation failure), does this early return prevent the hardware state > from recovering? > > Since attrs->drop and the mac address are updated before calling > mlx5e_accel_ipsec_fs_modify(), a failure in the hardware update leaves the > software state out of sync with the hardware. > > Prior to this patch, a subsequent netdev event for the same neighbor would > unconditionally retry the hardware update. With this patch, the early return > sees the optimistically updated software state, matches it, and skips the > retry, potentially leaving the hardware permanently stuck in a dropped or > failed state. @Tariq, @Jianbo: I tend to think that the above qualifies as pre-existing issue: when mlx5e_accel_ipsec_fs_modify() failed the S/W and the H/W ended-up in out-of-sync state for a potentially unlimited time even before this patch. WDYT? /P