Re: [PATCH net-next v2] net: mana: Handle SKB if TX SGEs exceed hardware limit

[Simon Horman <horms@kernel.org>]

On Fri, Oct 31, 2025 at 06:50:10PM +0530, Aditya Garg wrote:
> On 30-10-2025 14:34, Simon Horman wrote:
> > On Wed, Oct 29, 2025 at 06:12:35AM -0700, Aditya Garg wrote:
> > > The MANA hardware supports a maximum of 30 scatter-gather entries (SGEs)
> > > per TX WQE. Exceeding this limit can cause TX failures.
> > > Add ndo_features_check() callback to validate SKB layout before
> > > transmission. For GSO SKBs that would exceed the hardware SGE limit, clear
> > > NETIF_F_GSO_MASK to enforce software segmentation in the stack.
> > > Add a fallback in mana_start_xmit() to linearize non-GSO SKBs that still
> > > exceed the SGE limit.
> > > 
> > > Return NETDEV_TX_BUSY only for -ENOSPC from mana_gd_post_work_request(),
> > > send other errors to free_sgl_ptr to free resources and record the tx
> > > drop.
> > > 
> > > Co-developed-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
> > > Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
> > > Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com>
> > 
> > ...
> > 
> > > @@ -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
> > > +		 */
> > 
> > Hi,
> > 
> > I'm curious to know if we actually need this code.
> > Are there cases where the mana_features_check() doesn't
> > handle things and the kernel will reach this line?
> > 
> > > +		if (skb_is_gso(skb))
> > > +			netdev_warn_once(ndev, "GSO enabled skb exceeds max SGE limit\n");
> > > +		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));
> > > +			goto tx_drop_count;
> > > +		}
> > > +	}
> > > +
> > >   	pkg.tx_oob.s_oob.vcq_num = cq->gdma_id;
> > >   	pkg.tx_oob.s_oob.vsq_frame = txq->vsq_frame;
> > 
> > ...
> 
> Hi Simon,
> As it was previously discussed and agreed on with Eric, this is for Non-GSO
> skbs which could have possibly nr_frags greater than hardware limit.
> 
> Quoting Eric's comment from v1 thread: https://lore.kernel.org/netdev/CANn89iKwHWdUaeAsdSuZUXG-W8XwyM2oppQL9spKkex0p9-Azw@mail.gmail.com/
> "I think that for non GSO, the linearization attempt is fine.
> 
> Note that this is extremely unlikely for non malicious users,
> and MTU being usually small (9K or less),
> the allocation will be much smaller than a GSO packet."

Thanks for the clarification, that makes sense to me.

FTR, Jakub's question (elsewhere) is different to mine.