Date: Thu, 28 Apr 2016 14:53:25 -0700 From: bazzoola <bazzoola@gmail.com> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: Navdeep Parhar <np@freebsd.org>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: netmap overrun counters Message-ID: <1ea2e401-4b38-4277-a1d0-13b51e58d491@gmail.com> In-Reply-To: <CA%2BhQ2%2Bi7-6bbPR4JmDLuSP%2ByHr8Tra9PzQfZx3uHuNSzjt3JOg@mail.gmail.com> References: <cd306a81-3a4b-6386-a059-73d455d3c931@gmail.com> <9fd88731-2cdf-a6da-4b4e-f97bb120696a@FreeBSD.org> <863506de-870e-0da4-81d3-6ab537feaa2b@gmail.com> <CA%2BhQ2%2Bj%2BQyOTfKHhkp3KRQsD7aTdA=o4rQAZ_hnYXB8_x9py6Q@mail.gmail.com> <c004919a-21fd-51d9-eb35-8458ebe97652@gmail.com> <CA%2BhQ2%2Bi7-6bbPR4JmDLuSP%2ByHr8Tra9PzQfZx3uHuNSzjt3JOg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks Adrian, and thanks Luigi for the explanation: On 04/28/2016 01:15 PM, Luigi Rizzo wrote: > > please re-read the relevant part of the manual page: > > RECEIVE RINGS > On receive rings, after a netmap system call, the slots in the range > head... tail-1 contain received packets. User code should process them > and advance head and cur past slots it wants to return to the kernel. > cur may be moved further ahead if the user code wants to wait for more > packets without returning all the previous slots to the kernel. > > At the next NIOCRXSYNC/select()/poll(), slots up to head-1 are returned > to the kernel for further receives, and tail may advance to report new > incoming packets. > Below is an example of the evolution of an RX ring: > > after the syscall, there are some (h)eld and some (R)eceived slots > head cur tail > | | | > v v v > RX [..hhhhhhRRRRRRRR..........] > > user advances head and cur, releasing some slots and holding others > head cur tail > | | | > v v v > RX [..*****hhhRRRRRR...........] > > NICRXSYNC/poll()/select() recovers slots and reports new packets > head cur tail > | | | > v v v > RX [.......hhhRRRRRRRRRRRR....] > > > tail advances if there are new packets _and_ can at most go one > slot before head. At that point the buffer is full and the NIC > starts dropping packets until your application consumes packets, > advances head+cur and makes room so that the NIC can copy new > > packets to the buffers and the driver advances tail > > Basically, all I am trying to do is detect if frames are dropped in my > application using netmap API. > I am looking at https://www.freebsd.org/cgi/man.cgi?query=netmap&manpath=FreeBSD+11-current "Passing the NETMAP_DO_RX_POLL flag to NIOCREGIF updates receive rings even without read events" This means that even if I don't update cur/head pointers in my application then netmap will keep updating its rings. Is statement correct? If yes, how is this useful if tail doesn't increment. > > wrong model :) > netmap per se never drops packets because it does not run code. > > If your application does not read fast enough it is the NIC that > drops packets, and counts them as overrun; netmap cannot know > how many of them. I have a simple test (without NETMAP_DO_RX_POLL set), I send UDP packets with a known counter and monitor that counter in my netmap application. If there is a mismatch I know a packet was dropped. I also monitor sysctl em.0.overrun before and after I run the program and it stays 0. After around 20 seconds of of capturing frames (and storing them in memory), Swap kicks in (my program starts paging) and I detect the 1st dropped packet using my application. However, sysctl *overrun for em never reports drops. Should I look at a different stat? Thanks! B.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1ea2e401-4b38-4277-a1d0-13b51e58d491>