bge dropping packets issue
pisymbol at gmail.com
Fri Apr 18 17:56:15 UTC 2008
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:
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
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....
More information about the freebsd-net