Linux USB
 help / color / mirror / Atom feed
From: Hayes Wang <hayeswang@realtek.com>
To: Eric Dumazet <edumazet@google.com>
Cc: "kuba@kernel.org" <kuba@kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	nic_swsd <nic_swsd@realtek.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"bjorn@mork.no" <bjorn@mork.no>,
	"pabeni@redhat.com" <pabeni@redhat.com>
Subject: RE: [PATCH net-next resend 1/2] r8152: remove queuing rx packets in driver
Date: Mon, 18 Sep 2023 09:28:03 +0000	[thread overview]
Message-ID: <e3ad16c0e8414af6be25f4bf9ab5e1e3@realtek.com> (raw)
In-Reply-To: <CANn89i+Tou=YwteEd5ceaHP54sZpkRotwcV6YWAs4jAUq=ocJg@mail.gmail.com>

Eric Dumazet <edumazet@google.com>
> Sent: Monday, September 18, 2023 4:53 PM
[...]
> > > [1] More conventional way to to put this condition at the beginning of
> > > the while () loop,
> > > because the budget could be zero.
> >
> > If the budget is zero, the function wouldn't be called.
> > a7b8d60b3723 ("r8152: check budget for r8152_poll") avoids it.
> 
> Yes, and we could revert  this patch :/
> 
> Moving the test at the front of the loop like most other drivers would
> have avoided this issue,
> and avoided this discussion.

I don't do that because I want to avoid some checks and spin lock before and after
the loop. For example,

1. spin lock
2. move the ready lists to local
3. spin unlock
4. loop the lists
5. break the loop if budget is zero
6. spin lock
7. move the remained list back for next schedule
8. spin unlock

I could avoid the redundant behavior.

> > > > +               if (work_done >= budget)
> > > > +                       break;
> > > >         }
> > > >
> > > > +       /* Splice the remained list back to rx_done */
> > > >         if (!list_empty(&rx_queue)) {
> > > >                 spin_lock_irqsave(&tp->rx_lock, flags);
> > > > -               list_splice_tail(&rx_queue, &tp->rx_done);
> > > > +               list_splice(&rx_queue, &tp->rx_done);
> > > >                 spin_unlock_irqrestore(&tp->rx_lock, flags);
> > > >         }
> > > >
> > > >  out1:
> > > > -       return work_done;
> > > > +       if (work_done > budget)
> > >
> > > This (work_done >budget) condition would never be true if point [1] is
> > > addressed.
> >
> > A bulk transfer may contain many packets, so the work_done may be more
> than budget.
> > That is why I queue the packets in the driver before this patch.
> > For example, if a bulk transfer contains 70 packet and budget is 64,
> > napi_gro_receive would be called for the first 64 packets and 6 packets
> would
> > be queued in driver for next schedule. After this patch, napi_gro_receive()
> would
> > be called for the 70 packets, even the budget is 64. And the remained bulk
> transfers
> > would be handled for next schedule.
> 
> A comment would be nice. NAPI logic should look the same in all drivers.
> 
> If a driver has some peculiarities, comments would help to maintain
> the code in the long run.

I would update it. Thanks.

Best Regards,
Hayes



  reply	other threads:[~2023-09-18  9:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-18  7:41 [PATCH net-next resend 0/2] r8152: modify rx_bottom Hayes Wang
2023-09-18  7:42 ` [PATCH net-next resend 1/2] r8152: remove queuing rx packets in driver Hayes Wang
2023-09-18  7:54   ` Eric Dumazet
2023-09-18  8:38     ` Hayes Wang
2023-09-18  8:52       ` Eric Dumazet
2023-09-18  9:28         ` Hayes Wang [this message]
2023-09-18  7:42 ` [PATCH net-next resend 2/2] r8152: use napi_gro_frags Hayes Wang

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=e3ad16c0e8414af6be25f4bf9ab5e1e3@realtek.com \
    --to=hayeswang@realtek.com \
    --cc=bjorn@mork.no \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nic_swsd@realtek.com \
    --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