From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     netdev@vger.kernel.org
Cc:     "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Jamal Hadi Salim <jhs@mojatatu.com>,
        Cong Wang <xiyou.wangcong@gmail.com>,
        Jiri Pirko <jiri@resnulli.us>,
        Vinicius Costa Gomes <vinicius.gomes@intel.com>,
        Kurt Kanzenbach <kurt@linutronix.de>,
        Jacob Keller <jacob.e.keller@intel.com>,
        Gerhard Engleder <gerhard@engleder-embedded.com>,
        Jesse Brandeburg <jesse.brandeburg@intel.com>,
        Tony Nguyen <anthony.l.nguyen@intel.com>,
        intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2 net-next 02/15] net/sched: taprio: continue with other TXQs if one dequeue() failed
Date:   Tue,  7 Feb 2023 15:54:27 +0200
Message-Id: <20230207135440.1482856-3-vladimir.oltean@nxp.com>
In-Reply-To: <20230207135440.1482856-1-vladimir.oltean@nxp.com>
References: <20230207135440.1482856-1-vladimir.oltean@nxp.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?4ysDQypWn5AaN0x1tXMq1nha2TuhqA1+pYkbbLAJFD8TycpgihJO8DVUE1pp?=
 =?us-ascii?Q?ErOmI2rPAHvyU5tLl5XG8qEbvJtboAeIW4W69QnpQ3azbtR9Y333PgYPojvF?=
 =?us-ascii?Q?wR3Ny5ZuT07cYI+j4BjpIWNULJD/p3wFVlCtOckDpQg/sjBY8DbSreVE0j4C?=
 =?us-ascii?Q?fLThcBXfnDGRXuuqe3lvr0Fd45sGyoNufUtKjSc53HR85iA1dM65MbyrhCNA?=
 =?us-ascii?Q?ZD43RS1B9G1zksgQ9vWbqc2Rp0f1Spxtrqb+YWExCuQPNMdFAB5VfFI8e1Gc?=
 =?us-ascii?Q?iamFdwZPqobHOpe9XU7MjVfFpRpQ3AC6CcsEGcOy+A8v8qx8bbRpkW1VthTD?=
 =?us-ascii?Q?wvnt1kg/T+BMcnMjWWYlW8Bm5owOIS6sO7dYQmlSVIuuuxmj89lcP4IInebf?=
 =?us-ascii?Q?X5Hq7F/0kCZ0vMEebWJIOkHY1pbIFR5woGRsdhJDuF86ZIqvt5UKMwSxkH6Q?=
 =?us-ascii?Q?dZNBLmaepOTeflt4EkDl1oaXzeY1iCoR7rE5HUIFBCuQaZuW6LFfI4ucZAA5?=
 =?us-ascii?Q?1J3rDWqSxXofD5v8ijrGtc3WwQ6cUmishHbDHW0enioxr2BQrBDqQ95padC1?=
 =?us-ascii?Q?zxV8ndhYI795Jdy9B+jGBfXPJo+WguWqes2T4y/RL04/Gw7mJ9K9DHNQa+KX?=
 =?us-ascii?Q?gMTIxa6X8c6FprOaGYeECpF+QkAvfjeZx0TBtSrUmxPutqKz3C4oFnQolCto?=
 =?us-ascii?Q?Pi5CIsLGgY9jktrf13q10q/B4dfcN2ap9LnvEB826PjP7tseoPoSihbkclI2?=
 =?us-ascii?Q?CgCAJ2jucs7kM4UmNvbNxPWkEW/FygrhjBY/fNOnHMudWlXVyWHhnOUkivi3?=
 =?us-ascii?Q?PmqBvwyuadAYYIyV3xIKr6hoeO2LdX5VsXSJM5ir+PcvHlAzO/IfKdNI5Z4z?=
 =?us-ascii?Q?iS0NTEZx5GIdsHH4bQlgMf9eZgnuIusb1DHnuzyK4/FfG4GTDifeZsRNGK/P?=
 =?us-ascii?Q?bYU72unzAo/d1bXyWgQ+3xakNkOrTbW+E2g8DhOxbnP4EhTJ2ZUmQ5FWc1mS?=
 =?us-ascii?Q?fpfo7Ct6d8Kw95vfHx30SnA4a/Fw/kJXotInzlrEdwQU0Z9Imln26g2Hz345?=
 =?us-ascii?Q?YQ2Qo1Ra3zXJNnbW8soMbVW21GCAYyz0U241um38bEzgx75gWLtPR3St6jd2?=
 =?us-ascii?Q?kV+Rb8OqZOiCQk1tHDUFqfaSrXSpCKdqjwh0e+M9GeF79jbTXCXIWYhrZEu0?=
 =?us-ascii?Q?kBfAaH8V+2yllo/56w9FXoOb39FcjgM/tjPCF2v7vUEJHnM7pMNNVIaqj0/h?=
 =?us-ascii?Q?e3oIb5WoUDzTagqlk40QIHA+bqQKFhANPp8m7KfR64rs4xZ7s69AshrQYlj3?=
 =?us-ascii?Q?EHgPTAnDKjDM041srImpTxlKT0uFflI9ZXqhWB2eyJJn8BChGn1q9JQxqxzl?=
 =?us-ascii?Q?iCF9kP5I+u6TjPW7k/74f2f435ySE4hFSvv2iaEc8VdgHjvpSE/79ITDsE1c?=
 =?us-ascii?Q?3Ba+fzwGxQCLh2DbGydYvnqrhKwx6ZgDN4Jzo2bkpDjoV/gJZcsPfjgc658w?=
 =?us-ascii?Q?wRKkFKJK3f0clItgrMFjq8Xp6OHMiNgP7s+qWVb6SbsfO9CC7GapQGnog7F9?=
 =?us-ascii?Q?nxasbr1398b2kVLN37KVS46ywVjaHiWwks90dRnBGmWcgqNxxqgMy7ySRu1V?=
 =?us-ascii?Q?SQ=3D=3D?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 865c8c28-d67c-419c-4d9e-08db0912eb3d
X-MS-Exchange-CrossTenant-AuthSource: VI1PR04MB5136.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2023 13:55:06.6906
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: KVdRDMN1Y3EpGCtgavt4PwuSltua+1KH9DK4e3vbjfMgqENz6zgFRVlUNGeD7G3sGGOM4R+QMpVakFcYsVKO5A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR04MB8115
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

This changes the handling of an unlikely condition to not stop dequeuing
if taprio failed to dequeue the peeked skb in taprio_dequeue().

I've no idea when this can happen, but the only side effect seems to be
that the atomic_sub_return() call right above will have consumed some
budget. This isn't a big deal, since either that made us remain without
any budget (and therefore, we'd exit on the next peeked skb anyway), or
we could send some packets from other TXQs.

I'm making this change because in a future patch I'll be refactoring the
dequeue procedure to simplify it, and this corner case will have to go
away.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>
---
v1->v2: none

 net/sched/sch_taprio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index d9e26ddaa7f2..0fde303978a5 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -587,7 +587,7 @@ static struct sk_buff *taprio_dequeue(struct Qdisc *sch)
 
 		skb = child->ops->dequeue(child);
 		if (unlikely(!skb))
-			goto done;
+			continue;
 
 skb_found:
 		qdisc_bstats_update(sch, skb);
-- 
2.34.1