From owner-freebsd-net@FreeBSD.ORG Sun May 3 07:09:55 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41184906 for ; Sun, 3 May 2015 07:09:55 +0000 (UTC) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 015091B33 for ; Sun, 3 May 2015 07:09:55 +0000 (UTC) Received: by oica37 with SMTP id a37so93917532oic.0 for ; Sun, 03 May 2015 00:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=eNg11puqHdhPuldtpK9EsWTUCLCZ8uYpwafuw70+EhQ=; b=U6uboGoQ66cj0zbnUvWVtagiPcLiuf9LKb6XAa5IS8ok7szU/8cfRQagy+Ou9ZQlR+ xhvmZpDctKbGLororv+Unn5s3TjwgG+f6+xpyFDdhRNLR3X567Hlt+VyUUiSH89miXnX 9VitTSvFwGbz2VisDPqghkDoqwzLHHvIJ0NOzYJJ5329/ikjnW3vSWxJE+xqpImlVdbV eHt6Jkbe4jqjVJAqGZ0EOejxevQxWs8rKcfRVxXGWxyK1Da3wRXKeDDAFnRdaz45DJ9S YrjQFhJpxvfXVdr5Tm9A18IFCHdlJa9ElDqnHYiRlGWQEKMiQJGIFPCFbL6VR6W/L+8p 4Ikg== X-Received: by 10.182.27.103 with SMTP id s7mr8990968obg.2.1430636993705; Sun, 03 May 2015 00:09:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.87.198 with HTTP; Sun, 3 May 2015 00:09:33 -0700 (PDT) In-Reply-To: References: <9C799778-79DC-4D5F-BA5C-EA94A573ED10@freebsdbrasil.com.br> From: Raimundo Santos Date: Sun, 3 May 2015 04:09:33 -0300 Message-ID: Subject: Fwd: netmap-ipfw on em0 em1 To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 07:09:55 -0000 Clarifying things for the sake of documentation: To use the host stack, append a ^ character after the name of the interface you want to use. (Info from netmap(4) shipped with FreeBSD 10.1 RELEASE.) Examples: "kipfw em0" does nothing useful. "kipfw netmap:em0" disconnects the NIC from the usual data path, i.e., there are no host communications. "kipfw netmap:em0 netmap:em0^" or "kipfw netmap:em0+" places the netmap-ipfw rules between the NIC and the host stack entry point associated (the IP addresses configured on it with ifconfig, ARP and RARP, etc...) with the same NIC. On 10 November 2014 at 18:29, Evandro Nunes wrote: > dear professor luigi, > i have some numbers, I am filtering 773Kpps with kipfw using 60% of CPU and > system using the rest, this system is a 8core at 2.4Ghz, but only one core > is in use > in this next round of tests, my NIC is now an avoton with igb(4) driver, > currently with 4 queues per NIC (total 8 queues for kipfw bridge) > i have read in your papers we should expect something similar to 1.48Mpps > how can I benefit from the other CPUs which are completely idle? I tried > CPU Affinity (cpuset) kipfw but system CPU usage follows userland kipfw so > I could not set one CPU to userland while other for system > All the papers talk about *generating* lots of packets, not *processing* lots of packets. What this netmap example does is processing. If someone really wants to use the host stack, the expected performance WILL BE worse - what's the point of using a host stack bypassing tool/framework if someone will end up using the host stack? And by generating, usually the papers means: minimum sized UDP packets. > > can you please enlighten? > For everyone: read the manuals, read related and indicated materials (papers, web sites, etc), and, as a least resource, read the code. Within netmap's codes, it's more easy than it sounds.