netmap overrun counters

[Luigi Rizzo]

On Thu, Apr 28, 2016 at 9:15 PM, bazzoola <bazzoola at gmail.com> wrote:

>
>
> On 04/28/2016 12:06 PM, Luigi Rizzo wrote:
> >
> >
> > On Thursday, April 28, 2016, bazzoola <bazzoola at gmail.com
> > <mailto:bazzoola at gmail.com>> wrote:
> >
> >
> >
> >     On 04/28/2016 11:35 AM, Navdeep Parhar wrote:
> >     > On 04/28/2016 11:13, bazzoola wrote:
> >     >> Hi!
> >     >>
> >     >> Two questions:
> >     >>
> >     >> (1) Is there a way to know when netmap rx rings overrun? Most NIC
> >     >> drivers provide MPC (missed packet count) and sysctl for
> rx_overrun.
> >     >>
> >     >> I would like to know if my application is not reading as fast,
> >     i.e., no
> >     >> frames are being dropped.
> >     >
> >     > A NIC's hardware counters don't distinguish between netmap or
> normal
> >     > operation so you can monitor the existing sysctls for rx
> >     drops/overruns.
> >     >
> >     > Regards,
> >     > Navdeep
> >     >
> >
> >     Navdeep,
> >
> >     I am not asking about NIC's ring overrun. As you know netmap has its
> own
> >     rings. Is there a way to know if netmap's rx ring overrun?
> >
> >
> > Overruns by definition can only be counted by the NIC
> >
> > Cheers
> > Luigi
> >
> >
>
> Luigi,
>
> I will rephrase the question to avoid the 'overrun' definition.
>
> (1) if my application is not reading fast enough is there a way to know
> if netmap's rx ring starts overwriting unread slots?
>

​This never happens. When the ring is full the NIC stops writing
packets to the buffers and drops them​, counting them as overruns.
Same as with the standard drivers.


> Also, my section question was:
>
> (2) What is the benefit of NETMAP_DO_RX_POLL? I do see the slots being
> updated when I set this flag but 'tail' is not advancing unless I read.
>
>
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.
>

​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.

If it is your application that drops packets, it is because it has
read them so netmap cannot know that they have been dropped.

I think you are misled by the way the kernel operates, where
1) the NIC stores packets in the ring, then 2) the kernel
copies them in the socket buffer, and finally 3) the application
reads from the socket buffer. With netmap there is no #2

cheers
luigi