[net-next] vmxnet3: increase default rx ring sizes

We often notice rx packet drops due to small default rx ring sizes and
solve the problem by increasing the ring sizes. This patch increases the
default rx ring sizes thereby reducing the probability of rx packet
drops out of the box.

Signed-off-by: Shrikrishna Khare <skhare@vmware.com>
Acked-by: Jin Heo <heoj@vmware.com>
Acked-by: Guolin Yang <gyang@vmware.com>
Acked-by: Boon Ang <bang@vmware.com>
---
 drivers/net/vmxnet3/vmxnet3_int.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

>  /*
>   * Version numbers
>   */
> -#define VMXNET3_DRIVER_VERSION_STRING   "1.4.a.0-k"
> +#define VMXNET3_DRIVER_VERSION_STRING   "1.4.11.0-k"
>  
>  /* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
> -#define VMXNET3_DRIVER_VERSION_NUM      0x01040a00
> +#define VMXNET3_DRIVER_VERSION_NUM      0x01040b00

Version strings in drivers are totally pointless, but should not this
be 0x01041100?

   Andrew

On Tue, 28 Nov 2017, Andrew Lunn wrote:

> >  /*
> >   * Version numbers
> >   */
> > -#define VMXNET3_DRIVER_VERSION_STRING   "1.4.a.0-k"
> > +#define VMXNET3_DRIVER_VERSION_STRING   "1.4.11.0-k"
> >  
> >  /* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
> > -#define VMXNET3_DRIVER_VERSION_NUM      0x01040a00
> > +#define VMXNET3_DRIVER_VERSION_NUM      0x01040b00
> 
> Version strings in drivers are totally pointless, but should not this
> be 0x01041100?
> 

Version number is hex value written to vmxnet3 emulation, thus 0x1040b00 
is correct (0x0b = 11). The VERSION_STRING should have previously been 
"1.4.10.0-k", this patch rectifies that by setting correct value 
"1.4.11.0-k".

I will let John Savanyo (cc'ed) comment on having the version in the 
driver part.

Thanks,
Shri

From: Shrikrishna Khare <skhare@vmware.com>
Date: Tue, 28 Nov 2017 13:12:04 -0800

> We often notice rx packet drops due to small default rx ring sizes and
> solve the problem by increasing the ring sizes. This patch increases the
> default rx ring sizes thereby reducing the probability of rx packet
> drops out of the box.
> 
> Signed-off-by: Shrikrishna Khare <skhare@vmware.com>
> Acked-by: Jin Heo <heoj@vmware.com>
> Acked-by: Guolin Yang <gyang@vmware.com>
> Acked-by: Boon Ang <bang@vmware.com>

That's not enough for me.

If you're going to quadruple your default RX ring size I want to
hear more about the research you did into the packet drops and
whether other things can be done to solve the problem.

Is something holding onto the packets unnecessarily long?

Is something blocking interrupts (hardware or software)?

Is an offload miscoded or misbehaving?

Is there a problem with the RX ring replenish algorithm of the
driver or it's heuristics?

Tell me more about that than just "bumping the RX ring
size fixes the problem".

Thank you.

From: Boon Ang <bang@vmware.com>
Date: Wed, 29 Nov 2017 16:25:16 +0000

> I hope the above explains our motivation.  Let us know if you have
> more questions.

Please add these descriptive details to your commit message and
resubmit.