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: <f1d31561-f5b5-486f-98e4-75ccc2723131@linux.dev>
Date: Thu, 29 Feb 2024 21:22:19 +0000
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Jakub Kicinski <kuba@...nel.org>, Jiri Pirko <jiri@...nulli.us>
Cc: Michael Chan <michael.chan@...adcom.com>, davem@...emloft.net,
 netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com,
 pavan.chebbi@...adcom.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 29/02/2024 17:30, Jakub Kicinski wrote:
> On Thu, 29 Feb 2024 18:11:49 +0100 Jiri Pirko wrote:
>> Idk. This does not look sane to me at all. Will we have custom knobs to
>> change timeout for arbitrary FW commands as this as a common thing?
>> Driver is the one to take care of timeouts of FW gracefully, he should
>> know the FW, not the user. Therefore exposing user knobs like this
>> sounds pure wrong to me.
>>
>> nack for adding this to devlink.
> 
> +1
> 
> BTW why is the documentation in a different patch that the param :(
> 
>> If this is some maybe-to-be-common ptp thing, can that be done as part
>> of ptp api perhaps?

Jiri, do you mean extend current ioctl used to enable/disable HW
timestamps?

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

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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ