From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 8 13:55:30 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5FE50D7A; Sun, 8 Sep 2013 13:55:30 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E87E2EF0; Sun, 8 Sep 2013 13:55:30 +0000 (UTC) Received: from [109.44.18.26] (helo=fabiankeil.de) by smtprelay03.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1VIfST-0003l1-OP; Sun, 08 Sep 2013 15:55:21 +0200 Date: Sun, 8 Sep 2013 15:18:07 +0200 From: Fabian Keil To: Alexander Motin Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking Message-ID: <76c368a7.170c2a81@fabiankeil.de> In-Reply-To: <5224511D.4090503@FreeBSD.org> References: <520D4ADB.50209@FreeBSD.org> <5224511D.4090503@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/e+tolWcnwD9WbCgVTVT2xX5"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 13:55:30 -0000 --Sig_/e+tolWcnwD9WbCgVTVT2xX5 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Alexander Motin wrote: > I would like to invite more people to review and test my patches for=20 > improving CAM and GEOM scalability, that for last six months you could=20 > see developing in project/camlock SVN branch. Full diff of that branch=20 > against present head (r255131) can be found here: > http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch So far I haven't noticed any issues with this patch (or later on with camlock_20130906.patch) using glabel, ggatec, geli and ZFS on amd64. cdda2wav continued to work as expected as well. Fabian --Sig_/e+tolWcnwD9WbCgVTVT2xX5 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlIseQ8ACgkQBYqIVf93VJ3T4wCfeiDSZXs0l4Jo8T21G8j24SgE 21kAoJaTVJK37ZTpNjkcqSiTT2R9mXal =D4l8 -----END PGP SIGNATURE----- --Sig_/e+tolWcnwD9WbCgVTVT2xX5-- From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 8 22:04:57 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BF6A235F; Sun, 8 Sep 2013 22:04:57 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7482F23FC; Sun, 8 Sep 2013 22:04:57 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id uz19so5233906obc.7 for ; Sun, 08 Sep 2013 15:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=varJUjxC2+25LZ+AASb6JvS1GpLV8Xw80zP2Wrgl6Fw=; b=r1G9x2zpCrR9fqzs36n2VA2gHrsgDJVqT/oaKdmyOph3b+AtMBJHCtpyeSTjsJ5Qky exFpNBVCBhs3gatJQEvG60Dx7sxzF4nVId3HfbmJLvdPhCb1ZoNE6uz/q+RuXSZZI3Wr IW7TiTsrvCdXRRTlZG2mbt4LRxRZo3pdlUri4Sa91gEHgSFMxR3XZgMCO44eTtX0hfd9 PZV9rYPiUTA+kEH6b5FIqVerm4M/yuGhRnB5tX6U7L186Gp+aGZZHmClMt2XK+g7rofj G5I8VKI7O7j3QFM9TGKwA7DmwICvSvRV8GX/ucYd8WlQ/VnKgJNsbBNf3DQI6qSVP0Lv hYhA== MIME-Version: 1.0 X-Received: by 10.182.237.75 with SMTP id va11mr9457906obc.5.1378677896815; Sun, 08 Sep 2013 15:04:56 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.182.32.101 with HTTP; Sun, 8 Sep 2013 15:04:56 -0700 (PDT) Date: Sun, 8 Sep 2013 23:04:56 +0100 X-Google-Sender-Auth: CfWKWJFYiwx2HsbUWjmVMn5mWyI Message-ID: Subject: Call for FreeBSD 2013Q3 (July-September) Status Reports From: Gabor Pali To: hackers@freebsd.org, current@freebsd.org, FreeBSD developers Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 22:04:57 -0000 Dear FreeBSD Community, Please note that the next submission date for the July to September Quarterly Status Reports is October 7th, 2013, less than a month away. They do not have to be very long -- basically they may be about anything that lets people know what is going on around the FreeBSD Project. Submission of reports is not restricted to committers: Anyone who is doing anything interesting and FreeBSD-related can (and therefore encouraged to) write one! The preferred and easiest submission method is to use the XML generator [1] with the result emailed as an attachment to us, that is, monthly@FreeBSD.org [2]. There is also an XML template [3] which can be filled out manually and attached if preferred. To enable compilation and publication of the Q3 report as soon as possible for the October 7th deadline, please be prompt with any report submissions you may have. We are looking forward to all of your 2013Q3 reports! Cheers, Gabor [1] http://www.freebsd.org/cgi/monthly.cgi [2] mailto:monthly@freebsd.org [3] http://www.freebsd.org/news/status/report-sample.xml From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 13 15:08:25 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E57EE4D9; Fri, 13 Sep 2013 15:08:24 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ADAE52829; Fri, 13 Sep 2013 15:08:24 +0000 (UTC) Received: from [209.249.190.124] (port=63489 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VKUys-0006KF-N7; Fri, 13 Sep 2013 11:08:23 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_C7AE7CBE-E315-44DA-B15B-4A00DFC704F3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Network stack changes From: George Neville-Neil In-Reply-To: Date: Fri, 13 Sep 2013 11:08:27 -0400 Message-Id: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> References: <521E41CB.30700@yandex-team.ru> To: Adrian Chadd X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-Mailman-Approved-At: Fri, 13 Sep 2013 15:36:45 +0000 Cc: "Alexander V. Chernikov" , Luigi Rizzo , Andre Oppermann , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" , "Andrey V. Elsukov" , Gleb Smirnoff , FreeBSD Net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 15:08:25 -0000 --Apple-Mail=_C7AE7CBE-E315-44DA-B15B-4A00DFC704F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 29, 2013, at 7:49 , Adrian Chadd wrote: > Hi, >=20 > There's a lot of good stuff to review here, thanks! >=20 > Yes, the ixgbe RX lock needs to die in a fire. It's kinda pointless to = keep > locking things like that on a per-packet basis. We should be able to = do > this in a cleaner way - we can defer RX into a CPU pinned taskqueue = and > convert the interrupt handler to a fast handler that just schedules = that > taskqueue. We can ignore the ithread entirely here. >=20 > What do you think? >=20 > Totally pie in the sky handwaving at this point: >=20 > * create an array of mbuf pointers for completed mbufs; > * populate the mbuf array; > * pass the array up to ether_demux(). >=20 > For vlan handling, it may end up populating its own list of mbufs to = push > up to ether_demux(). So maybe we should extend the API to have a = bitmap of > packets to actually handle from the array, so we can pass up a larger = array > of mbufs, note which ones are for the destination and then the upcall = can > mark which frames its consumed. >=20 > I specifically wonder how much work/benefit we may see by doing: >=20 > * batching packets into lists so various steps can batch process = things > rather than run to completion; > * batching the processing of a list of frames under a single lock = instance > - eg, if the forwarding code could do the forwarding lookup for 'n' = packets > under a single lock, then pass that list of frames up to = inet_pfil_hook() > to do the work under one lock, etc, etc. >=20 > Here, the processing would look less like "grab lock and process to > completion" and more like "mark and sweep" - ie, we have a list of = frames > that we mark as needing processing and mark as having been processed = at > each layer, so we know where to next dispatch them. >=20 One quick note here. Every time you increase batching you may increase = bandwidth but you will also increase per packet latency for the last packet in a = batch. That is fine so long as we remember that and that this is a tuning knob to balance the two. > I still have some tool coding to do with PMC before I even think about > tinkering with this as I'd like to measure stuff like per-packet = latency as > well as top-level processing overhead (ie, CPU_CLK_UNHALTED.THREAD_P / > lagg0 TX bytes/pkts, RX bytes/pkts, NIC interrupts on that core, etc.) >=20 This would be very useful in identifying the actual hot spots, and would = be helpful to anyone who can generate a decent stream of packets with, say, an = IXIA. Best, George --Apple-Mail=_C7AE7CBE-E315-44DA-B15B-4A00DFC704F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIzKmsACgkQYdh2wUQKM9Lk2QCeLeRhFPb5zHPhQ4hHJ+H/JXWv OR0AoMDJ9iHjwtGg4DblcC0ZSmxt/noE =gAUE -----END PGP SIGNATURE----- --Apple-Mail=_C7AE7CBE-E315-44DA-B15B-4A00DFC704F3-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 13 21:29:53 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C72E29A9 for ; Fri, 13 Sep 2013 21:29:53 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 571F425CA for ; Fri, 13 Sep 2013 21:29:52 +0000 (UTC) Received: from [98.139.214.32] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 13 Sep 2013 21:29:45 -0000 Received: from [98.139.211.193] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 13 Sep 2013 21:29:45 -0000 Received: from [127.0.0.1] by smtp202.mail.bf1.yahoo.com with NNFMP; 13 Sep 2013 21:29:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379107785; bh=Kaf80IlOjl67QGvyrwTU3XSh9I+X0QCirQ67s/Il0xg=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=TMWrpFBbAc2dRR3gSGBZHMKVIrh48naEgyu3iSMuZ/lcnaU6UJZ+R73tyO+lz2K8gXz27WkJB+1/CWdD2hHtmLRnEK+g1mKEZ+3WIpMxKQdFAr28wFJuLnqyV1ATX8RPqvaIQOx7+GoJl8XamLl+ZYffZoekLa+JeYEAPiB1sEc= X-Yahoo-Newman-Id: 648278.46296.bm@smtp202.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MZSdC2gVM1m64uJBkLQnEM7r2nMC13zBV5hDxarJNyjyIjU Lt5TD8bGnyXnvKgbzCHNs9BKyZ2CygZ5GOd1rvfcgET4YuzYK3Luivx1rQQH N9DcJfPgHyeb6DU_n08ROEQ3O5EY0reGpO_D7qQAmn74sHcoB.9BCWWbE1a3 RYouQNqjVfe3j91T0.c8hbGVmowaKkh8Unz_EFzB4V1Gue4uSytWCnWWef49 Ll9FTRijYrXHKNNl9wo.m2KtTY7e0bJniiGKfPrld96fv3PLniivW9kDIgnt BXHo7KzRaYG5gtYUf25k0o98EG_QKC8wHICyBYNAQ7ZVLY4UmQgQQqHYm9P1 H9yzhYS7O7D8Hhx7wTGMG.GrSp8xRcb0UChxW_ls8NEtY.xr8RASfTGT9PTG OcM1toqRnbWOUbcjdr12dMzEtFOHZYEP1JhmRrze0Sg2J3NIvQxHz8TNPqx6 JwiTGssucItQoVnV4kD0gFgbGoiX5cwsJpwViMI6uojrhdhPBrKRtihXg_WQ MS7.ywVkV4fQ3eK0nm7mX0k74T58pf5ufI4Tx6NrsXuKt9LURDCDyTdl4ZiI Ang-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp202.mail.bf1.yahoo.com with SMTP; 13 Sep 2013 14:29:45 -0700 PDT Subject: I am too dumb to understand geom(4) From: Sean Bruno To: "freebsd-hackers@freebsd.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-CEil6ovgBT7irOMMhaiT" Date: Fri, 13 Sep 2013 14:29:44 -0700 Message-ID: <1379107784.2739.31.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 21:29:53 -0000 --=-CEil6ovgBT7irOMMhaiT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How does one make geom_concat(4) load at boot, assume two devices are to be used as a single concatenated device and then create the /dev/ device for it? My MIPS kernconf has: # GEOM modules device geom_map # to get access to the SPI flash partitions device geom_uncompress # compressed in-memory filesystem hackery! device geom_concat #=20 device geom_label #=20 options GEOM_CONCAT # concatenation device support options GEOM_UNCOMPRESS options GEOM_LABEL And yet, I am unable to use gconcat to do anthing useful: # gconcat usage: gconcat help gconcat list [-a] [name ...] gconcat status [-ags] [name ...] gconcat load [-v] gconcat unload [-v] # kldstat -v|grep g_ 43 g_part_mbr 42 g_part_bsd 44 g_uncompress 38 g_map 41 g_part 19 g_md 35 g_concat 37 g_disk 57 g_class 40 g_label 39 g_vfs 36 g_dev --=-CEil6ovgBT7irOMMhaiT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSM4PHAAoJEBkJRdwI6BaHVv0H/jPOmRdDW0CPT3TbAE1/UPRc IiHo0p1Xlse4X9vCklTMBY0OYPNzSGW1YZWTdyfwlEBnVBE2RqrR4topJ+ffG4fI k7S6jo3cDlg7dt365ZO/2hYVTAyguEJfXrE6Ns1sXCEqpukOJxud4e7hvtP7YnGx nK4henp0OkMPQS3rcUMC7NFM2Zyhl8/D8M5YoI/QfDM+GcJumUXYtxig5+h6mYcq ztdWqEehjAqkedHsDkQrvI2/jnJgdTXxzJYz/xt/UIzHZZcbkLypconzi72W79lo IPKgm3wxfh51rG6mcYbvAJ1wNs/IPQbdCZqWj6lUDpM7ExzZ7k1MaT+4xNk1Tn8= =7t7B -----END PGP SIGNATURE----- --=-CEil6ovgBT7irOMMhaiT-- From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 13 22:44:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BA466CF7; Fri, 13 Sep 2013 22:44:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id F0B502CB0; Fri, 13 Sep 2013 22:44:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAMaUM1KDaFve/2dsb2JhbABbhBGDKr1RgTN0giUBAQQBDhVCFBsYAgINGQJZBhOHfQanYJFpgSmOFDQHgmmBNQOpboNAIIFu X-IronPort-AV: E=Sophos;i="4.90,901,1371096000"; d="scan'208";a="51784977" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 13 Sep 2013 18:43:23 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 11462B3F45; Fri, 13 Sep 2013 18:43:23 -0400 (EDT) Date: Fri, 13 Sep 2013 18:43:23 -0400 (EDT) From: Rick Macklem To: George Neville-Neil Message-ID: <221093226.23439826.1379112203059.JavaMail.root@uoguelph.ca> In-Reply-To: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> Subject: Re: Network stack changes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) X-Mailman-Approved-At: Fri, 13 Sep 2013 23:03:34 +0000 Cc: "Alexander V. Chernikov" , Luigi Rizzo , Andre Oppermann , freebsd-hackers@freebsd.org, FreeBSD Net , Adrian Chadd , "Andrey V. Elsukov" , Gleb Smirnoff , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 22:44:58 -0000 George Neville-Neil wrote: > > On Aug 29, 2013, at 7:49 , Adrian Chadd wrote: > > > Hi, > > > > There's a lot of good stuff to review here, thanks! > > > > Yes, the ixgbe RX lock needs to die in a fire. It's kinda pointless > > to keep > > locking things like that on a per-packet basis. We should be able > > to do > > this in a cleaner way - we can defer RX into a CPU pinned taskqueue > > and > > convert the interrupt handler to a fast handler that just schedules > > that > > taskqueue. We can ignore the ithread entirely here. > > > > What do you think? > > > > Totally pie in the sky handwaving at this point: > > > > * create an array of mbuf pointers for completed mbufs; > > * populate the mbuf array; > > * pass the array up to ether_demux(). > > > > For vlan handling, it may end up populating its own list of mbufs > > to push > > up to ether_demux(). So maybe we should extend the API to have a > > bitmap of > > packets to actually handle from the array, so we can pass up a > > larger array > > of mbufs, note which ones are for the destination and then the > > upcall can > > mark which frames its consumed. > > > > I specifically wonder how much work/benefit we may see by doing: > > > > * batching packets into lists so various steps can batch process > > things > > rather than run to completion; > > * batching the processing of a list of frames under a single lock > > instance > > - eg, if the forwarding code could do the forwarding lookup for 'n' > > packets > > under a single lock, then pass that list of frames up to > > inet_pfil_hook() > > to do the work under one lock, etc, etc. > > > > Here, the processing would look less like "grab lock and process to > > completion" and more like "mark and sweep" - ie, we have a list of > > frames > > that we mark as needing processing and mark as having been > > processed at > > each layer, so we know where to next dispatch them. > > > > One quick note here. Every time you increase batching you may > increase bandwidth > but you will also increase per packet latency for the last packet in > a batch. > That is fine so long as we remember that and that this is a tuning > knob > to balance the two. > And any time you increase latency, that will have a negative impact on NFS performance. NFS RPCs are usually small messages (except Write requests and Read replies) and the RTT for these (mostly small, bidirectional) messages can have a significant impact on NFS perf. rick > > I still have some tool coding to do with PMC before I even think > > about > > tinkering with this as I'd like to measure stuff like per-packet > > latency as > > well as top-level processing overhead (ie, > > CPU_CLK_UNHALTED.THREAD_P / > > lagg0 TX bytes/pkts, RX bytes/pkts, NIC interrupts on that core, > > etc.) > > > > This would be very useful in identifying the actual hot spots, and > would be helpful > to anyone who can generate a decent stream of packets with, say, an > IXIA. > > Best, > George > > > From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 13 23:50:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7F75BF5D; Fri, 13 Sep 2013 23:50:56 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE58024DF; Fri, 13 Sep 2013 23:50:55 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id lf11so1477854vcb.35 for ; Fri, 13 Sep 2013 16:50:54 -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 :cc:content-type; bh=v+1K+CJy8FST36tLGRI1CopeWdhZIx7Suv24TJlXZrM=; b=g/b01xY6i+diDvG6LVOFtHGVgdT7+E8zNQUgDXY1AsBTKvepoYfhQ9v0/fH30G3+5q uZyXq/Yp2p4lcKeGcsGTTME0a9BexzNatw/Unmp5HbFbDPsgKvILeN0xrcyUhCb7Y7Mh /aZfU+E8w8MiutITXjHfnmVI1G/i2+iVmKB7pkaOPGl5nxjrJaeAiFWyC66ZuZOPpJTQ msGuo9cwQ9V2gd6iiuld+7+PYWq8dNIinCYlgKgLi3B9e6mvFFmCTVe0NF0j91fYRgRh 2ThzkZb+tm88RJ+GbzxziK6o5SeJM/+jY9FdZmvuRJyIwcezz+6yg9t5vxj9TyN2DkuF 2Srg== MIME-Version: 1.0 X-Received: by 10.58.137.167 with SMTP id qj7mr14239382veb.1.1379116254223; Fri, 13 Sep 2013 16:50:54 -0700 (PDT) Received: by 10.220.96.78 with HTTP; Fri, 13 Sep 2013 16:50:54 -0700 (PDT) In-Reply-To: <221093226.23439826.1379112203059.JavaMail.root@uoguelph.ca> References: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> <221093226.23439826.1379112203059.JavaMail.root@uoguelph.ca> Date: Fri, 13 Sep 2013 19:50:54 -0400 Message-ID: Subject: Re: Network stack changes From: "Sam Fourman Jr." To: Rick Macklem X-Mailman-Approved-At: Sat, 14 Sep 2013 11:18:28 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Alexander V. Chernikov" , Luigi Rizzo , Andre Oppermann , freebsd-hackers@freebsd.org, George Neville-Neil , freebsd-arch@freebsd.org, Adrian Chadd , "Andrey V. Elsukov" , Gleb Smirnoff , FreeBSD Net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 23:50:56 -0000 > > And any time you increase latency, that will have a negative impact on > NFS performance. NFS RPCs are usually small messages (except Write requests > and Read replies) and the RTT for these (mostly small, bidirectional) > messages can have a significant impact on NFS perf. > > rick > > this may be a bit off topic but not much... I have wondered with all of the new tcp algorithms http://freebsdfoundation.blogspot.com/2011/03/summary-of-five-new-tcp-congestion.html what algorithm is best suited for NFS over gigabit Ethernet, say FreeBSD to FreeBSD. and further more would a NFS optimized tcp algorithm be useful? Sam Fourman Jr. From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 14 01:39:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 588CE92D; Sat, 14 Sep 2013 01:39:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8B6B92916; Sat, 14 Sep 2013 01:39:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAP+9M1KDaFve/2dsb2JhbABbgz9Sgyq9U4E1dIIlAQEEASNWBRYYAgINGQJZBgqIBgYMp2aRc4EpjhQ0B4JpgTUDhRWWbY1sg0AggW4 X-IronPort-AV: E=Sophos;i="4.90,902,1371096000"; d="scan'208";a="51799604" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 13 Sep 2013 21:38:50 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 67F6EB404B; Fri, 13 Sep 2013 21:38:50 -0400 (EDT) Date: Fri, 13 Sep 2013 21:38:50 -0400 (EDT) From: Rick Macklem To: "Sam Fourman Jr." Message-ID: <1087948919.23486338.1379122730412.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: Network stack changes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) X-Mailman-Approved-At: Sat, 14 Sep 2013 11:18:56 +0000 Cc: "Alexander V. Chernikov" , Luigi Rizzo , Andre Oppermann , freebsd-hackers@freebsd.org, George Neville-Neil , freebsd-arch@freebsd.org, Adrian Chadd , "Andrey V. Elsukov" , Gleb Smirnoff , FreeBSD Net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 01:39:10 -0000 Sam Fourman Jr. wrote: > > > > > And any time you increase latency, that will have a negative impact > > on > > NFS performance. NFS RPCs are usually small messages (except Write > > requests > > and Read replies) and the RTT for these (mostly small, > > bidirectional) > > messages can have a significant impact on NFS perf. > > > > rick > > > > > this may be a bit off topic but not much... I have wondered with all > of the > new > tcp algorithms > http://freebsdfoundation.blogspot.com/2011/03/summary-of-five-new-tcp-congestion.html > > what algorithm is best suited for NFS over gigabit Ethernet, say > FreeBSD to > FreeBSD. > and further more would a NFS optimized tcp algorithm be useful? > I have no idea what effect they might have. NFS traffic is quite different than streaming or bulk data transfer. I think this might make a nice research project for someone. rick > Sam Fourman Jr. > From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 14 03:20:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C15D375C; Sat, 14 Sep 2013 03:20:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 77D232D5A; Sat, 14 Sep 2013 03:20:10 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id b13so1846169wgh.23 for ; Fri, 13 Sep 2013 20:20:09 -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=IFtRksCRmfL5B1+1wrQ7GTfCJsIIDDCQHX1+tZW4pFQ=; b=gI6Nxi2aoExXobnlohogoRzOt/qT7IXI0S9dphpVrKUea7aD4TIXmx63GGGEDMC1RJ RA27fo4BQDJ0VIiHocD9bvG5E37i8JnwODvAUpXEJn2OAIBJ2JGT6jwZfTwYLig5VAjm J7TZj0nj1NWZi1FqKh2SoMOjG0roERH3UT+4AbsBozTVV0yA36ecQqdvoYj2OkHeN4XN eB7iFW8OKSUD1qX1mVZhJ/ELCZNLJTkM8J5BBS8MQf192G62xmiN8QUTJ8ANiHntSpYH SC1bDAPmy6yBesJBrzoElWyK5AJ9DmzUj9+jkqOACAjjYPgoMyEzracI7lwUC/CdcGkW UZrQ== MIME-Version: 1.0 X-Received: by 10.180.10.136 with SMTP id i8mr4954841wib.46.1379128808906; Fri, 13 Sep 2013 20:20:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Fri, 13 Sep 2013 20:20:08 -0700 (PDT) In-Reply-To: <221093226.23439826.1379112203059.JavaMail.root@uoguelph.ca> References: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> <221093226.23439826.1379112203059.JavaMail.root@uoguelph.ca> Date: Fri, 13 Sep 2013 20:20:08 -0700 X-Google-Sender-Auth: A0kv2cAHQtkyVSyFBvksPLrnLYs Message-ID: Subject: Re: Network stack changes From: Adrian Chadd To: Rick Macklem X-Mailman-Approved-At: Sat, 14 Sep 2013 12:12:29 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Alexander V. Chernikov" , Luigi Rizzo , Andre Oppermann , "freebsd-hackers@freebsd.org" , George Neville-Neil , FreeBSD Net , "Andrey V. Elsukov" , Gleb Smirnoff , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 03:20:11 -0000 On 13 September 2013 15:43, Rick Macklem wrote: > And any time you increase latency, that will have a negative impact on > NFS performance. NFS RPCs are usually small messages (except Write requests > and Read replies) and the RTT for these (mostly small, bidirectional) > messages can have a significant impact on NFS perf. > Hi, the penalties to go to main memory quite a few times each time we process a frame is expensive. If we can get some better behaviour through batching leading to more efficient cache usage, it may not actually _have_ a delay. But, that requires a whole lot of design stars to align. And I'm still knee deep elsewhere, so I haven't really finished getting up to speed with what everyone else has done / said about it.. -adrian From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 14 14:22:44 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC2B03DC; Sat, 14 Sep 2013 14:22:44 +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 64E8129D4; Sat, 14 Sep 2013 14:22:43 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9D36D7300B; Sat, 14 Sep 2013 16:28:02 +0200 (CEST) Date: Sat, 14 Sep 2013 16:28:02 +0200 From: Luigi Rizzo To: George Neville-Neil Subject: Re: Network stack changes Message-ID: <20130914142802.GC71010@onelab2.iet.unipi.it> References: <521E41CB.30700@yandex-team.ru> <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Sat, 14 Sep 2013 19:44:04 +0000 Cc: "Alexander V. Chernikov" , Adrian Chadd , Andre Oppermann , "freebsd-hackers@freebsd.org" , FreeBSD Net , Luigi Rizzo , "Andrey V. Elsukov" , Gleb Smirnoff , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 14:22:44 -0000 On Fri, Sep 13, 2013 at 11:08:27AM -0400, George Neville-Neil wrote: > > On Aug 29, 2013, at 7:49 , Adrian Chadd wrote: ... > > I still have some tool coding to do with PMC before I even think about > > tinkering with this as I'd like to measure stuff like per-packet latency as > > well as top-level processing overhead (ie, CPU_CLK_UNHALTED.THREAD_P / > > lagg0 TX bytes/pkts, RX bytes/pkts, NIC interrupts on that core, etc.) > > > > This would be very useful in identifying the actual hot spots, and would be helpful > to anyone who can generate a decent stream of packets with, say, an IXIA. IXIA ? For the timescales we need to address we don't need an IXIA, a netmap sender is more than enough cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 14 14:29:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 91632418; Sat, 14 Sep 2013 14:29:23 +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 4B73D29EB; Sat, 14 Sep 2013 14:29:23 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 015667300A; Sat, 14 Sep 2013 16:25:26 +0200 (CEST) Date: Sat, 14 Sep 2013 16:25:26 +0200 From: Luigi Rizzo To: George Neville-Neil Subject: Re: Network stack changes Message-ID: <20130914142526.GB71010@onelab2.iet.unipi.it> References: <521E41CB.30700@yandex-team.ru> <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Sat, 14 Sep 2013 19:44:20 +0000 Cc: "Alexander V. Chernikov" , Adrian Chadd , Andre Oppermann , "freebsd-hackers@freebsd.org" , "freebsd-arch@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , Gleb Smirnoff , FreeBSD Net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 14:29:23 -0000 On Fri, Sep 13, 2013 at 11:08:27AM -0400, George Neville-Neil wrote: > > On Aug 29, 2013, at 7:49 , Adrian Chadd wrote: ... > One quick note here. Every time you increase batching you may increase bandwidth > but you will also increase per packet latency for the last packet in a batch. The ones who suffer are the first ones, because their processing is somewhat delayed to 1) let the input batch build up, and 2) complete processing of the batch before pushing results to the next stage. However one should never wait for an input batch to grow; you process whatever your source gives you (one or more packets) by the time you are ready (and if you are slow/overloaded, of course you will get a large backlog at once). Either way, there is no reason to create additional delay on input. cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 14 18:50:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B36D1F45; Sat, 14 Sep 2013 18:50:08 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E08292476; Sat, 14 Sep 2013 18:50:07 +0000 (UTC) Received: by mail-ve0-f177.google.com with SMTP id db12so1900995veb.22 for ; Sat, 14 Sep 2013 11:50:07 -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:from:date:message-id :subject:to:cc:content-type; bh=/cuWua3KDkh6N+MoMwXcUoLKAbOeUwYx5AACQMHPtbc=; b=O1UlmyHnbTj+sgU6LCj9npvH4o6X88SBN3g84lWL/bVNWoLgp0H9Fv/TNJC0W+7M+R nEWGG/cFPTqz/WmR6+4t4pPZiEieyii4a8v3QixD/nIi42yANuRCy+jJjOQtJo77MBk3 tEfzncV5pH6zoBQmWpYQ+/UxZhJC4rcvku6++QPybEZZLnQAuddvfOoo3qFrEy4Bm+vo vLYCyTwqwd3SgENVZFUjENeCEk+AkPjypH4FmcXs6lKeVQTP8vaCE5FXbhI5Ifb1Pwc2 YzCv1t1m+KVkgRWn3MBK0Xcco/y2Evhg0/Fv5StOGd5NkzCH/j0GA858i7AQ9R7DywfI Dn/A== X-Received: by 10.220.13.20 with SMTP id z20mr18354266vcz.0.1379184607005; Sat, 14 Sep 2013 11:50:07 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.221.9 with HTTP; Sat, 14 Sep 2013 11:49:46 -0700 (PDT) In-Reply-To: <20130914142802.GC71010@onelab2.iet.unipi.it> References: <521E41CB.30700@yandex-team.ru> <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> <20130914142802.GC71010@onelab2.iet.unipi.it> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sat, 14 Sep 2013 20:49:46 +0200 X-Google-Sender-Auth: jGoYAycMs8RBkfo6ZVCAv397HvM Message-ID: Subject: Re: Network stack changes To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 14 Sep 2013 19:59:56 +0000 Cc: "Alexander V. Chernikov" , Adrian Chadd , Andre Oppermann , "freebsd-hackers@freebsd.org" , George Neville-Neil , "freebsd-arch@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , Gleb Smirnoff , FreeBSD Net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 18:50:08 -0000 On Sat, Sep 14, 2013 at 4:28 PM, Luigi Rizzo wrote: > > IXIA ? For the timescales we need to address we don't need an IXIA, > a netmap sender is more than enough > The great netmap generates only one IP flow (same src/dst IP and same src/dst port). This don't permit to test multi-queue NIC (or SMP packet-filter) on a simple lab like this: netmap sender => freebsd router => netmap receiver Regards, Olivier From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 14 19:24:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9DA1161C; Sat, 14 Sep 2013 19:24:05 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D8E8725FD; Sat, 14 Sep 2013 19:24:03 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id lv10so1997565lab.37 for ; Sat, 14 Sep 2013 12:24:01 -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=5s/IVe0iDOLPQnHwtjKoQD9xkSMh7tizoAp5hr4lTvI=; b=GS901BZYZ5iM987h7sm7k/dxsSdQ2yBeR78dv6Lge9kVf1trBrPOztm95RxpEIGYFr XecerDCxWGsHvmRYSV8wCiEv9Ts1aWSsBGkK0d+CCqZw4b2RQ7HXz21lRWBK5BMfypkf sobNwbGh6oWQjxLiUEMK8/MZLb46xOlrZ0Mhs96D/aOKuLw17tiODK3RxRQsMPyKQ4Qm qxGT7/KH8CXkuL4SAHq5yhFsSoLIcqw16qNDwayLDIjcRv0XG3b31wdiSEPCv3uIKa1k 1EJH4qLw6aA/XhEsNU1OstWpBQPRQSFmkMDyqmyp9QbzneSzrWjI7A9VmiM08re6nYhG m9FA== MIME-Version: 1.0 X-Received: by 10.112.64.36 with SMTP id l4mr17268604lbs.15.1379186641610; Sat, 14 Sep 2013 12:24:01 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Sat, 14 Sep 2013 12:24:01 -0700 (PDT) In-Reply-To: References: <521E41CB.30700@yandex-team.ru> <6BDA4619-783C-433E-9819-A7EAA0BD3299@neville-neil.com> <20130914142802.GC71010@onelab2.iet.unipi.it> Date: Sat, 14 Sep 2013 21:24:01 +0200 X-Google-Sender-Auth: As4PNyDtyJpFBvlZh6F6Ginwbys Message-ID: Subject: Re: Network stack changes From: Luigi Rizzo To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= X-Mailman-Approved-At: Sat, 14 Sep 2013 20:00:09 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "Alexander V. Chernikov" , Adrian Chadd , Andre Oppermann , "freebsd-hackers@freebsd.org" , George Neville-Neil , "freebsd-arch@freebsd.org" , Luigi Rizzo , "Andrey V. Elsukov" , Gleb Smirnoff , FreeBSD Net , Luigi Rizzo X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Sep 2013 19:24:05 -0000 On Saturday, September 14, 2013, Olivier Cochard-Labb=E9 wrote: > On Sat, Sep 14, 2013 at 4:28 PM, Luigi Rizzo wrote: >> >> IXIA ? For the timescales we need to address we don't need an IXIA, >> a netmap sender is more than enough >> > > The great netmap generates only one IP flow (same src/dst IP and same > src/dst port). True the sample app generates only one flow but it is trivial to modify it to generate multiple flows. My point was, we have the ability to generate high rate traffic, as long as we do tolerate a .1-1us jitter. Beyond that, you do need some ixia-like solution. Cheers Luigi > This don't permit to test multi-queue NIC (or SMP packet-filter) on a > simple lab like this: > netmap sender =3D> freebsd router =3D> netmap receiver > > Regards, > > Olivier > --=20 -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------