From: Jakub Kicinski <kuba@kernel.org>
To: "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@quicinc.com>
Cc: <davem@davemloft.net>, <edumazet@google.com>, <pabeni@redhat.com>,
<netdev@vger.kernel.org>, <vadim.fedorenko@linux.dev>,
<lkp@intel.com>, <horms@kernel.org>,
Sean Tranchetti <quic_stranche@quicinc.com>
Subject: Re: [PATCH net-next v4] net: qualcomm: rmnet: Add side band flow control support
Date: Tue, 10 Oct 2023 11:21:59 -0700 [thread overview]
Message-ID: <20231010112159.2e2e1b86@kernel.org> (raw)
In-Reply-To: <b1efa230-b30b-0ace-5e99-fe8593eeb12e@quicinc.com>
On Tue, 10 Oct 2023 09:23:12 -0600 Subash Abhinov Kasiviswanathan (KS)
wrote:
> > I'm not sure what you mean. Qdiscs can form hierarchies.
> > You put mq first and then whatever child qdisc you want for individual
> > queues.
>
> There is no userspace interface exposed today currently to invoke
> netif_tx_stop_queue(dev, queue) / netif_tx_wake_queue(dev, queue). The
> API itself can only be invoked within kernel.
>
> I was wondering if it would be acceptable to add a user accessible
> interface in core networking to stop_queue / wake_queue instead of the
> driver.
Maybe not driver queue control but if there's no qdisc which allows
users to pause from user space, I think that would be a much easier
sale.
That said the flow of the whole thing seems a bit complex.
Can't the driver somehow be notified by the device directly?
User space will suffer from all sort of wake up / scheduling
latencies, it'd be better if the whole sleep / wake thing was
handled in the kernel.
next prev parent reply other threads:[~2023-10-10 18:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-06 0:16 [PATCH net-next v4] net: qualcomm: rmnet: Add side band flow control support Subash Abhinov Kasiviswanathan
2023-10-10 2:42 ` Jakub Kicinski
2023-10-10 4:00 ` Subash Abhinov Kasiviswanathan (KS)
2023-10-10 14:56 ` Jakub Kicinski
2023-10-10 15:23 ` Subash Abhinov Kasiviswanathan (KS)
2023-10-10 18:21 ` Jakub Kicinski [this message]
2023-10-10 21:32 ` Subash Abhinov Kasiviswanathan (KS)
2023-10-11 0:35 ` Subash Abhinov Kasiviswanathan (KS)
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=20231010112159.2e2e1b86@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=lkp@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=quic_stranche@quicinc.com \
--cc=quic_subashab@quicinc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).