Skip site navigation (1)Skip section navigation (2)
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,
> advance​s 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>