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 5B8045394 for ; Fri, 1 Mar 2024 17:18:58 +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=1709313538; cv=none; b=T+zoJai+cOd0doaQ/Tq1gIji+xzvetdzUzAZvog9dHHHqIVixSD+PJGipKeG0KfbVMpNWYHOdFJfdLFG+pUK7gppdunhhFn37BpNdIIfppx+mn+wdnYRC8X+PGSkUGsNJPvwEYjFtHf4gw3AJTgbd12UB1SN+MGYGojIbRNuvzA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709313538; c=relaxed/simple; bh=qmqDcDsvijwOtJxPiMfwYXE87/zWFNMI4/lPT6C/TL8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=q42jv29EgDoYlEhL9tHSg2vWK1/jnv62p5mZVuOklZP63p7KEmR7vyAok5BkmEgsb8LgrfF2IYFQohfDhyzENG48dIh9AvJLCETOa+V/cyDZbRYNKBvIOz1C3kCFOpttlt7a2pVvTdWS3ZqNfMkxOvW422mxgpCGL0VgyJFB2cM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YXlnE59G; 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="YXlnE59G" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3262C43390; Fri, 1 Mar 2024 17:18:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709313538; bh=qmqDcDsvijwOtJxPiMfwYXE87/zWFNMI4/lPT6C/TL8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YXlnE59GYkeEpoPsn3wtfznZxaPEMbw5jLAVfKHVTBmjpVpkOuHdzkdJsgN0e9f6a 54fiEirQSIcETGrhHXrb/utDqDJOORBm2NDzslKE4iAqPH8ZpfPrvSKAL9QwQizUeD d15OsdtiTKWyNUS4IRrSlTyehay2HgNGWdAE3uF9agQhKair8x+ybB8WktH8o0UJMK zr4yIU6Q+k/guSvwgFIJAWp8f9TIKZ48vjbIAlPU6Hy4rQfgLp9CSZVMZCKyNgfDbs nhI0Hz4VOF9bAhimy8LUU4/+dgYkg/ouHozaQLC7fSsHBAfvCKYvb0EZffN6DoRp2/ Bd7sqkokaHrTA== Date: Fri, 1 Mar 2024 09:18:57 -0800 From: Jakub Kicinski To: Pavan Chebbi Cc: Vadim Fedorenko , Jiri Pirko , Michael Chan , davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com, pabeni@redhat.com, andrew.gospodarek@broadcom.com, richardcochran@gmail.com Subject: Re: [PATCH net-next 1/2] bnxt_en: Introduce devlink runtime driver param to set ptp tx timeout Message-ID: <20240301091857.5f79ba3d@kernel.org> In-Reply-To: References: <20240229070202.107488-1-michael.chan@broadcom.com> <20240229070202.107488-2-michael.chan@broadcom.com> <20240229093054.0bd96a27@kernel.org> <20240229174914.3a9cb61e@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 1 Mar 2024 13:09:30 +0530 Pavan Chebbi wrote: > > What I was saying is that in the PTP daemon you don't know whether > > the app running is likely to cause delays or not, and how long. > > As such timeouts are rare but still normal. Normal, because...? Why do they happen? > But if you've an environment where you want to have some kind of sync > between the application and the NIC, as to when should both conclude > that the timestamp is absolutely lost, we need some knob like this. > Like you pointed out it's for an informed user who has knowledge of > the Let's start from informing the user why timeout happens. > workloads/flow control and how (badly) could they affect the TX. Of > course the user cannot make an accurate estimation of the exact time > out, but he can always experiment with the knob. > We are not sure if others need this as well, hence the private devlink > parameter. For most common users, the default 1s timeout should serve > well.