From owner-freebsd-net@freebsd.org Thu Apr 28 21:53:27 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 520FCB208D3 for ; Thu, 28 Apr 2016 21:53:27 +0000 (UTC) (envelope-from bazzoola@gmail.com) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 219151C83; Thu, 28 Apr 2016 21:53:27 +0000 (UTC) (envelope-from bazzoola@gmail.com) Received: by mail-pf0-x242.google.com with SMTP id r187so12359294pfr.2; Thu, 28 Apr 2016 14:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=8uhO92cUcw+FI3A21Rch0tbtPdNldY9MAj4vNrXkEeU=; b=uKrFKpwVe5vOWwGsUYnXd5gS0/Hietk9OvEimWG39fPaVv2yIy1HZhRP7iKB0VlVan QCFEb4r1kgLsb/xDz9l99XGQG21itCGLmJcLC/mUzE0Cox/koKBkXxcvcamt2twWGRhw eL6T0sQFgjXzOw8+xWCr7hwIUfoFPQrgSqwqtpD0HK/XKB4S2Tc5UbxK3l1rSTRRVXmf TDt7GVF96lyUlCXZWYI2hBa8v9gpsCn+Hd5OhOh2wOFXCk5C66+Sq4osCXTINtlsx7qh X8mj8pr8U2qAXgQRzw0XNrL+MiFyniGZcZIWuQ/MBDZZl02nSA7hWmvNOlIIA8TFPebg JIgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=8uhO92cUcw+FI3A21Rch0tbtPdNldY9MAj4vNrXkEeU=; b=jYsziXKNX7b/CyEf0zrTUdX2cfHzpXsaygtj3Ibtds+kZNmX/BeNJAJmV6Jhf5oFAg g/8a/siKt6ridSOWuRwxG1Sdd5nmWmvj8edOAY5U1+OgEWQkmnh8atKtuAYJN8CzTK8W 2posJoCzaTwhTy+n32xeLdBGoKR11Zxr0PxJ6YWdcViMn2K2UR1Mz93Mm1RHLuHIDkpN /OwERWN8S+BcnxrhkvP9WkmktNUWhfd2fudR4xwWaZaKNkNYXX3UxBTMcqpcHByTBKWr atY2UkEQnEHTU1H0QTeRl624IVJppPWcs5tAwsYosVbSGLqzRpXOU3zahtfe/aoMDlAe 2Hxg== X-Gm-Message-State: AOPr4FUUpdM8uzuV2qvGjHvr6Jw+1b1DaCDs4ZuPi2Jvb8OwxAf2YQ8sZTp4/1NiR6tElg== X-Received: by 10.98.83.65 with SMTP id h62mr24090701pfb.163.1461880406777; Thu, 28 Apr 2016 14:53:26 -0700 (PDT) Received: from ?IPv6:2620:83:8001:24::1:567? ([2620:83:8001:24::1:567]) by smtp.googlemail.com with ESMTPSA id 76sm17580196pfz.44.2016.04.28.14.53.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2016 14:53:26 -0700 (PDT) Subject: Re: netmap overrun counters To: Luigi Rizzo References: <9fd88731-2cdf-a6da-4b4e-f97bb120696a@FreeBSD.org> <863506de-870e-0da4-81d3-6ab537feaa2b@gmail.com> Cc: Navdeep Parhar , "freebsd-net@freebsd.org" From: bazzoola Message-ID: <1ea2e401-4b38-4277-a1d0-13b51e58d491@gmail.com> Date: Thu, 28 Apr 2016 14:53:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 21:53:27 -0000 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.