RE: RFC: NAPI packet weighting patch

What more do you need other than checking the statistics counter?  The
drop statistics (the ones we care about) are incremented in real time
by the ->poll() code, so it's not like we have to trigger some
asynchronous event to get a current version of the number.

I think that there is some more confusion here.  I'm talking about
frames dropped by the Ethernet controller at the hardware level (no
descriptor available).  This for example is happening now with our
driver with the weight set to 64.  This is also what started us looking
into what was going on with the weight.  I don't see how the NAPI code
to dynamically adjust the weight could easily get the hardware stats
number to know if frames are being dropped or not.  Sorry if I caused
the confusion here.

Mitch is working on a response to Jamal's last mail trying to level set
what we are seeing and doing.

Cheers,
John

Ronciak, John writes:
 > > What more do you need other than checking the statistics counter?  The
 > > drop statistics (the ones we care about) are incremented in real time
 > > by the ->poll() code, so it's not like we have to trigger some
 > > asynchronous event to get a current version of the number.
 > > 
 > 
 > I think that there is some more confusion here.  I'm talking about
 > frames dropped by the Ethernet controller at the hardware level (no
 > descriptor available).  This for example is happening now with our
 > driver with the weight set to 64.  This is also what started us looking
 > into what was going on with the weight.  I don't see how the NAPI code
 > to dynamically adjust the weight could easily get the hardware stats
 > number to know if frames are being dropped or not.  Sorry if I caused
 > the confusion here.

 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

 Cheers.
 					--ro