From: Adam Young <admiyo@amperemail.onmicrosoft.com>
To: Jeremy Kerr <jk@codeconstruct.com.au>,
admiyo@os.amperecomputing.com,
Matt Johnston <matt@codeconstruct.com.au>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Sudeep Holla <sudeep.holla@arm.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Huisong Li <lihuisong@huawei.com>
Subject: Re: [PATCH net-next v25 1/1] mctp pcc: Implement MCTP over PCC Transport
Date: Wed, 27 Aug 2025 00:55:05 -0400 [thread overview]
Message-ID: <ae68a2b3-71f5-4fe0-b74a-495bc537ab64@amperemail.onmicrosoft.com> (raw)
In-Reply-To: <9b66a22a2fe689a993d9ff83baf8b7bbecbb8c90.camel@codeconstruct.com.au>
On 8/26/25 21:37, Jeremy Kerr wrote:
> The only remaining query I had was the TX flow control. You're returning
> NETDEV_TX_BUSY while the queues are still running, so are likely to get
> repeated TX in a loop there.
Sorry, I missed this until just after hitting submit again.
The code currently goes
if (rc < 0) {
skb_unlink(skb, &mpnd->outbox.packets);
return NETDEV_TX_BUSY;
}
Which means the failed-to-send packet is unlinked. I guess I am unclear
if this is sufficient to deal with the packet flow control issue or not.
I have not yet had a setup up where I can flood the network with packets
and see what happens if I fill up the ring buffer. I think that is the
most likely failure case that will lead to flow control issues. If the
remote side cannot handle packets as fast as they are sent, at some
point we have to stop sending them. The mailbox abstraction makes that
hard to detect; I think the send_message will hang trying to get the
lock on the shared buffer, and time out.
next prev parent reply other threads:[~2025-08-27 4:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-19 20:51 [PATCH net-next v25 0/1] MCTP Over " admiyo
2025-08-19 20:51 ` [PATCH net-next v25 1/1] mctp pcc: Implement MCTP over " admiyo
2025-08-22 8:21 ` Jeremy Kerr
2025-08-26 20:51 ` Adam Young
2025-08-27 1:37 ` Jeremy Kerr
2025-08-27 4:55 ` Adam Young [this message]
2025-08-26 22:37 ` Adam Young
2025-08-27 4:48 [PATCH net-next v25 0/1] MCTP Over " admiyo
2025-08-27 4:48 ` [PATCH net-next v25 1/1] mctp pcc: Implement MCTP over " admiyo
2025-08-27 7:36 ` Jeremy Kerr
2025-08-27 17:54 ` kernel test robot
2025-08-29 9:17 ` kernel test robot
2025-08-29 19:32 ` ALOK TIWARI
2025-09-01 0:59 ` Jeremy Kerr
2025-09-05 17:25 ` Adam Young
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=ae68a2b3-71f5-4fe0-b74a-495bc537ab64@amperemail.onmicrosoft.com \
--to=admiyo@amperemail.onmicrosoft.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=admiyo@os.amperecomputing.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jk@codeconstruct.com.au \
--cc=kuba@kernel.org \
--cc=lihuisong@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeconstruct.com.au \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sudeep.holla@arm.com \
/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
all inboxes | Powered by JetHome®