bge dropping packets issue

[Alexander Sack]

On Thu, Apr 17, 2008 at 9:13 PM, Bruce Evans <brde at optusnet.com.au> wrote:
> > So the million dollar question:  Do you believe that if I disable
> > DEVICE_POLLING and use interrupt driven I/O, I could achieve zero
> > packet loss over a 1Gbps link?  This is the main issue I need to solve
> > (solve means either no its not really achievable without a heavy
> > rewrite of the driver OR yes it is with some tuning).  If the answer
> > is yes, then I have to understand the impact on the system in general.
> > I just want to be sure I'm on a viable path through the BGE maze!
> >
>
>  I think you can get close enough if the bus and memory and CPU(s)
>  permit and you don't need to get too close to the theoretical limits.

Thanks again Bruce for the detailed response.

Here are my results:

Good news:

Well after fiddling around with it, it seems if I bump the number of
rx_bds to 512, disable polling, and use net.isr.direct=1, bge does not
drop packets anymore (as verified by assigning a counter within
bge_ticks() when a packet is dropped as read by the hardware
registers).  What's interesting is that there is also an outOfRxBDs
register you can read if you suspect chain starvation which I
discovered after looking at the Linux driver's more complete stat
structure.

Bad news:

Packets still get dropped but this time by BPF.  It seems I pushed the
problem upstream (in terms of the stack).  The user land software
listening in this instance is using BPF.  I guess my next adventure is
to understand how much can BPF take before dumping packets due to lack
of buffer space - currently net.bpf.bufsize is 1048576 which is the
maxbufsize.  Is this common place for BPF to drop packets?  (forgive
me I have not searched the mailing list as I just confirmed these
results by instrumenting BPF).  Could I raise the maxbufsize and still
operate safely?  (I do have 8GB on a 64-bit system).

Almost but no cigar....

-aps