From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 00:22:46 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EEEA106564A for ; Sat, 17 Mar 2012 00:22:46 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 17C8D8FC0C for ; Sat, 17 Mar 2012 00:22:45 +0000 (UTC) Received: by wern13 with SMTP id n13so5791022wer.13 for ; Fri, 16 Mar 2012 17:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wtwEOr8qOA8q1l1xKolvLG8hSY1bUdilwp+NeCWRDCc=; b=cogZF8W2S/KzGi+Wg+gbPTNBVMOAd2Rh+ACi7hV4dxqgTDCSIP5SWEpc3+G0K9RKga J1kS10GxLdB2PnGxDqYTaOcm8U6t7iWOaZenCexoyhl70J/BcKkHuK8z76xLpIw7Wc0O tkh1TgEoFFewUgAtv4Jn2ilM/areqIusLEWL+zBdACVIxJL3flSd/EE3v4Z/EA0Uh2df N4bVn3rUesJToAeVDBQVn5hm0vIAc2mQzghYhTynYwzZ+5kvaLfZugSNeTXnwaQw0+Ld YbLCN843hjKYUXrFyvjGVFO36Y2t2+gSmRPt+HdBOBrVMmzaL8J+7WFy3+9ek5c2bDJt qZvQ== MIME-Version: 1.0 Received: by 10.216.133.234 with SMTP id q84mr2633206wei.102.1331943765186; Fri, 16 Mar 2012 17:22:45 -0700 (PDT) Received: by 10.180.102.6 with HTTP; Fri, 16 Mar 2012 17:22:45 -0700 (PDT) In-Reply-To: <20120316231337.GA62350@onelab2.iet.unipi.it> References: <20120316231337.GA62350@onelab2.iet.unipi.it> Date: Fri, 16 Mar 2012 20:22:45 -0400 Message-ID: From: grarpamp To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: netmap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 00:22:46 -0000 > yes this is the long term plan (actually, kind of works now too > if the netmap-attached client then passes the packets to the host > stack). I would not know how to do that as a common user. Maybe like divert/natd socket in ipfw. But perhaps natd is the only example of user tool in base for that kind of thing right now. > The tricky question is who select which (incoming) traffic needs > to go to the host, and which one should be filtered out. I have > some ideas but need to figure out what is the best way to go. I guess it would need to have all the usual interface semantics... MAC, multicast, promiscuous, alias, vlan, jumbo, v4/v6, checksum, routing, bpf, statistics. I doubt userland interface for all those to the kernel exists yet, and some are only accessible by the code nearest the iron. Maybe better to let the full emulator be kernel space. And it seems there is some additional configuration, or loss of service risk, if the emulator is userland and that account gets compromised. If that is what you meant by 'who'. If the user wanted to then run divert/natd, raw, quagga, and other processing for read/write, they could as normal, just with net0 interface. Anyways, I don't know much. > the em family is already supported. For the 100Mbit ports there > is really no point, as CPUs are fast enough already. Of course, it would just be a consistency thing, /dev/netmap ed0 :) And much boring work when 1000Mbit parts is cheap standard to use now.