From: Aditya Garg <gargaditya@linux.microsoft.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, pabeni@redhat.com, longli@microsoft.com,
kotaranov@microsoft.com, horms@kernel.org,
shradhagupta@linux.microsoft.com, ssengar@linux.microsoft.com,
ernis@linux.microsoft.com, dipayanroy@linux.microsoft.com,
shirazsaleem@microsoft.com, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rdma@vger.kernel.org, gargaditya@microsoft.com
Subject: Re: [PATCH net-next v2] net: mana: Handle SKB if TX SGEs exceed hardware limit
Date: Wed, 5 Nov 2025 22:10:23 +0530 [thread overview]
Message-ID: <82bcd959-571e-42ce-b341-cbfa19f9f86d@linux.microsoft.com> (raw)
In-Reply-To: <20251031162611.2a981fdf@kernel.org>
On 01-11-2025 04:56, Jakub Kicinski wrote:
> On Wed, 29 Oct 2025 06:12:35 -0700 Aditya Garg wrote:
>> @@ -289,6 +290,21 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>> cq = &apc->tx_qp[txq_idx].tx_cq;
>> tx_stats = &txq->stats;
>>
>> + if (MAX_SKB_FRAGS + 2 > MAX_TX_WQE_SGL_ENTRIES &&
>> + skb_shinfo(skb)->nr_frags + 2 > MAX_TX_WQE_SGL_ENTRIES) {
>> + /* GSO skb with Hardware SGE limit exceeded is not expected here
>> + * as they are handled in mana_features_check() callback
>> + */
>> + if (skb_is_gso(skb))
>> + netdev_warn_once(ndev, "GSO enabled skb exceeds max SGE limit\n");
>
> This could be the same question Simon asked but why do you think you
> need this line? Sure you need to linearize non-GSO but why do you care
> to warn specifically about GSO?! Looks like defensive programming or
> testing leftover..
>
Hi Jakub,
Agreed, The GSO specific warning is redundant. I'll drop it in next
revision.
>> + if (skb_linearize(skb)) {
>> + netdev_warn_once(ndev, "Failed to linearize skb with nr_frags=%d and is_gso=%d\n",
>> + skb_shinfo(skb)->nr_frags,
>> + skb_is_gso(skb));
>
> .. in practice including is_gso() here as you do is probably enough for
> debug
>
Ok
>> + goto tx_drop_count;
>> + }
>> + }
>> +
>> pkg.tx_oob.s_oob.vcq_num = cq->gdma_id;
>> pkg.tx_oob.s_oob.vsq_frame = txq->vsq_frame;
>>
>> @@ -402,8 +418,6 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>> }
>> }
>>
>> - WARN_ON_ONCE(pkg.wqe_req.num_sge > MAX_TX_WQE_SGL_ENTRIES);
>> -
>> if (pkg.wqe_req.num_sge <= ARRAY_SIZE(pkg.sgl_array)) {
>> pkg.wqe_req.sgl = pkg.sgl_array;
>> } else {
>> @@ -438,9 +452,13 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>>
>> if (err) {
>> (void)skb_dequeue_tail(&txq->pending_skbs);
>> + mana_unmap_skb(skb, apc);
>> netdev_warn(ndev, "Failed to post TX OOB: %d\n", err);
>
> You have a print right here and in the callee. This condition must
> (almost) never happen in practice. It's likely fine to just drop
> the packet.
> The logs placed in callee doesn't covers all the failure scenarios,
hence I feel to have this log here with proper status. Maybe I can
remove the log in the callee?
> Either way -- this should be a separate patch.
>
Are you suggesting a separate patch altogether or two patch in the same
series?
Based on your suggestion i can work on v3.
Regards,
Aditya
>> - err = NETDEV_TX_BUSY;
>> - goto tx_busy;
>> + if (err == -ENOSPC) {
>> + err = NETDEV_TX_BUSY;
>> + goto tx_busy;
>> + }
>> + goto free_sgl_ptr;
>> }
>>
>> err = NETDEV_TX_OK;
>> @@ -478,6 +496,25 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>> return NETDEV_TX_OK;
>> }
next prev parent reply other threads:[~2025-11-05 16:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 13:12 [PATCH net-next v2] net: mana: Handle SKB if TX SGEs exceed hardware limit Aditya Garg
2025-10-30 9:04 ` Simon Horman
2025-10-31 13:20 ` Aditya Garg
2025-11-03 14:58 ` Simon Horman
2025-10-31 23:26 ` Jakub Kicinski
2025-11-05 16:40 ` Aditya Garg [this message]
2025-11-06 0:17 ` Jakub Kicinski
2025-11-06 13:00 ` Aditya Garg
2025-11-06 13:17 ` Eric Dumazet
2025-11-10 12:08 ` Aditya Garg
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=82bcd959-571e-42ce-b341-cbfa19f9f86d@linux.microsoft.com \
--to=gargaditya@linux.microsoft.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=dipayanroy@linux.microsoft.com \
--cc=edumazet@google.com \
--cc=ernis@linux.microsoft.com \
--cc=gargaditya@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=horms@kernel.org \
--cc=kotaranov@microsoft.com \
--cc=kuba@kernel.org \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=longli@microsoft.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shirazsaleem@microsoft.com \
--cc=shradhagupta@linux.microsoft.com \
--cc=ssengar@linux.microsoft.com \
--cc=wei.liu@kernel.org \
/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.