From: "Daniel Zahka" <daniel.zahka@gmail.com>
To: <netdev-bot+sashiko@kernel.org>, <daniel.zahka@gmail.com>
Cc: <alexanderduyck@fb.com>, <kuba@kernel.org>,
<kernel-team@meta.com>, <andrew+netdev@lunn.ch>,
<davem@davemloft.net>, <edumazet@google.com>, <pabeni@redhat.com>,
<ast@kernel.org>, <daniel@iogearbox.net>, <hawk@kernel.org>,
<john.fastabend@gmail.com>, <sdf@fomichev.me>,
<dimitri.daskalakis1@gmail.com>, <mohsin.bashr@gmail.com>,
<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
<bpf@vger.kernel.org>
Subject: Re: [PATCH net-next v2 5/8] eth: mpnic: start and stop the Tx HW queues
Date: Mon, 28 Sep 2026 11:00:13 -0400 [thread overview]
Message-ID: <DLR1F9RXTT06.UETFCFM0S7X9@gmail.com> (raw)
In-Reply-To: <179055370349.3145.18291043056842354620@kernel.org>
On Sun Sep 27, 2026 at 8:01 PM EDT, netdev-bot+sashiko wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider.
>
> Critical: 0 · High: 1 · Medium: 0 · Low: 1
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [High] mpnic_wait_all_queues_idle() returns void and drops the
> -ETIMEDOUT from read_poll_timeout().
> - [Low] mpnic_enable_twq() writes fls(size_mask) & MPNIC_TWQ_SIZE_SIZE (a
> 4-bit field), and mpnic_enable_tcq() writes the same exponent into…
>
> --
>
> eth: mpnic: start and stop the Tx HW queues
>
> This commit writes the Tx work queue and completion queue base addresses
> and sizes into the hardware. It adds mpnic_enable() and mpnic_disable() to
> turn the Tx queues on and off. It also adds mpnic_wait_all_queues_idle(),
> which polls the TWQ, TQS, TDE and TCQ idle bitmaps, and mpnic_flush(),
> which throws away any Tx work left in the rings.
>
>> diff --git a/drivers/net/ethernet/meta/mpnic/mpnic_txrx.c b/drivers/net/ethernet/meta/mpnic/mpnic_txrx.c
>> index 853976e11b032..aaa3a3e99a138 100644
>> --- a/drivers/net/ethernet/meta/mpnic/mpnic_txrx.c
>> +++ b/drivers/net/ethernet/meta/mpnic/mpnic_txrx.c
>
> [ ... ]
>
>> @@ -467,6 +468,180 @@ void mpnic_reset_netif_queues(struct mpnic_net *mpn)
>> }
>> }
>>
>> +static void mpnic_enable_twq(struct mpnic_dev *mpd, struct mpnic_ring *twq)
>> +{
>> + u32 log_size = fls(twq->size_mask);
>> + u32 i = twq->q_idx;
>
> [ ... ]
>
>> + /* Store descriptor ring address and size */
>> + mpnic_wr64(mpd, MPNIC_TWQ_BASE_ADDR(i, 0), twq->dma);
>> + mpnic_wr64(mpd, MPNIC_TWQ_SIZE(i, 0), log_size & MPNIC_TWQ_SIZE_SIZE);
>
> [ ... ]
>
>> +static void mpnic_enable_tcq(struct mpnic_dev *mpd,
>> + struct mpnic_napi_vector *nv,
>> + struct mpnic_ring *tcq)
>> +{
>> + u32 log_size = fls(tcq->size_mask);
>> + u32 i = tcq->q_idx;
>
> [ ... ]
>
>> + /* Store descriptor ring address and size */
>> + mpnic_wr64(mpd, MPNIC_TCQ_BASE_ADDR(i), tcq->dma);
>> + mpnic_wr64(mpd, MPNIC_TCQ_SIZE(i), log_size & MPNIC_TCQ_SIZE_SIZE);
>
> [Severity: Low]
> This isn't a bug with the current fixed 1024-entry rings, but
> mpnic_enable_twq() and mpnic_enable_tcq() mask the same exponent with
> fields of different widths in mpnic_csr.h:
>
> #define MPNIC_TWQ_SIZE_SIZE CSR_GENMASK(3, 0)
> #define MPNIC_TCQ_SIZE_SIZE CSR_GENMASK(4, 0)
>
> For a 64K-entry ring (fls() == 16), TWQ_SIZE would get 0 and TCQ_SIZE
> would get 16. Is this the intended encoding for each register?
>
The code is correct. TWQ has a max ring size of 64k, and that has an
encoding of 0 (like fbnic). TCQ actually supports rings as large as
256k, but it does not have/need the 0 encoding for that, as there is an
extra bit in the size field.
> fbnic has a comment for the 4-bit form: "Write lower 4 bits of log size
> as 64K ring size is 0". Would a similar comment help here?
>
> [ ... ]
>
>> +void mpnic_wait_all_queues_idle(struct mpnic_dev *mpd)
>> +{
>> + static const struct mpnic_idle_regs queues[] = {
>> + { MPNIC_TWQ_IDLE(0), MPNIC_TWQ_IDLE_CNT, "TWQ" },
>> + { MPNIC_TQS_IDLE(0), MPNIC_TQS_IDLE_CNT, "TQS" },
>> + { MPNIC_TDE_IDLE(0), MPNIC_TDE_IDLE_CNT, "TDE" },
>> + { MPNIC_TCQ_IDLE(0), MPNIC_TCQ_IDLE_CNT, "TCQ" },
>> + };
>> + u32 non_idle_bitmap;
>> + int err;
>> +
>> + err = read_poll_timeout(mpnic_non_idle_queues, non_idle_bitmap,
>> + !non_idle_bitmap, 20, 500000, false, mpd,
>> + queues, ARRAY_SIZE(queues));
>> + if (err)
>> + mpnic_idle_dump(mpd, queues, ARRAY_SIZE(queues),
>> + non_idle_bitmap, err);
>> +}
>
> [Severity: High]
> What happens to the Tx rings if this poll times out?
>
> The commit message says every block "has to report idle before the
> descriptors are safe to free". However, the -ETIMEDOUT from
> read_poll_timeout() is only logged. mpnic_wait_all_queues_idle() returns
> void, so a caller can't tell a timeout apart from a clean drain.
>
> mpnic_stop() is added later in the series, in "eth: mpnic: add a netdevice
> and basic Tx handling". It carries on whatever the result:
>
> mpnic_disable(mpn);
> mpnic_wait_all_queues_idle(mpn->mpd);
> mpnic_flush(mpn);
>
> mpnic_reset_netif_queues(mpn);
> mpnic_free_resources(mpn);
>
> mpnic_disable_twq() and mpnic_disable_tcq() only clear the enable bits.
> TWQ_BASE_ADDR and TCQ_BASE_ADDR still point at the rings.
>
> After a timeout, mpnic_flush()->mpnic_clean_twq0(..., true, tail) unmaps
> the in-flight Tx buffers and consumes their skbs. Then
> mpnic_free_ring_resources() calls dma_free_coherent() on the TWQ and TCQ
> descriptor memory.
>
> Could a Tx engine that is still busy then fetch descriptors or payload from
> freed memory and put it on the wire? Could the TCM write completion
> descriptors into memory that now belongs to another user?
>
> fbnic_wait_all_queues_idle() handles the same case differently. It turns
> on Tx drop through fbnic_tx_flush(), polls again, and returns an int.
> Would something similar be needed here? At minimum, could the error be
> returned so the caller can avoid freeing the rings?
This was addressed many times in the v1 sashiko review.
next prev parent reply other threads:[~2026-09-28 15:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 0:35 [PATCH net-next v2 0/8] eth: mpnic: initial support for Meta Platforms NIC Daniel Zahka
2026-09-25 0:35 ` [PATCH net-next v2 1/8] eth: mpnic: add scaffolding " Daniel Zahka
2026-09-28 0:01 ` netdev-bot+sashiko
2026-09-28 12:13 ` Daniel Zahka
2026-09-25 0:35 ` [PATCH net-next v2 2/8] eth: mpnic: add register init for the device Daniel Zahka
2026-09-28 0:01 ` netdev-bot+sashiko
2026-09-28 12:14 ` Daniel Zahka
2026-09-25 0:35 ` [PATCH net-next v2 3/8] eth: mpnic: allocate MSI-X vectors Daniel Zahka
2026-09-28 0:01 ` netdev-bot+sashiko
2026-09-28 16:01 ` Daniel Zahka
2026-09-25 0:35 ` [PATCH net-next v2 4/8] eth: mpnic: implement Tx queue allocation and cleanup Daniel Zahka
2026-09-28 0:01 ` netdev-bot+sashiko
2026-09-28 14:46 ` Daniel Zahka
2026-09-25 0:35 ` [PATCH net-next v2 5/8] eth: mpnic: start and stop the Tx HW queues Daniel Zahka
2026-09-28 0:01 ` netdev-bot+sashiko
2026-09-28 15:00 ` Daniel Zahka [this message]
2026-09-25 0:35 ` [PATCH net-next v2 6/8] eth: mpnic: add a netdevice and basic Tx handling Daniel Zahka
2026-09-28 0:01 ` netdev-bot+sashiko
2026-09-28 15:10 ` Daniel Zahka
2026-09-25 0:35 ` [PATCH net-next v2 7/8] eth: mpnic: implement Rx queue allocation and cleanup Daniel Zahka
2026-09-28 0:01 ` netdev-bot+sashiko
2026-09-28 15:11 ` Daniel Zahka
2026-09-25 0:35 ` [PATCH net-next v2 8/8] eth: mpnic: add basic Rx handling Daniel Zahka
2026-09-28 0:01 ` netdev-bot+sashiko
2026-09-28 15:17 ` Daniel Zahka
2026-09-28 18:16 ` [PATCH net-next v2 0/8] eth: mpnic: initial support for Meta Platforms NIC Daniel Zahka
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=DLR1F9RXTT06.UETFCFM0S7X9@gmail.com \
--to=daniel.zahka@gmail.com \
--cc=alexanderduyck@fb.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dimitri.daskalakis1@gmail.com \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kernel-team@meta.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mohsin.bashr@gmail.com \
--cc=netdev-bot+sashiko@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
/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®