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: <CALs4sv1WSJSxTM=cJ84RLkVjo7S8=xG+dR=FGXmDHUWrj7ZWSw@mail.gmail.com>
Date: Fri, 1 Mar 2024 13:09:30 +0530
From: Pavan Chebbi <pavan.chebbi@...adcom.com>
To: Jakub Kicinski <kuba@...nel.org>
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, Mar 1, 2024 at 7:19 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 29 Feb 2024 21:22:19 +0000 Vadim Fedorenko wrote:
> > > Perhaps, but also I think it's fairly impractical. Specialized users may
> > > be able to tune this, but in DC environment PTP is handled at the host
> >
> > That's correct, only 1 app is actually doing syncronization
> >
> > > level, and the applications come and go. So all the poor admin can do
> >
> > Container/VM level applications don't care about PTP packets timestamps.
> > They only care about the time being synchronized.
>
> 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. 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
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.

> > > is set this to the max value. While in the driver you can actually try
> >
> > Pure admin will tune it according to the host level app configuration
> > which may differ because of environment.
>
> Concrete example?
>
> > > to be a bit more intelligent. Expecting the user to tune this strikes me
> > > as trying to take the easy way out..
> >
> > There is no actual way for application to signal down to driver that it
> > gave up waiting for TX timestamp, what other kind of smartness can we
> > expect here?
>
> Let's figure out why the timeouts happen, before we create uAPIs.
> If it's because there's buffer bloat or a pause storm, the next TS
> request that gets queued will get stuck in the same exact way.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4209 bytes)