All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rahul Rameshbabu <rrameshbabu@nvidia.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, Tariq Toukan <tariqt@nvidia.com>,
	Gal Pressman <gal@nvidia.com>, Saeed Mahameed <saeedm@nvidia.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	David Miller <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Maxim Mikityanskiy <maxtram95@gmail.com>
Subject: Re: [PATCH net] sch_htb: Avoid grafting on htb_destroy_class_offload when destroying htb
Date: Wed, 11 Jan 2023 11:56:52 -0800	[thread overview]
Message-ID: <875ydcrgjf.fsf@nvidia.com> (raw)
In-Reply-To: <Y759ojjda4lh/vQk@nanopsycho> (Jiri Pirko's message of "Wed, 11 Jan 2023 10:13:06 +0100")

Jiri Pirko <jiri@resnulli.us> writes:

> Tue, Jan 10, 2023 at 09:20:04PM CET, rrameshbabu@nvidia.com wrote:
>>Peek at old qdisc and graft only when deleting leaf class in the htb. When
>>destroying the htb, the caller may already have grafted a new qdisc that is
>>not part of the htb structure being destroyed. htb_destroy_class_offload
>>should not peek at the qdisc of the netdev queue since that will either be
>
> You are not telling the codebase what to do. Do it in order to make it
> obvious what the patch is doing. That makes the patch description easier
> to understand.
>

I do think this description does describe what the patch is trying to
logically achieve rather than what the codebase itself is doing. The
goal of this patch is to correct htb_destroy_class_offload, so that it
will not attempt to graft a qdisc that does not belong to the htb (the
new qdisc), when destroying the htb entirely (the htb is destroyed when
replaced with another qdisc or explicitly destroyed). When deleting a
leaf, it makes sense to graft the leaf back if it failed to be deleted
by the device.

>
>>the new qdisc in the case of replacing the htb or simply a noop_qdisc is
>>the case of destroying the htb without a replacement qdisc.
>
>
> Looks to me like 2 fixes, shouldn't this be 2 patches instead?

This change is one logical fix in terms of refactoring the code to only
peek and graft the old qdisc when deleting a leaf of the htb. It
resolves issues in two use cases though.

  tc qdisc delete dev eth2 root handle 1: htb default 1 # deleting the htb

  tc qdisc replace dev eth2 root pfifo # replace htb with another qdisc

>
>
>>
>>Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload")
>>Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
>>Cc: Eric Dumazet <edumazet@google.com>
>>Cc: Maxim Mikityanskiy <maxtram95@gmail.com>
>>---
>> net/sched/sch_htb.c | 23 +++++++++++++----------
>> 1 file changed, 13 insertions(+), 10 deletions(-)
>>
>>diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
>>index 2238edece1a4..360ce8616fd2 100644
>>--- a/net/sched/sch_htb.c
>>+++ b/net/sched/sch_htb.c
>>@@ -1557,14 +1557,13 @@ static int htb_destroy_class_offload(struct Qdisc *sch, struct htb_class *cl,
>> 
>> 	WARN_ON(!q);
>> 	dev_queue = htb_offload_get_queue(cl);
>>-	old = htb_graft_helper(dev_queue, NULL);
>>-	if (destroying)
>>-		/* Before HTB is destroyed, the kernel grafts noop_qdisc to
>>-		 * all queues.
>>+	if (!destroying) {
>>+		old = htb_graft_helper(dev_queue, NULL);
>>+		/* Last qdisc grafted should be the same as cl->leaf.q when
>>+		 * calling htb_destroy
>> 		 */
>>-		WARN_ON(!(old->flags & TCQ_F_BUILTIN));
>>-	else
>> 		WARN_ON(old != q);
>>+	}
>> 
>> 	if (cl->parent) {
>> 		_bstats_update(&cl->parent->bstats_bias,
>>@@ -1581,10 +1580,14 @@ static int htb_destroy_class_offload(struct Qdisc *sch, struct htb_class *cl,
>> 	};
>> 	err = htb_offload(qdisc_dev(sch), &offload_opt);
>> 
>>-	if (!err || destroying)
>>-		qdisc_put(old);
>>-	else
>>-		htb_graft_helper(dev_queue, old);
>>+	/* htb_offload related errors when destroying cannot be handled */
>>+	WARN_ON(err && destroying);
>>+	if (!destroying) {
>>+		if (!err)
>>+			qdisc_put(old);
>>+		else
>>+			htb_graft_helper(dev_queue, old);
>>+	}
>> 
>> 	if (last_child)
>> 		return err;
>>-- 
>>2.36.2
>>

      reply	other threads:[~2023-01-11 19:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-10 20:20 [PATCH net] sch_htb: Avoid grafting on htb_destroy_class_offload when destroying htb Rahul Rameshbabu
2023-01-11  9:13 ` Jiri Pirko
2023-01-11 19:56   ` Rahul Rameshbabu [this message]

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=875ydcrgjf.fsf@nvidia.com \
    --to=rrameshbabu@nvidia.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gal@nvidia.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=maxtram95@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=saeedm@nvidia.com \
    --cc=tariqt@nvidia.com \
    --cc=xiyou.wangcong@gmail.com \
    /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.