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: <CALs4sv123NSvtprMEqTxhHVjS6i1ZDgfOrx4z_cEnUyYuQP1Zg@mail.gmail.com>
Date: Thu, 7 Mar 2024 09:20:44 +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 10:48 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> 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?

Excuse me for the late reply.
In my experience so far, it's primarily because of flow control and
how stressed the underlying HW queue is. (I am sure it's not unique to
our hardware alone)
Hence we wanted to accommodate cases where the expected wait time is
higher than what is default in the driver, for the packets to go out.
But it's disappointing to know that even private devlink params are
discouraged for such purposes.
I'd think that non-generic driver params in devlink serve exactly such
requirements and having such a knob would be useful for an advanced
user.
Not to mention, in my view, such additions to devlink would make it
more popular and would help in its wider adoption.
For now, we will drop this series and try to get back with a different solution.

>
> > 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.

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