All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Pavan Chebbi <pavan.chebbi@broadcom.com>
Cc: Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	Jiri Pirko <jiri@resnulli.us>,
	Michael Chan <michael.chan@broadcom.com>,
	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
Date: Fri, 1 Mar 2024 09:18:57 -0800	[thread overview]
Message-ID: <20240301091857.5f79ba3d@kernel.org> (raw)
In-Reply-To: <CALs4sv1WSJSxTM=cJ84RLkVjo7S8=xG+dR=FGXmDHUWrj7ZWSw@mail.gmail.com>

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.

  reply	other threads:[~2024-03-01 17:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-29  7:02 [PATCH net-next 0/2] bnxt_en: Support configurable PTP TX timeout Michael Chan
2024-02-29  7:02 ` [PATCH net-next 1/2] bnxt_en: Introduce devlink runtime driver param to set ptp tx timeout Michael Chan
2024-02-29  9:27   ` Vadim Fedorenko
2024-02-29 17:11   ` Jiri Pirko
2024-02-29 17:30     ` Jakub Kicinski
2024-02-29 21:22       ` Vadim Fedorenko
2024-03-01  1:49         ` Jakub Kicinski
2024-03-01  7:39           ` Pavan Chebbi
2024-03-01 17:18             ` Jakub Kicinski [this message]
2024-03-07  3:50               ` Pavan Chebbi
2024-03-07  4:19                 ` Jakub Kicinski
2024-03-01 11:34         ` Jiri Pirko
2024-02-29  7:02 ` [PATCH net-next 2/2] bnxt_en: Retry for TX timestamp from FW until timeout specified Michael Chan
2024-02-29  9:23   ` Vadim Fedorenko
2024-02-29 16:43     ` Michael Chan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240301091857.5f79ba3d@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew.gospodarek@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jiri@resnulli.us \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavan.chebbi@broadcom.com \
    --cc=richardcochran@gmail.com \
    --cc=vadim.fedorenko@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.