From owner-svn-src-all@FreeBSD.ORG Wed Feb 29 10:01:51 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C47FC106564A; Wed, 29 Feb 2012 10:01:51 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6FAAD8FC12; Wed, 29 Feb 2012 10:01:51 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1S2gMO-000BTS-Pj; Wed, 29 Feb 2012 14:02:12 +0400 Date: Wed, 29 Feb 2012 14:02:12 +0400 From: Slawa Olhovchenkov To: Luigi Rizzo Message-ID: <20120229100212.GE97848@zxy.spb.ru> References: <201202271905.q1RJ52Se032771@svn.freebsd.org> <20120228073122.GC57270@onelab2.iet.unipi.it> <20120228203523.GB97848@zxy.spb.ru> <20120228215856.GA99692@onelab2.iet.unipi.it> <20120229091433.GC97848@zxy.spb.ru> <20120229095126.GA6942@onelab2.iet.unipi.it> <20120229094603.GD97848@zxy.spb.ru> <20120229100825.GA7148@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120229100825.GA7148@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: svn-src-head@freebsd.org, Luigi Rizzo , src-committers@freebsd.org, svn-src-all@freebsd.org, Ben Kaduk Subject: Re: svn commit: r232238 - in head: share/man/man4 sys/dev/e1000 sys/dev/ixgbe sys/dev/netmap sys/dev/re sys/net tools/tools/netmap X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 10:01:52 -0000 On Wed, Feb 29, 2012 at 11:08:25AM +0100, Luigi Rizzo wrote: > On Wed, Feb 29, 2012 at 01:46:03PM +0400, Slawa Olhovchenkov wrote: > > On Wed, Feb 29, 2012 at 10:51:26AM +0100, Luigi Rizzo wrote: > > > > > On Wed, Feb 29, 2012 at 01:14:33PM +0400, Slawa Olhovchenkov wrote: > > > > On Tue, Feb 28, 2012 at 10:58:56PM +0100, Luigi Rizzo wrote: > > > > > > > > > On Wed, Feb 29, 2012 at 12:35:23AM +0400, Slawa Olhovchenkov wrote: > > > > > ... > > > > > > > > > ?3. The two changes above unfortunately require an API change, so while > > > > > > > > > ? ? at it add a version field and some spares to the ioctl() argument > > > > > > > > > ? ? to help detect mismatches. > > > > > > > > > > > > > > > > Is it worth bumping __FreeBSD_version? > > > > > > > > > > > > > > I don't think it is necessary. > > > > > > > There is basically no code that uses the netmap API except for > > > > > > > the examples in tools/tools/netmap, and i now have a NETMAP_API macro > > > > > > > > > > > > no code in *FreeBSD base system*, yes? > > > > > > because I am write tools uses the netmap API now. > > > > > > > > > > i am glad to hear that, and the NETMAP_API will serve you well > > > > > because you can use the same also on the Linux version of netmap > > > > > > > > Can you explain some detail about netmap? > > > > > > > > 1. What is order of send packets from different rings? > > > > 2. What is time packets sent? I am need sustain desired value of > > > > transfer rate. > > > > > > Same as with the standard API: > > > > > > 1. it is the hardware that decides that. You can make no assumptions. > > > 2. once again, once you have issued the system call, > > > it is the hardware that decides when it will send packets out. > > > > Realy? I don't do any system call now and see transmited packets > > (in dev.ix.0.mac_stats.tx_frames_XXX stats). > > you MUST issue system calls (ioctl() or poll()) ) to have packets > sent out. Please re-read the manpage. Ah, pool(). I am don't clean understand this, please write some more in manpage. > > 3. Jumbo frames support only throw tunable hw.netmap.buf_size? > > yes but in practice forget jumbo frames. There is no guarantees > that the code works for buf_size > 4096 . > > Unless you want to use them to support NFS and 8K filesystem blocks > (in which case there is a point - you have no fragmentation), > jumbo frames are only useful with low-performance drivers. > With netmap you have no such an issue. This is (suuport jumbo frames) not for performance, but for compatibility and simplify application: one way for generation/capturing small and jumbo packets.