Date: Fri, 18 Apr 2008 13:56:06 -0400 From: "Alexander Sack" <pisymbol@gmail.com> To: "Bruce Evans" <brde@optusnet.com.au> Cc: freebsd-net@freebsd.org, Dieter <freebsd@sopwith.solgatos.com>, Jung-uk Kim <jkim@freebsd.org> Subject: Re: bge dropping packets issue Message-ID: <3c0b01820804181056u389d108ejb8bf81d0941ee66@mail.gmail.com> In-Reply-To: <20080418093328.B50187@delplex.bde.org> References: <3c0b01820804160929i76cc04fdy975929e2a04c0368@mail.gmail.com> <200804161456.20823.jkim@FreeBSD.org> <3c0b01820804161328m77704ca0g43077a9718d446d4@mail.gmail.com> <200804161654.22452.jkim@FreeBSD.org> <3c0b01820804161402u3aac4425n41172294ad33a667@mail.gmail.com> <20080417112329.G47027@delplex.bde.org> <3c0b01820804170643w6b771ce9jdfc2dc5b240922b@mail.gmail.com> <20080418093328.B50187@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 17, 2008 at 9:13 PM, Bruce Evans <brde@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c0b01820804181056u389d108ejb8bf81d0941ee66>