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: Wed, 6 Mar 2024 20:19:13 -0800 [thread overview]
Message-ID: <20240306201913.626a41f0@kernel.org> (raw)
In-Reply-To: <CALs4sv123NSvtprMEqTxhHVjS6i1ZDgfOrx4z_cEnUyYuQP1Zg@mail.gmail.com>
On Thu, 7 Mar 2024 09:20:44 +0530 Pavan Chebbi wrote:
> > > 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.
The problem can be solved more intelligently.
next prev parent reply other threads:[~2024-03-07 4:19 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
2024-03-07 3:50 ` Pavan Chebbi
2024-03-07 4:19 ` Jakub Kicinski [this message]
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=20240306201913.626a41f0@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.