From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 73D2042CB05 for ; Thu, 9 Jul 2026 12:37:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783600664; cv=none; b=EPpV8KqtcmV//T5BqNRuzNTUIfRlEsGJuAPkpR2SlTke4N7FVXmOW89BJ8UCj7bgMlpDllQ7Yzmj3ZK2rOEqRxoY3lNB6Y/FSiJIAyv84+4f80LAoizOEv4BA6ugcs0UhEIKJyiIQqEi5vVFbBREnr9tFE+BR6rBoVeOyUw+EkY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783600664; c=relaxed/simple; bh=N7u+K2H8AMSpKxT22XYhaTAOeJR5UWYAcY50gHQtV+s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OVs7VXjUvuzy8NjMX03RhlkA4CX4WjllRqaKfX/WDZ/AbyAJM25VxCQ5QDC40/6kdQvIOQ5KsyNL5mLLIEpvDNDKQdSTbkVPTm7inqZgAadrOLhd6H6FjFI/9fOHA/3Qo+sviEhVPpqFEJlTMmnNWhUe/peGq5X+rubAJCKxdxE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=oSTzm5VZ; arc=none smtp.client-ip=209.85.160.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="oSTzm5VZ" Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-51c08df8513so10483311cf.3 for ; Thu, 09 Jul 2026 05:37:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783600662; x=1784205462; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=eZsM6QHqor3CIMylXI/PYzeAjQqxKR3ZG+lD/y/C554=; b=oSTzm5VZ7AfjqOHJkzYkX+wFI4gGi93a2qGibtMzjADMd0+KQ15XUmLpKBT+9QUEhz pZ0iU0UQbXCTHq/lik610Ak7La5pZDSlCYj0TB5ws6Po5gVYxNQKxiYyY8tluNujTuJU 6GNV6NlRaiRw/+Zs+kLGOmdaeMyeVONB4UXX8QbZ0FpbyNkOj1Y9av572FJDxpVGp7+0 CXj7wmqKhVaTr30U2+PPioWJ64IDEkmGB5XfdYlYgroWD6KcFsn/QShQ+OG4l9NbcQvO YLztGYAWcX7EELU5M/WW3X71uqUMV8M7bSpTvp7bYLAES6TMuLJ9CEdMz3qcNdCI8bTn Bi5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783600662; x=1784205462; h=content-transfer-encoding:content-type:in-reply-to:from :content-language: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:content-type; bh=eZsM6QHqor3CIMylXI/PYzeAjQqxKR3ZG+lD/y/C554=; b=P4/DXK8znUeYyNjrsXEUEO5sjJ4ekvdP8c0u6WN1WkS1VYkJJqh3YhBDwPFJJWjuIU EzkVg0S29TFcmDVZOTcc6yE1e65E/BIiO9Uu7o8uE2kjY6TTnke/VQ4K5mAHaMCxqHp+ WsHMPLsKQZrw9W9XE7m1kZn8Wl7Xtjzdgc74mamRppAoo4QP9uCv9Z2EvaK6mFTkvx0e CsfdFh6nPhcTRzLkkw9sqW7afaNSdrQCesx7c8fIHMojqzrLO8JGjQoRy90wWFVAAOBA r4ZGnQpGX6dJULhF+VhiEv3CCDUc4ZKPodwwGYLIKlBJJPUGcNYNkkkxviam5+30qgPh adwg== X-Forwarded-Encrypted: i=1; AHgh+RqzgnOmVEk4Hzq8bHlGkzBQSYyWmAt7WjDNrAyV5nAsZZmUz/vIIFjFNYhEl70dKOsZiR1tafzPLy1OzMQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yyvx8NYgLMnsmIFWtcSUZDzD9telHQbFC2I7RQ0U3kjCY5AuBKw d90bv9zzHVEMfWj3icBtyQwxe7EhpIY3s8SrSNNEm6b7MG+xd2wX06A6 X-Gm-Gg: AfdE7cmqFfVs9MuRe4w9qrSA50LnDeJ1qpPza7SwrsZBnMF8xt7HEWvx1YxlrtYS/hb 5YAJ6lczqmD8Fzcp2aKx1vlQYvVP0HuiUlb61eUYWc9QLcZpetJLRAapn5QegEfmxsZzAgpVCl8 t56OgginY4ZVXek+Z0pcmqIobR0fbiDpARS+e6kFB19m8l1sACashS6axNBVedwjFQtwzNLKUec K4GfFW8fDola0EZ2SelkhMu2g7OvBnIsfQUnxueNQITYtSwWiCuCPRD+p5YU4DV4nLnxSad7L42 UV3uI6+4Ovkx2U+Ny217rlMMs3r40x71Lmvfwhd1BSKfHeFiWoKXFvZL+6eDfLDJt8EXolJZnv6 /OBQqmYHNbldENEU2b7z8YB+lF8UCys84/YNpgBKCJc3UHNZXj29cHzf+McCD+jLNVk6iOhr0pe T9zyRyocHRdv+jzngT50e9GO8OiZp1iX0+RNKyNCvsRN3D X-Received: by 2002:a05:622a:606:b0:51c:844f:28df with SMTP id d75a77b69052e-51c8b420e56mr74133901cf.75.1783600662266; Thu, 09 Jul 2026 05:37:42 -0700 (PDT) Received: from ?IPV6:2a03:83e0:1145:4:69c1:4b24:4324:2373? ([2620:10d:c091:500::1:7f14]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-51c41abe756sm172240671cf.6.2026.07.09.05.37.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2026 05:37:41 -0700 (PDT) Message-ID: Date: Thu, 9 Jul 2026 08:37:40 -0400 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-next 00/15] net/mlx5e: PSP cleanups and improvements To: Cosmin Ratiu , "andrew+netdev@lunn.ch" , "davem@davemloft.net" , Tariq Toukan , "kuba@kernel.org" , "pabeni@redhat.com" , "edumazet@google.com" , "netdev@vger.kernel.org" Cc: Boris Pismenny , "willemdebruijn.kernel@gmail.com" , Jianbo Liu , "leon@kernel.org" , Rahul Rameshbabu , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , Raed Salem , Chris Mi , Dragos Tatulea , "sdf.kernel@gmail.com" , Mark Bloch , "sdf@fomichev.me" , Saeed Mahameed , "aleksandr.loktionov@intel.com" , Gal Pressman , Lama Kayal , "jacob.e.keller@intel.com" References: <20260707130858.969928-1-tariqt@nvidia.com> <0dfe5f6b-dbc8-4104-8883-e88e8e59ab58@gmail.com> <9c6a65b7e54a31dea87e7ea1c5b1b3931240f3ac.camel@nvidia.com> <3a8a33b0822e82d8a37aeb7e9c326889074e458a.camel@nvidia.com> Content-Language: en-US From: Daniel Zahka In-Reply-To: <3a8a33b0822e82d8a37aeb7e9c326889074e458a.camel@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/9/26 6:51 AM, Cosmin Ratiu wrote: > So the test relies on TCP retransmissions to catch the encrypted echo > from the responder on the UDP socket. The timeline seems to be: > 1. data_send_off disables PSP on its end. > 2. data_send_off opens a UDP socket and binds it to port 1000. > 3. data_send_off sends "data echo" to psp_responder on the control > connection. > 4. psp_responder send "echo" on the now sabotaged PSP connection. > 5. psp_responder acks the "echo request" on the control connection. > 6. data_send_off receives the ack. > 7. data_send_off tries to receive "echo" on the PSP connection but > expect_fail==True so stops after 100 ms. > 8. data_send_off reenables PSP on its end. > 9. data_send_off waits for "echo" to be received now that connectivity > is back for up to 350 ms. > 10. data_send_off asserts that something is in the UDP socket queue. > > So UDP packets could be enqueued if PSP packets are received between > steps 4-8. > > It seems disabling PSP steering rules isn't as atomic as we thought, > and sometimes the first echo is discarded by steering. The default TCP > retransmission timeout is 200 ms so there are no retransmissions in the > ~150-170 ms between steps 4-8. > > With a slightly modified test that directly requests data echoes, the > test becomes more reliable. Additionally, you need the UDP_NO_CHECK6_RX > (102) socket options for the ipv6 version, otherwise zero-checksum UDP > packets are discarded by the stack. I vaguely remember doing this > change for this test in Jakub's repo a few years ago. > > Anyway, here's the diff that makes both tests reliably pass: Thanks for taking a look. I suppose the timing and 0 udp checksum explain why I wasn't seeing any packets. I was concerned that we may have entered a state where we were losing some udp packets permanently, as opposed to just some transient drops at the time the device is reconfigured, but it sounds like that isn't the case. So, I think this works ok then.