From: thomas.petazzoni@bootlin.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] net: mvneta: improve suspend/resume
Date: Fri, 30 Mar 2018 11:49:16 +0200 [thread overview]
Message-ID: <20180330114916.4e786de2@windsurf> (raw)
In-Reply-To: <20180330171547.5f96bbff@xhacker.debian>
Hello,
On Fri, 30 Mar 2018 17:15:47 +0800, Jisheng Zhang wrote:
> > > + cpuhp_state_remove_instance_nocalls(online_hpstate,
> > > + &pp->node_online);
> > > + cpuhp_state_remove_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
> > > + &pp->node_dead);
> >
> > Do we need to remove/add those CPU notifiers when suspending/resuming ?
>
> Take mvneta_cpu_online() as an example, if we don't remove it during
> suspend, when system is resume back, it will touch mac when secondary
> cpu is ON, but at this point the mvneta isn't resumed, this is not safe.
Hm. I'm still a bit confused by this new CPU hotplug API. I understand
the issue you have and indeed unregistering the CPU hotplug callbacks
is a way to solve the problem, but I find it weird that we have to do
this.
Anyway, it's OK to do it, because it's anyway what was done so far. It
is just annoying that there is a duplication of the logic between
mvneta_suspend() and mvneta_stop() on one side, and duplication between
mvneta_resume() and mvnete_start() on the other side.
> > > + for (queue = 0; queue < rxq_number; queue++) {
> > > + struct mvneta_rx_queue *rxq = &pp->rxqs[queue];
> > > +
> > > + mvneta_rxq_drop_pkts(pp, rxq);
> > > + }
> >
> > Wouldn't it make sense to have
> > mvneta_rxq_sw_deinit/mvneta_rxq_hw_deinit(), like you did for the
> > initialization ?
>
> For rxq deinit, we'd like to drop rx pkts, this is both HW and SW operation.
> So we reuse mvneta_rxq_drop_pkts() here.
Hum, OK, indeed. It would have been nicer to have something symmetric,
with the hw/sw parts split in a similar way for the init and deinit of
both txqs and rxqs, but I agree that dropping the RX packets before
going into suspend involves both HW and SW operations.
Thanks!
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Cc: David Miller <davem@davemloft.net>, <netdev@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] net: mvneta: improve suspend/resume
Date: Fri, 30 Mar 2018 11:49:16 +0200 [thread overview]
Message-ID: <20180330114916.4e786de2@windsurf> (raw)
In-Reply-To: <20180330171547.5f96bbff@xhacker.debian>
Hello,
On Fri, 30 Mar 2018 17:15:47 +0800, Jisheng Zhang wrote:
> > > + cpuhp_state_remove_instance_nocalls(online_hpstate,
> > > + &pp->node_online);
> > > + cpuhp_state_remove_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
> > > + &pp->node_dead);
> >
> > Do we need to remove/add those CPU notifiers when suspending/resuming ?
>
> Take mvneta_cpu_online() as an example, if we don't remove it during
> suspend, when system is resume back, it will touch mac when secondary
> cpu is ON, but at this point the mvneta isn't resumed, this is not safe.
Hm. I'm still a bit confused by this new CPU hotplug API. I understand
the issue you have and indeed unregistering the CPU hotplug callbacks
is a way to solve the problem, but I find it weird that we have to do
this.
Anyway, it's OK to do it, because it's anyway what was done so far. It
is just annoying that there is a duplication of the logic between
mvneta_suspend() and mvneta_stop() on one side, and duplication between
mvneta_resume() and mvnete_start() on the other side.
> > > + for (queue = 0; queue < rxq_number; queue++) {
> > > + struct mvneta_rx_queue *rxq = &pp->rxqs[queue];
> > > +
> > > + mvneta_rxq_drop_pkts(pp, rxq);
> > > + }
> >
> > Wouldn't it make sense to have
> > mvneta_rxq_sw_deinit/mvneta_rxq_hw_deinit(), like you did for the
> > initialization ?
>
> For rxq deinit, we'd like to drop rx pkts, this is both HW and SW operation.
> So we reuse mvneta_rxq_drop_pkts() here.
Hum, OK, indeed. It would have been nicer to have something symmetric,
with the hw/sw parts split in a similar way for the init and deinit of
both txqs and rxqs, but I agree that dropping the RX packets before
going into suspend involves both HW and SW operations.
Thanks!
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-03-30 9:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-29 10:12 [PATCH 0/2] net: mvneta: improve suspend/resume Jisheng Zhang
2018-03-29 10:12 ` Jisheng Zhang
2018-03-29 10:13 ` [PATCH 1/2] net: mvneta: split rxq/txq init into SW and HW parts Jisheng Zhang
2018-03-29 10:13 ` Jisheng Zhang
2018-03-29 11:42 ` Thomas Petazzoni
2018-03-29 11:42 ` Thomas Petazzoni
2018-03-30 9:04 ` Jisheng Zhang
2018-03-30 9:04 ` Jisheng Zhang
2018-03-29 10:15 ` [PATCH 2/2] net: mvneta: improve suspend/resume Jisheng Zhang
2018-03-29 10:15 ` Jisheng Zhang
2018-03-29 11:54 ` Thomas Petazzoni
2018-03-29 11:54 ` Thomas Petazzoni
2018-03-30 9:15 ` Jisheng Zhang
2018-03-30 9:15 ` Jisheng Zhang
2018-03-30 9:49 ` Thomas Petazzoni [this message]
2018-03-30 9:49 ` Thomas Petazzoni
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=20180330114916.4e786de2@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.