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 <[email protected]> > > > Signed-off-by: Dipayaan Roy <[email protected]> > > > Signed-off-by: Aditya Garg <[email protected]> > > > > ... > > > > > @@ -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-...@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.
