From owner-freebsd-net@freebsd.org Thu Apr 28 20:15:20 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 88D68B1F188 for ; Thu, 28 Apr 2016 20:15:20 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 DB1811332; Thu, 28 Apr 2016 20:15:19 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id u64so96781337lff.3; Thu, 28 Apr 2016 13:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=XPt8MNLFAhFKzaCsgd4nez1NTUaNp02YYAWwSDgdvPc=; b=h0BgC5VzmuIWy1njSO5jKM4OYRKUo178naQuv/bzJI8/BMmJVgUle7zAb3f93+JK8F Q5l7SjvoCWI5t1YU9ejiR1S3nXI5SUtKZlgC0ZYPwUflXh1cRKdJLTPYVR6M+mMl7LBP eQBu7IiVccJXP72dM1zEA+0AJimmyQvJj4SAo5UDFumixrcjnxxKJ5ryfe4+Q+jCRHXl Gf0QlX0Z+cGCyjJG0wtNDFrU8/4r38/iwCUF0FyLkcaZ5Tj+nAku1jdhrci671L0Lhvt +Ii2q1510op+IN+HQr0DaCRgPZIOXSWQV7HMgQm7A0BX+wOJ0xudyINXdNdY8qISZYgJ TEMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=XPt8MNLFAhFKzaCsgd4nez1NTUaNp02YYAWwSDgdvPc=; b=KSJfeYBhKH28g5wSB1I//PEBbniFk/2Iwod8OkSRZvvbeP+Rd09lHDvL0AUib4ZuMm IX/IrRwAfoQoqR7gLY2NNRTsIFxFfDtksLIWZrELkAqbC15LiTq1HtpafTXbaJE7eeWk XozrtfDPgMeAl6AtQQFEyFfrsdTjEki+6o7NgCeoy8ms5r8n1upuk7184YAODmVfNLkc v8f1PkSprJeRRyQi7Rdy9a9RRyTTtDBKW7LJNt8V+v4Ar/9eORLsGRSFthCGothJGyj9 ErVj0nDLu51THPfYg3eRaipipGp7bhirof7LS5gvzKHfhHg/d6JtlZvK0om35Iwo/2ua ft3Q== X-Gm-Message-State: AOPr4FVTQkaSxAmmKQY7gepSCdbDByKR+tqN/UmPK1R5Vk979mi99sDbL+s3+6L0+kxNhYmYxv+rouo2EaR3/w== MIME-Version: 1.0 X-Received: by 10.112.13.33 with SMTP id e1mr5953120lbc.79.1461874517515; Thu, 28 Apr 2016 13:15:17 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.79.102 with HTTP; Thu, 28 Apr 2016 13:15:17 -0700 (PDT) In-Reply-To: References: <9fd88731-2cdf-a6da-4b4e-f97bb120696a@FreeBSD.org> <863506de-870e-0da4-81d3-6ab537feaa2b@gmail.com> Date: Thu, 28 Apr 2016 22:15:17 +0200 X-Google-Sender-Auth: ejY72bkp3y-vzBpCnaAvYLWdHdI Message-ID: Subject: Re: netmap overrun counters From: Luigi Rizzo To: bazzoola Cc: Navdeep Parhar , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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 20:15:20 -0000 On Thu, Apr 28, 2016 at 9:15 PM, bazzoola wrote: > > > On 04/28/2016 12:06 PM, Luigi Rizzo wrote: > > > > > > On Thursday, April 28, 2016, bazzoola > > 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 NI= C > > >> 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 it= s > 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? > =E2=80=8BThis never happens. When the ring is full the NIC stops writing packets to the buffers and drops them=E2=80=8B, 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 the= m 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 returne= d 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 other= s 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=E2=80=8Bs 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. > =E2=80=8Bwrong 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