linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Eric Dumazet <edumazet@google.com>
To: Christian Marangi <ansuelsmth@gmail.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: Sat, 30 Sep 2023 15:42:20 +0200	[thread overview]
Message-ID: <CANn89iJqkpRu8rd_M7HCzaZQV5P_XTCzbKe5DOwnJkTRDZWEWw@mail.gmail.com> (raw)
In-Reply-To: <65181064.050a0220.7887c.c7ee@mx.google.com>

On Sat, Sep 30, 2023 at 2:11 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
>
> On Sat, Sep 30, 2023 at 01:59:53PM +0200, Eric Dumazet wrote:
> > On Fri, Sep 22, 2023 at 1:13 PM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > >
> > > We currently have napi_if_scheduled_mark_missed that can be used to
> > > check if napi is scheduled but that does more thing than simply checking
> > > it and return a bool. Some driver already implement custom function to
> > > check if napi is scheduled.
> > >
> > > Drop these custom function and introduce napi_is_scheduled that simply
> > > check if napi is scheduled atomically.
> > >
> > > Update any driver and code that implement a similar check and instead
> > > use this new helper.
> > >
> > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > > ---
> > >  drivers/net/ethernet/chelsio/cxgb3/sge.c  | 8 --------
> > >  drivers/net/wireless/realtek/rtw89/core.c | 2 +-
> > >  include/linux/netdevice.h                 | 5 +++++
> > >  net/core/dev.c                            | 2 +-
> > >  4 files changed, 7 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> > > index 2e9a74fe0970..71fa2dc19034 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
> > > diff --git a/drivers/net/wireless/realtek/rtw89/core.c b/drivers/net/wireless/realtek/rtw89/core.c
> > > index 133bf289bacb..bbf4ea3639d4 100644
> > > --- a/drivers/net/wireless/realtek/rtw89/core.c
> > > +++ b/drivers/net/wireless/realtek/rtw89/core.c
> > > @@ -1744,7 +1744,7 @@ static void rtw89_core_rx_to_mac80211(struct rtw89_dev *rtwdev,
> > >         struct napi_struct *napi = &rtwdev->napi;
> > >
> > >         /* In low power mode, napi isn't scheduled. Receive it to netif. */
> > > -       if (unlikely(!test_bit(NAPI_STATE_SCHED, &napi->state)))
> > > +       if (unlikely(!napi_is_scheduled(napi)))
> > >                 napi = NULL;
> > >
> > >         rtw89_core_hw_to_sband_rate(rx_status);
> > > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > > index db3d8429d50d..8eac00cd3b92 100644
> > > --- a/include/linux/netdevice.h
> > > +++ b/include/linux/netdevice.h
> > > @@ -482,6 +482,11 @@ static inline bool napi_prefer_busy_poll(struct napi_struct *n)
> > >         return test_bit(NAPI_STATE_PREFER_BUSY_POLL, &n->state);
> > >  }
> > >
> >
> >
> > In which context is it safe to call this helper ?
> >
>
> test_bit is atomic so it should be always safe. Also the idea of this
> check (and from what I can see this apply also to the other 2 user) is
> somehow best effort, we check if in the current istant there is a napi
> scheduled and we act.

I think testing a bit here is not enough to take any kind of useful decision,
unless used in a particular context.

>
> > I fear that making this available will add more bugs.
> >
> > For instance rspq_check_napi() seems buggy to me.
> >
>
> Mhhh why? Am I opening a can of worms?

Yes I think :/

Because only the thread that has grabbed the bit can make any sense of it.

Another thread reading it would not really know if the value is not going to
change immediately. So what would be the point ?

It seems rspq_check_napi() real intent was maybe the following,
but really this is hard to know if the current race in this code is okay or not.

diff --git a/drivers/net/ethernet/chelsio/cxgb3/sge.c
b/drivers/net/ethernet/chelsio/cxgb3/sge.c
index 2e9a74fe0970df333226b80af8716f30865c01b7..e153c9590b36b38e430bc93660146b428e9b3347
100644
--- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
@@ -2676,8 +2676,10 @@ static int rspq_check_napi(struct sge_qset *qs)

        if (!napi_is_scheduled(&qs->napi) &&
            is_new_response(&q->desc[q->cidx], q)) {
-               napi_schedule(&qs->napi);
-               return 1;
+               if (napi_schedule_prep(&qs->napi)) {
+                       __napi_schedule(&qs->napi);
+                       return 1;
+               }
        }
        return 0;
 }

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-09-30 13:43 UTC|newest]

Thread overview: 19+ 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 ` [net-next PATCH 2/3] net: stmmac: improve TX timer arm logic Christian Marangi
2023-09-29 12:38   ` Vincent Whitchurch
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 12:28   ` Andrew Lunn
2023-09-22 12:39     ` Christian Marangi
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-30 11:59 ` Eric Dumazet
2023-09-30 12:11   ` Christian Marangi
2023-09-30 13:42     ` Eric Dumazet [this message]
2023-10-02 12:29       ` Christian Marangi
2023-10-02 12:35         ` Eric Dumazet
2023-10-02 12:43           ` Christian Marangi
2023-10-02 12:49             ` Eric Dumazet
2023-10-02 12:54               ` Christian Marangi
2023-10-02 12:56                 ` 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=CANn89iJqkpRu8rd_M7HCzaZQV5P_XTCzbKe5DOwnJkTRDZWEWw@mail.gmail.com \
    --to=edumazet@google.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=ansuelsmth@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).