From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 BF3E42F261D; Mon, 3 Nov 2025 13:59:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762178359; cv=none; b=vEGcqBobFElBFmfUKqJiosBFpThr/ojC6/Go/8cvfX0jJUsCeVvj4Zbk00EPi1GZUextuXzztn3WHzTNIGsRPlqU7f1ODj/lT7YL6vNGOUv8msec7l1SzVcZNxsD6cUY0TqzZVvdoJ3gyAgAdGKl6z/VBpiZ4LOb9PA5miNpqBg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762178359; c=relaxed/simple; bh=0oAeYn4eoIt7fITYoXBYzp284ep+P4EZt8Gf1qpP4oE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BwusC/HxrM+bGzlCp8IHDBR4j4ubjQUFVX81ARPhmZua9/DEFiceeAH/mX5/osL2CdWxhm/Lj7xq2D4J0PsNVazVpQHpAUS2M/4PoEa72qrzfy5gSpC72g00vo1xHgN7tvS59jxy8sCJ50ItCYz++B6lfXN8xHTCR0MdTwQdPxE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UlQcXGbO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UlQcXGbO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B51F1C4CEE7; Mon, 3 Nov 2025 13:59:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762178359; bh=0oAeYn4eoIt7fITYoXBYzp284ep+P4EZt8Gf1qpP4oE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UlQcXGbOlyvxErBCoqLQNCaqrnB3NX4ocVQ0NFukMQ4J7KYEYmSnTe7tvzkWP85k0 u/XEb1YWQCZ0Hwec6BxB+bE8Hk1yAEj2rCAPM/9hg0N9nxhxeCQk4kwvuBBFBTRlp+ VW1Zxa3NVjB3sDQbIaW5QoVyQn1YV2mfT0KwLWAXvcCkpvlSkVeORAuzT9KRfG47ZB fGGxQfPUjTgpHC3eoHV4fVq57uEt9OhoOT3JDbN63BtlDo8V4J4/vKlp6IqoOUjrhE j0557nDKZmyELdfOXACTfXVlKifcKl3zTAxwMY2eMWJDUIYgncHY0B64PZ/y0ERNMO zwnmRYll6LaUQ== Date: Mon, 3 Nov 2025 13:59:14 +0000 From: Simon Horman To: Tariq Toukan Cc: Eric Dumazet , Jakub Kicinski , Paolo Abeni , Andrew Lunn , "David S. Miller" , Saeed Mahameed , Leon Romanovsky , Mark Bloch , netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, Gal Pressman , Carolina Jubran Subject: Re: [PATCH net-next V2 7/7] net/mlx5e: Defer channels closure to reduce interface down time Message-ID: References: <1761831159-1013140-1-git-send-email-tariqt@nvidia.com> <1761831159-1013140-8-git-send-email-tariqt@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1761831159-1013140-8-git-send-email-tariqt@nvidia.com> On Thu, Oct 30, 2025 at 03:32:39PM +0200, Tariq Toukan wrote: > Cap bit tis_tir_td_order=1 indicates that an old firmware requirement / > limitation no longer exists. When unset, the latency of several firmware > commands significantly increases with the presence of high number of > co-existing channels (both old and new sets). Hence, we used to close > unneeded old channels before invoking those firmware commands. > > Today, on capable devices, this is no longer the case. Minimize the > interface down time by deferring the old channels closure, after the > activation of the new ones. > > Perf numbers: > Measured the number of dropped packets in a simple ping flood test, > during a configuration change operation, that switches the number of > channels from 247 to 248. > > Before: 71 packets lost > After: 15 packets lost, ~80% saving. > > Signed-off-by: Tariq Toukan > Reviewed-by: Carolina Jubran Reviewed-by: Simon Horman