From owner-freebsd-net@FreeBSD.ORG Sun May 3 16:22:47 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 5F6D2B48 for ; Sun, 3 May 2015 16:22:47 +0000 (UTC) Received: from nm49-vm8.bullet.mail.ne1.yahoo.com (nm49-vm8.bullet.mail.ne1.yahoo.com [98.138.121.136]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 27D321DB1 for ; Sun, 3 May 2015 16:22:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430670010; bh=7U5yG9bwwuZ1LEF3Gw41Nk9JVrnXSJR924g7OmcAEOM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Vxi4M1JRy+vEc4yFEbu7DnrmHl7finecpnMBUCEZQnVnpEggrazGF9mBJfnt+8XZC3t1DwBIkUj05talI0SbNED87xliR5drG7bj4mHWN3RzTxUCZKX+jSQxecQGiXrYFwd6/Ukyxt6EE3LJYsKUvdXZKc6nzA3P3mvl/b+03+1hIEW7TLKMXSLQYySSVMy17BQYQFjU6rP28K5mQ3fRpLOY32/YrSCwl0HrGWEVMrPfJd1s5GlOr8D+oCUmDOW3xt6OOn/rpTTU+UYvbSDbpRphgUbT6LrK35V8KUuQ9I0y4BsDng4FrJi5i0SCusP936FwuXLf6w4TBLh1kigzfg== Received: from [127.0.0.1] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 03 May 2015 16:20:10 -0000 Received: from [98.138.100.102] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 03 May 2015 16:17:30 -0000 Received: from [98.138.89.170] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 03 May 2015 16:17:30 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 03 May 2015 16:17:30 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 471016.26845.bm@omp1026.mail.ne1.yahoo.com X-YMail-OSG: LgL_3O8VM1lV6DUKVvjnd77DMft15uQhXv_OlqcXK9cvwCL6lbCIknbYNeBjdCz YV1FbzfJ7BompZNgpHxVbtJp7KOzkEH4URKUj4mTxzeQq4X06XMJy2eI1E3.kT9zudLxZdnUuVDE Z3fqzq6hFE8gXu.DnHpZ3SpfGfN8QfIgMMt34bQ5w1wbl4r3Gb9HEcPhwHYeWrn4vT5VY0L67i1q ZmY58VI9Anfx7jihOitvSTInyg4j4sKBNsMDGkBLqCmkh3FoT1CR0Yiq68Z3HGyaXTtHlfZ6O309 jkpXVwTR.h6iOvSWSMqJUQOfkJ8m80mbwF._nSF66oL8kNXI3jss1YieB7XqNpI1vUwfj4K9uOdr XEOi5SgVAds7FKmCVb.0aogiXZwzWqhB9yDhFq91aocXCdk7JqjLgeUyPxr9DilWWzpz6VFF6aR0 nvVKmQIF7m.UQcrtQ9mGqA366dVGRXzoUL01OsFXiEF2_7K992qWZWBQy6jWCzp_I35oi9QX0o.M 0x7Ym2tONbfAFoi.lX.wX6O50vw-- Received: by 98.138.101.177; Sun, 03 May 2015 16:17:30 +0000 Date: Sun, 3 May 2015 16:17:29 +0000 (UTC) From: Barney Cordoba Reply-To: Barney Cordoba To: "freebsd-net@freebsd.org" Message-ID: <1574363412.546978.1430669849590.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: Subject: Re: Fwd: netmap-ipfw on em0 em1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 16:22:47 -0000 Frankly I'm baffled by netmap. You can easily write a loadable kernel module that moves packets from 1 interface to another and hook in the firewall; why would you want to bring them up into user space? It's 1000s of lines of unnecessary code. On Sunday, May 3, 2015 3:10 AM, Raimundo Santos wrote: 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. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun May 3 18:12:47 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC670FB for ; Sun, 3 May 2015 18:12:47 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 6B416183D for ; Sun, 3 May 2015 18:12:47 +0000 (UTC) Received: by lbcga7 with SMTP id ga7so92199301lbc.1 for ; Sun, 03 May 2015 11:12:44 -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:content-type; bh=QnZLu/vmoOZH6lfYm0ZZ5pswS4hgsG6nD+fS97F93oA=; b=wOt58lktK7OvFmOmc9gJed/Pmy6nEAw3craUf1h9elEAuvOxCHGbzGr0S6O40LmzwA FwD8FsvABQF1gDnbr/FvhlJSTEKUJ+UUvpzIx/qufqmg6PECIwaKo0AjtYnVXFXcwx3o aEXE80+aNnQfK6sFdd4V/E4nz+nSkChq9cMeK54ZFUvuv0pPklNVJsGHBhXXuSsb88JZ +iLSktORaXWOvsUQlBkK9HLiu/dhb6vNjde/HGsqPGzs/cvI401CEFq8QVfCk2H/TB+r V9YzTwMxCAWdEVbrWbaYx1wEqUtkNlJ6Q/3rrcUFJu9wR3wQ3kqumqfkdnqTGXsIZ7iu tAiA== MIME-Version: 1.0 X-Received: by 10.153.5.8 with SMTP id ci8mr16667014lad.62.1430676764220; Sun, 03 May 2015 11:12:44 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.20.232 with HTTP; Sun, 3 May 2015 11:12:44 -0700 (PDT) In-Reply-To: <1574363412.546978.1430669849590.JavaMail.yahoo@mail.yahoo.com> References: <1574363412.546978.1430669849590.JavaMail.yahoo@mail.yahoo.com> Date: Sun, 3 May 2015 20:12:44 +0200 X-Google-Sender-Auth: elXQjBvjZ12dS6_p3WLJzLOw_Mw Message-ID: Subject: Re: Fwd: netmap-ipfw on em0 em1 From: Luigi Rizzo To: Barney Cordoba Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 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 18:12:48 -0000 On Sun, May 3, 2015 at 6:17 PM, Barney Cordoba via freebsd-net < freebsd-net@freebsd.org> wrote: > Frankly I'm baffled by netmap. You can easily write a loadable kernel > module that moves packets from 1 interface to another and hook in the > firewall; why would you want to bring them up into user space? It's 1000s > of lines of unnecessary code. > > Because it is much faster. The motivation for netmap-like solutions (that includes Intel's DPDK, PF_RING/DNA and several proprietary implementations) is speed: they bypass the entire network stack, and a good part of the device drivers, so you can access packets 10+ times faster. So things are actually the other way around: the 1000's of unnecessary lines of code (not really thousands, though) are those that you'd pay going through the standard network stack when you don't need any of its services. Going to userspace is just a side effect -- turns out to be easier to develop and run your packet processing code in userspace, but there are netmap clients (e.g. the VALE software switch) which run entirely in the kernel. cheers luigi > > > On Sunday, May 3, 2015 3:10 AM, Raimundo Santos > wrote: > > > 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. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------