From: Christian Marangi <ansuelsmth@gmail.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>,
Raju Rangoju <rajur@chelsio.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <joabreu@synopsys.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Ping-Ke Shih <pkshih@realtek.com>, Kalle Valo <kvalo@kernel.org>,
Simon Horman <horms@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jiri Pirko <jiri@resnulli.us>, Hangbin Liu <liuhangbin@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-wireless@vger.kernel.org
Subject: Re: [net-next PATCH 1/3] net: introduce napi_is_scheduled helper
Date: Mon, 2 Oct 2023 14:54:55 +0200 [thread overview]
Message-ID: <651abda3.df0a0220.a04f0.12df@mx.google.com> (raw)
In-Reply-To: <CANn89iLHMOh9Axt3xquzPjx0Dfn6obmSZJFSpzH51TKAN_nPqQ@mail.gmail.com>
On Mon, Oct 02, 2023 at 02:49:11PM +0200, Eric Dumazet wrote:
> On Mon, Oct 2, 2023 at 2:43 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> >
> > On Mon, Oct 02, 2023 at 02:35:22PM +0200, Eric Dumazet wrote:
> > > On Mon, Oct 2, 2023 at 2:29 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > >
> > > > Ehhh the idea here was to reduce code duplication since the very same
> > > > test will be done in stmmac. So I guess this code cleanup is a NACK and
> > > > I have to duplicate the test in the stmmac driver.
> > >
> > > I simply wanted to add a comment in front of this function/helper,
> > > advising not using it unless absolutely needed.
> > >
> > > Thus my question "In which context is it safe to call this helper ?"
> > >
> > > As long as it was private with a driver, I did not mind.
> > >
> > > But if made public in include/linux/netdevice.h, I would rather not
> > > have to explain
> > > to future users why it can be problematic.
> >
> > Oh ok!
> >
> > We have plenty of case similar to this. (example some clock API very
> > internal that should not be used normally or regmap related)
> >
> > I will include some comments warning that this should not be used in
> > normal circumstances and other warnings. If you have suggestion on what
> > to add feel free to write them.
> >
> > Any clue on how to proceed with the sge driver?
> >
>
> I would remove use of this helper for something with no race ?
>
> Feel free to submit this :
>
> (Alternative would be to change napi_schedule() to return a boolean)
>
Think mod napi_schedule() to return a bool would result in massive
warning (actually error with werror) with return value not handled.
I will submit with your Suggested-by. Ok for you?
> diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> index 2e9a74fe0970df333226b80af8716f30865c01b7..09d0e6aa4db982e3488e0c28bed33e83453801d0
> 100644
> --- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> @@ -2501,14 +2501,6 @@ static int napi_rx_handler(struct napi_struct
> *napi, int budget)
> return work_done;
> }
>
> -/*
> - * Returns true if the device is already scheduled for polling.
> - */
> -static inline int napi_is_scheduled(struct napi_struct *napi)
> -{
> - return test_bit(NAPI_STATE_SCHED, &napi->state);
> -}
> -
> /**
> * process_pure_responses - process pure responses from a response queue
> * @adap: the adapter
> @@ -2674,9 +2666,9 @@ static int rspq_check_napi(struct sge_qset *qs)
> {
> struct sge_rspq *q = &qs->rspq;
>
> - if (!napi_is_scheduled(&qs->napi) &&
> - is_new_response(&q->desc[q->cidx], q)) {
> - napi_schedule(&qs->napi);
> + if (is_new_response(&q->desc[q->cidx], q) &&
> + napi_schedule_prep(&qs->napi)) {
> + __napi_schedule(&qs->napi);
> return 1;
> }
> return 0;
--
Ansuel
WARNING: multiple messages have this Message-ID (diff)
From: Christian Marangi <ansuelsmth@gmail.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>,
Raju Rangoju <rajur@chelsio.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <joabreu@synopsys.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Ping-Ke Shih <pkshih@realtek.com>, Kalle Valo <kvalo@kernel.org>,
Simon Horman <horms@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jiri Pirko <jiri@resnulli.us>, Hangbin Liu <liuhangbin@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-wireless@vger.kernel.org
Subject: Re: [net-next PATCH 1/3] net: introduce napi_is_scheduled helper
Date: Mon, 2 Oct 2023 14:54:55 +0200 [thread overview]
Message-ID: <651abda3.df0a0220.a04f0.12df@mx.google.com> (raw)
In-Reply-To: <CANn89iLHMOh9Axt3xquzPjx0Dfn6obmSZJFSpzH51TKAN_nPqQ@mail.gmail.com>
On Mon, Oct 02, 2023 at 02:49:11PM +0200, Eric Dumazet wrote:
> On Mon, Oct 2, 2023 at 2:43 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> >
> > On Mon, Oct 02, 2023 at 02:35:22PM +0200, Eric Dumazet wrote:
> > > On Mon, Oct 2, 2023 at 2:29 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > >
> > > > Ehhh the idea here was to reduce code duplication since the very same
> > > > test will be done in stmmac. So I guess this code cleanup is a NACK and
> > > > I have to duplicate the test in the stmmac driver.
> > >
> > > I simply wanted to add a comment in front of this function/helper,
> > > advising not using it unless absolutely needed.
> > >
> > > Thus my question "In which context is it safe to call this helper ?"
> > >
> > > As long as it was private with a driver, I did not mind.
> > >
> > > But if made public in include/linux/netdevice.h, I would rather not
> > > have to explain
> > > to future users why it can be problematic.
> >
> > Oh ok!
> >
> > We have plenty of case similar to this. (example some clock API very
> > internal that should not be used normally or regmap related)
> >
> > I will include some comments warning that this should not be used in
> > normal circumstances and other warnings. If you have suggestion on what
> > to add feel free to write them.
> >
> > Any clue on how to proceed with the sge driver?
> >
>
> I would remove use of this helper for something with no race ?
>
> Feel free to submit this :
>
> (Alternative would be to change napi_schedule() to return a boolean)
>
Think mod napi_schedule() to return a bool would result in massive
warning (actually error with werror) with return value not handled.
I will submit with your Suggested-by. Ok for you?
> diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> index 2e9a74fe0970df333226b80af8716f30865c01b7..09d0e6aa4db982e3488e0c28bed33e83453801d0
> 100644
> --- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> @@ -2501,14 +2501,6 @@ static int napi_rx_handler(struct napi_struct
> *napi, int budget)
> return work_done;
> }
>
> -/*
> - * Returns true if the device is already scheduled for polling.
> - */
> -static inline int napi_is_scheduled(struct napi_struct *napi)
> -{
> - return test_bit(NAPI_STATE_SCHED, &napi->state);
> -}
> -
> /**
> * process_pure_responses - process pure responses from a response queue
> * @adap: the adapter
> @@ -2674,9 +2666,9 @@ static int rspq_check_napi(struct sge_qset *qs)
> {
> struct sge_rspq *q = &qs->rspq;
>
> - if (!napi_is_scheduled(&qs->napi) &&
> - is_new_response(&q->desc[q->cidx], q)) {
> - napi_schedule(&qs->napi);
> + if (is_new_response(&q->desc[q->cidx], q) &&
> + napi_schedule_prep(&qs->napi)) {
> + __napi_schedule(&qs->napi);
> return 1;
> }
> return 0;
--
Ansuel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-10-02 12:55 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-22 11:12 [net-next PATCH 1/3] net: introduce napi_is_scheduled helper Christian Marangi
2023-09-22 11:12 ` Christian Marangi
2023-09-22 11:12 ` [net-next PATCH 2/3] net: stmmac: improve TX timer arm logic Christian Marangi
2023-09-22 11:12 ` Christian Marangi
2023-09-29 12:38 ` Vincent Whitchurch
2023-09-29 12:38 ` Vincent Whitchurch
2023-09-30 12:04 ` Christian Marangi
2023-09-30 12:04 ` Christian Marangi
2023-09-22 11:12 ` [net-next PATCH 3/3] net: stmmac: increase TX coalesce timer to 5ms Christian Marangi
2023-09-22 11:12 ` Christian Marangi
2023-09-22 12:28 ` Andrew Lunn
2023-09-22 12:28 ` Andrew Lunn
2023-09-22 12:39 ` Christian Marangi
2023-09-22 12:39 ` Christian Marangi
2023-09-22 20:02 ` Dave Taht
2023-09-22 20:02 ` Dave Taht
2023-09-29 21:03 ` [net-next PATCH 1/3] net: introduce napi_is_scheduled helper Nambiar, Amritha
2023-09-29 21:03 ` Nambiar, Amritha
2023-09-30 11:59 ` Eric Dumazet
2023-09-30 11:59 ` Eric Dumazet
2023-09-30 12:11 ` Christian Marangi
2023-09-30 12:11 ` Christian Marangi
2023-09-30 13:42 ` Eric Dumazet
2023-09-30 13:42 ` Eric Dumazet
2023-10-02 12:29 ` Christian Marangi
2023-10-02 12:29 ` Christian Marangi
2023-10-02 12:35 ` Eric Dumazet
2023-10-02 12:35 ` Eric Dumazet
2023-10-02 12:43 ` Christian Marangi
2023-10-02 12:43 ` Christian Marangi
2023-10-02 12:49 ` Eric Dumazet
2023-10-02 12:49 ` Eric Dumazet
2023-10-02 12:54 ` Christian Marangi [this message]
2023-10-02 12:54 ` Christian Marangi
2023-10-02 12:56 ` Eric Dumazet
2023-10-02 12:56 ` Eric Dumazet
2023-10-02 12:59 ` Eric Dumazet
2023-10-02 12:59 ` Eric Dumazet
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=651abda3.df0a0220.a04f0.12df@mx.google.com \
--to=ansuelsmth@gmail.com \
--cc=alexandre.torgue@foss.st.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jiri@resnulli.us \
--cc=joabreu@synopsys.com \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-wireless@vger.kernel.org \
--cc=liuhangbin@gmail.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pkshih@realtek.com \
--cc=rajur@chelsio.com \
--cc=vincent.whitchurch@axis.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.