From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C4A683BB672 for ; Mon, 6 Jul 2026 08:39:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783327158; cv=none; b=ZBJdZ5MTWp0JQG1Dmpl4CesM+xYFzoD5b99lKGCfMTCeSij51wcJRb4aHk1w3mDXGh/t6rstAaoHtVSiQq8gCoPGFxAuIIgUimeeJtxL1yG/LOAWU03NfNt4JdnTl6kuUCs/L9N+m91qPR+fdPPDExS86jPV+7sF7MtdoHjaBpE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783327158; c=relaxed/simple; bh=e2Ji+pe/FvZXwpV4Xt5uOSRoeNT40g8FWm4dC+6dB9Q=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qndforgSU5NY4rs2BtUx1MZnYnSGnE1aoRm40eG4y3TV1imRnVo9cP0KpzYzgzSudxp1RvXp17aYfrtc8BLEbGfuCwOaU0fydxlzv+YiDO052ZJH2d3r1E9QWpOQYu0GucZVvWGvrPAmK/+tuDtzMOnm9L8Ay+sB1BWvNiY7wFM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=d3dKXIfv; arc=none smtp.client-ip=209.85.221.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="d3dKXIfv" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-4731f5ffa74so266069f8f.1 for ; Mon, 06 Jul 2026 01:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783327150; x=1783931950; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:date:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=x+ukvC8SX33SlI+h6grSEYjzYvRK1lDbsR7HDAAu2tk=; b=d3dKXIfvkea7NezY3YlOfTaz+lMDkmxLHzP4mK1dPgyy4sKiQQEaXhhTl0y5UWCBcd aoosfzGwim4CNra0f/dVKuL53w3SbBIS13F3FIhMEKOljlAXwPLZ3FMbxLOmTmfySMl5 do0+KtMVSL/b7IyRfup98chNsPLJWT/ehFfNYRk3IN+MNfoLpPBXWcNyCc45NwwzvF1O EdPupmrqm1Om+w9iNJ+kritu6WfyeBItiRYelyFGMtKp371HhGhEEosJR3FdTkfu0nyb 7g85BC7Ii+UavUv5t7L53nVBB0IEJ40yhxqk/wt4F1UxupBP5hGdxjUgOkhldOyJs8OZ 6HVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783327150; x=1783931950; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=x+ukvC8SX33SlI+h6grSEYjzYvRK1lDbsR7HDAAu2tk=; b=JzAgakeU24bVxmDsz4+8c6x1pXs2uYMwa5GJILjyDK0IbheGbhfvFKliYb/ky9isU+ RSCWKwFnXvq60WRrhtztRGCeP7yGrRFtymXnKY4pO/msfUEa4g5ER59HnfsyNIqrlHY1 1b6fgRuBXYQpio7QQpsSAbct8Pomahq57htG43+kprponLijmE1XYKvfz6a2W1FqsEgZ 7+CyiJyuTLxp1mCQQNqEEC3tP9NPFwZckGrH2BN16un6b4FQ2xaau1d5jSIthMwfykxU rChH4n2HHPnNfDC6PBSY2nN+MRAoHue6XOLaXGiNwOhpRIpBgGgWVESCuWNs/WYpVmfH gE+w== X-Forwarded-Encrypted: i=1; AHgh+Rq/SH4ZI2NrzUxbplsxebLWPvfBiptoXgvmXB/cYVlxWYwAKPcjEYnlZHYaCV2Z10eZQd9fK9UrRFgBi0k=@vger.kernel.org X-Gm-Message-State: AOJu0YzS1xS5tzgEC6mwruaOLu4mA9ZkyjVhGPhwfRDsTZuiApK0kFdJ jSe7qAOWV6bTUOQQH10kLWg8a5oL4P2/+V9194Yo7CmrLOPDxhwOfZdG X-Gm-Gg: AfdE7cktwwfQGHgdDqPeW6QbIYMmGG5n84LojJwn1sdhaUjuWBvg1xGq07+qAu8ExfJ uchupmKyMQ+TDK6++Ui27E+ay8uM5P5FU8FqOGwgYgU8fd3EFNuHyEO9SDSj6o6YVRzED7Xpzxq L+A9UUkE5ciIBuvuJrdX5T469O8KX0BwDYQUNezlx8ds3GYfxdX03lqd94Hdqh81edf3lkU5iJu 6yjzqRtuoNb8N3svSsOGbiDdx6iXuhouODC09puD8JRHX5CxtpQWIwX7wj3+Nk8sISrFCKH5Z0v Oxbm3g0tKxp/w4/PQTUT9jM8w2wzlQiyZbknlf6mBF0W6sOl5MCLrq6mJ1kf246mS0KE4Hcanaq 5a1wy0LA+up5AYJRb5/mAL5mR2nO9KC3/J8pY702zZF4f/A6UrbrqPfqezGA/pYmFeD6fGstHSo 9F1rHsaxhWeFiB X-Received: by 2002:a5d:5c89:0:b0:475:13e5:c878 with SMTP id ffacd0b85a97d-47aabd39c53mr5976764f8f.4.1783327149731; Mon, 06 Jul 2026 01:39:09 -0700 (PDT) Received: from skbuf ([2a02:2f04:d40e:d500:e1d4:332e:7c24:7e83]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47ad69519c2sm23892716f8f.37.2026.07.06.01.39.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jul 2026 01:39:08 -0700 (PDT) From: Vladimir Oltean X-Google-Original-From: Vladimir Oltean Date: Mon, 6 Jul 2026 11:39:06 +0300 To: Rosen Penev Cc: netdev@vger.kernel.org, Madalin Bucur , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , open list Subject: Re: [PATCH net-next] net: dpaa_eth: convert to napi_gro_receive Message-ID: <20260706083906.5oxmr47vbnaztfu2@skbuf> References: <20260706030632.1826810-1-rosenp@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260706030632.1826810-1-rosenp@gmail.com> Hi Rosen, On Sun, Jul 05, 2026 at 08:06:32PM -0700, Rosen Penev wrote: > Replace netif_receive_skb() with napi_gro_receive() to improve receive > performance for this driver. It has rx checksum support so routing speed > shouldn't suffer. > > Tested on a WatchGuard Firebox M300. > > iperf3 bidir speed test: > > [ ID][Role] Interval Transfer Bitrate Retr > [ 5][TX-C] 0.00-60.01 sec 5.35 GBytes 766 Mbits/sec 184 sender > [ 5][TX-C] 0.00-60.02 sec 5.35 GBytes 766 Mbits/sec receiver > [ 7][RX-C] 0.00-60.01 sec 5.50 GBytes 787 Mbits/sec 124 sender > [ 7][RX-C] 0.00-60.02 sec 5.49 GBytes 786 Mbits/sec receiver > > After: > > [ ID][Role] Interval Transfer Bitrate Retr > [ 5][TX-C] 0.00-60.01 sec 6.49 GBytes 929 Mbits/sec 0 sender > [ 5][TX-C] 0.00-60.02 sec 6.49 GBytes 928 Mbits/sec receiver > [ 7][RX-C] 0.00-60.01 sec 6.55 GBytes 938 Mbits/sec 0 sender > [ 7][RX-C] 0.00-60.02 sec 6.55 GBytes 937 Mbits/sec receiver > > Assisted-by: Opencode:big-pickle > Signed-off-by: Rosen Penev > --- > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c > index ad2d8256eb8d..83191f636ec7 100644 > --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c > +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c > @@ -2824,10 +2824,7 @@ static enum qman_cb_dqrr_result rx_default_dqrr(struct qman_portal *portal, > > skb_len = skb->len; > > - if (unlikely(netif_receive_skb(skb) == NET_RX_DROP)) { > - percpu_stats->rx_dropped++; > - return qman_cb_dqrr_consume; > - } > + napi_gro_receive(&np->napi, skb); > > percpu_stats->rx_packets++; > percpu_stats->rx_bytes += skb_len; > -- > 2.55.0 > > (thanks to Madalin for pointing out this change to me) I do not have time this week to test this patch, but in premise, you are creating exactly the conditions for this bug to occur: https://github.com/nxp-qoriq/linux/commit/d0ebec2092d6c5fe327513cb66e02d8c2c1a8f87 In sdk_dpaa we already do GRO for TCP flows and it has the problems pointed out in the above commit. With your change to use GRO for all capable flows, I currently have no reason to believe that without similar countermeasures as those taken by sdk_dpaa (napi_gro_receive() global to the entire QMan portal) the outcome would be different. Have you tested traffic in mixed scenarios, where flows from multiple interfaces land on the same CPU? Until further evidence comes in: pw-bot: cr