netdev
[Top] [All Lists]

Re: RFC: NAPI packet weighting patch

To: "Ronciak, John" <john.ronciak@xxxxxxxxx>
Subject: Re: RFC: NAPI packet weighting patch
From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Fri, 03 Jun 2005 11:33:00 -0700
Cc: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, jdmason@xxxxxxxxxx, shemminger@xxxxxxxx, hadi@xxxxxxxxxx, "Williams, Mitch A" <mitch.a.williams@xxxxxxxxx>, netdev@xxxxxxxxxxx, "Venkatesan, Ganesh" <ganesh.venkatesan@xxxxxxxxx>, "Brandeburg, Jesse" <jesse.brandeburg@xxxxxxxxx>
In-reply-to: <468F3FDA28AA87429AD807992E22D07E0450BFE8@orsmsx408>
Organization: Candela Technologies
References: <468F3FDA28AA87429AD807992E22D07E0450BFE8@orsmsx408>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1
Ronciak, John wrote:
It's not obvious that weight is to blame for frames dropped. I would look into RX ring size in relation to HW mitigation.
And of course if you system is very loaded the RX softirq gives room
for other jobs and frames get dropped



With the same system (fairly high end with nothing major running on it) we got rid of the dropped frames by just reducing the weight for 64. So the weight did have something to do with the dropped frames. Maybe other factors as well, but in static tests like this it sure looks like the 64 value is wrong is some cases.

Is this implying that having the NAPI poll do less work per poll of the driver actually increases performance? I would have guessed that the opposite would be true.

Maybe the poll is disabling the IRQs on the NIC for too long, or something
like that?

For e1000, are you using larger than the default 256 receive descriptors?
I have seen that increasing these descriptors helps decrease drops by
a small percentage.

Have you tried increasing the netdev-backlog setting to see if that
fixes the problem (while leaving the weight at the default)?

What packet sizes and speeds are you using for your tests?

Thanks,
Ben


-- Ben Greear <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com


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