From owner-freebsd-net@FreeBSD.ORG Sat Mar 17 07:26:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 649CA1065670 for ; Sat, 17 Mar 2012 07:26:41 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 246B18FC14 for ; Sat, 17 Mar 2012 07:26:40 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1FF5E7300A; Sat, 17 Mar 2012 08:45:20 +0100 (CET) Date: Sat, 17 Mar 2012 08:45:20 +0100 From: Luigi Rizzo To: grarpamp Message-ID: <20120317074520.GB69097@onelab2.iet.unipi.it> References: <20120316231337.GA62350@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org 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 07:26:41 -0000 On Fri, Mar 16, 2012 at 08:22:45PM -0400, grarpamp wrote: > > 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. the "bridge" application in tools/tools/examples does exactly that -- it can pass all packets (bidirectionally) between the host stack and an interface in netmap mode. With little modifications it can decide to look at the packets, keep some for itself, modify them, etc. And the OS still believes the interface is there so playing with addresses, forwarding tables, etc still works as always. To come to the rest of your message: sure it would be great if netmap could at the same time do all what is available in the standard stack _and_ go much faster. But life is typically a tradeoff and this case is no different: at the moment i can only offer the option of run-time switching between the standard stack and netmap mode, where you can do some things much faster but you have a bit of inconvenience with other features (e.g. you cannot do bpf in netmap mode, although netmap itself is a much faster way of doing capture/inject). cheers luigi