netdev - Re: [PATCH net-next 1/2] bnxt_en: Introduce devlink runtime driver param to set ptp tx timeout

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240301091857.5f79ba3d@kernel.org>
Date: Fri, 1 Mar 2024 09:18:57 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Pavan Chebbi <pavan.chebbi@...adcom.com>
Cc: Vadim Fedorenko <vadim.fedorenko@...ux.dev>, Jiri Pirko
 <jiri@...nulli.us>, Michael Chan <michael.chan@...adcom.com>,
 davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
 pabeni@...hat.com, andrew.gospodarek@...adcom.com, richardcochran@...il.com
Subject: Re: [PATCH net-next 1/2] bnxt_en: Introduce devlink runtime driver
 param to set ptp tx timeout

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.