[Top] [All Lists]

Re: NAPI: dev.c change to net_rx_action algorithm.

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: NAPI: dev.c change to net_rx_action algorithm.
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Fri, 08 Nov 2002 21:30:37 -0800
Cc: "'netdev@xxxxxxxxxxx'" <netdev@xxxxxxxxxxx>
Organization: Candela Technologies
References: <Pine.GSO.4.30.0211082351540.16986-100000@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910
jamal wrote:

On Fri, 8 Nov 2002, Ben Greear wrote:
I'm looking for the real cause.
No you are not. You are looking for something that will give you some
quick fix given your current setup.

Guilty, and as soon as I get this particular config optomized, I will
move on to the next scenario.  If the next scenario is better by some
other hack, then I will figure out how to reconcile the two, or make
the algorithms dynamic if I have to.

Be systematic about and prove where things are wrong. I even made some
suggestions to you a while back.

Things are wrong:  I can't tx and rx 8kpps (50Mbps) on 4 ports simultaneously.
I have fiddled with every magic static constant I could find, so now I'm
fidling with algoritms.  Primary culprit is rx-drop, which means the NIC
is not getting serviced in time, if I understand correctly.  I have 1024
rx-ring, which most agree is too large already, and yet it fills before
I can empty it.

Btw, and you'll love this one, if I change the priority of the irq thread
to -18, things get even better ;)

From what I can tell, the old code punishes interfaces who are
running slower at any given time.

You are totaly wrong. Go and read the paper on DRR.

I read the code.  It's likely I'm confused, but here is how
I interpret it.

#  If we are out of quota, refill quota but do not poll.
#    Why shouldn't we poll here?  We wouldn't be in this list
#    If there was nothing to poll, eh?

#  If we have quota, poll, but only refill quota if we still have
#  more work to do.  Busy devices have more work to do.  Slow ones
#  will not.  So, slow devices will have < dev->weight quota much of
#  the time.  If the formerly slow device suddenly gets a large burst of
#  traffic, it's first poll will likely be for a quota smaller than
#  dev->weight.  Why would this be good?

#  If we have quota, but do not not have more work to do after polling,
#  then pop out of the queue.  Note quota is not refilled in this case,
#  again punishing devices that are running slower.

                if (dev->quota <= 0 || dev->poll(dev, &budget)) {
                        list_add_tail(&dev->poll_list, &queue->poll_list);
                        if (dev->quota < 0)
                                dev->quota += dev->weight;
                                dev->quota = dev->weight;
                } else {

I see better results with the change below.  Why is that?

You tell me.

I think my algorithm is better, at least for this case.  It may
be worse for others, though I'm not sure why it would be.  The
one thing you can be certain of is that I'll let you know if
I figure it out :)


Ben Greear <greearb@xxxxxxxxxxxxxxx>       <Ben_Greear AT>
President of Candela Technologies Inc

<Prev in Thread] Current Thread [Next in Thread>