From: Wei Wang <weiwan@google.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>, Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Hannes Frederic Sowa <hannes@stressinduktion.org>,
Felix Fietkau <nbd@nbd.name>
Subject: Re: [PATCH net-next v9 1/3] net: extract napi poll functionality to __napi_poll()
Date: Wed, 3 Feb 2021 09:57:23 -0800 [thread overview]
Message-ID: <CAEA6p_DWqDbK_EFUXp+7XprBc3HegnV69qWhsPR4V_4K9oDGfA@mail.gmail.com> (raw)
In-Reply-To: <CAKgT0UdQCERxqcGmMe+xdF3aHvrRWzbCg+Wd3jGo=LREJayOQw@mail.gmail.com>
On Wed, Feb 3, 2021 at 9:00 AM Alexander Duyck
<alexander.duyck@gmail.com> wrote:
>
> On Fri, Jan 29, 2021 at 10:20 AM Wei Wang <weiwan@google.com> wrote:
> >
> > From: Felix Fietkau <nbd@nbd.name>
> >
> > This commit introduces a new function __napi_poll() which does the main
> > logic of the existing napi_poll() function, and will be called by other
> > functions in later commits.
> > This idea and implementation is done by Felix Fietkau <nbd@nbd.name> and
> > is proposed as part of the patch to move napi work to work_queue
> > context.
> > This commit by itself is a code restructure.
> >
> > Signed-off-by: Felix Fietkau <nbd@nbd.name>
> > Signed-off-by: Wei Wang <weiwan@google.com>
> > ---
> > net/core/dev.c | 35 +++++++++++++++++++++++++----------
> > 1 file changed, 25 insertions(+), 10 deletions(-)
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 0332f2e8f7da..7d23bff03864 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -6768,15 +6768,10 @@ void __netif_napi_del(struct napi_struct *napi)
> > }
> > EXPORT_SYMBOL(__netif_napi_del);
> >
> > -static int napi_poll(struct napi_struct *n, struct list_head *repoll)
> > +static int __napi_poll(struct napi_struct *n, bool *repoll)
> > {
> > - void *have;
> > int work, weight;
> >
> > - list_del_init(&n->poll_list);
> > -
> > - have = netpoll_poll_lock(n);
> > -
> > weight = n->weight;
> >
> > /* This NAPI_STATE_SCHED test is for avoiding a race
> > @@ -6796,7 +6791,7 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)
> > n->poll, work, weight);
> >
> > if (likely(work < weight))
> > - goto out_unlock;
> > + return work;
> >
> > /* Drivers must not modify the NAPI state if they
> > * consume the entire weight. In such cases this code
> > @@ -6805,7 +6800,7 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)
> > */
> > if (unlikely(napi_disable_pending(n))) {
> > napi_complete(n);
> > - goto out_unlock;
> > + return work;
> > }
> >
> > /* The NAPI context has more processing work, but busy-polling
> > @@ -6818,7 +6813,7 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)
> > */
> > napi_schedule(n);
> > }
> > - goto out_unlock;
> > + return work;
> > }
> >
> > if (n->gro_bitmask) {
> > @@ -6836,9 +6831,29 @@ static int napi_poll(struct napi_struct *n, struct list_head *repoll)
> > if (unlikely(!list_empty(&n->poll_list))) {
> > pr_warn_once("%s: Budget exhausted after napi rescheduled\n",
> > n->dev ? n->dev->name : "backlog");
> > - goto out_unlock;
> > + return work;
> > }
> >
> > + *repoll = true;
> > +
> > + return work;
> > +}
> > +
> > +static int napi_poll(struct napi_struct *n, struct list_head *repoll)
> > +{
> > + bool do_repoll = false;
> > + void *have;
> > + int work;
> > +
> > + list_del_init(&n->poll_list);
> > +
> > + have = netpoll_poll_lock(n);
> > +
> > + work = __napi_poll(n, &do_repoll);
> > +
> > + if (!do_repoll)
> > + goto out_unlock;
> > +
> > list_add_tail(&n->poll_list, repoll);
> >
> > out_unlock:
>
> Instead of using the out_unlock label why don't you only do the
> list_add_tail if do_repoll is true? It will allow you to drop a few
> lines of noise. Otherwise this looks good to me.
>
Ack.
> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
Thanks for the review.
next prev parent reply other threads:[~2021-02-03 18:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-29 18:18 [PATCH net-next v9 0/3] implement kthread based napi poll Wei Wang
2021-01-29 18:18 ` [PATCH net-next v9 1/3] net: extract napi poll functionality to __napi_poll() Wei Wang
2021-02-03 17:00 ` Alexander Duyck
2021-02-03 17:57 ` Wei Wang [this message]
2021-01-29 18:18 ` [PATCH net-next v9 2/3] net: implement threaded-able napi poll loop support Wei Wang
2021-02-03 17:20 ` Alexander Duyck
2021-02-03 17:59 ` Wei Wang
2021-01-29 18:18 ` [PATCH net-next v9 3/3] net: add sysfs attribute to control napi threaded mode Wei Wang
2021-02-03 0:28 ` Jakub Kicinski
2021-02-03 1:32 ` Wei Wang
2021-02-03 17:30 ` Alexander Duyck
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=CAEA6p_DWqDbK_EFUXp+7XprBc3HegnV69qWhsPR4V_4K9oDGfA@mail.gmail.com \
--to=weiwan@google.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hannes@stressinduktion.org \
--cc=kuba@kernel.org \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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).