Date: Tue, 26 May 2015 18:52:08 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: rank1seeker@gmail.com Cc: hackers@freebsd.org Subject: Re: dumpfs incorrectly displays ufsid Message-ID: <alpine.BSF.2.20.1505261848410.12925@mail.fig.ol.no> In-Reply-To: <20150526182656.000000bd@gmail.com> References: <20150526123126.00003bab@gmail.com> <alpine.BSF.2.20.1505261307580.12925@mail.fig.ol.no> <20150526182656.000000bd@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 May 2015 18:26+0200, rank1seeker@gmail.com wrote: > On Tue, 26 May 2015 13:09:53 +0200 (CEST) > Trond Endrestøl <Trond.Endrestol@fagskolen.gjovik.no> wrote: > > > On Tue, 26 May 2015 12:31+0200, rank1seeker@gmail.com wrote: > > > > > I've reported this at REL 8.2, long ago at May 2011 > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156908 > > > > > > Now at 10.1-RELEASE-p10 #0 r282952 i386 > > > > > > This happens, ONLY when first chars are 0 (zeros) in second pair of > > > 8 chars, in which case dumpfs, ommits them. > > > I.e; For: > > > /dev/ufsid/3b9aca0000000001 > > > > > > # dumpfs ada0s1h | head -2 > > > magic 19540119 (UFS2) time Sun Sep 9 03:46:40 2001 > > > superblock location 65536 id [ 3b9aca00 1 ] > > > > > > Problem is in '[ 3b9aca00 1 ]' > > > > If you apply this patch, then the case for UFS2 is treated similar to > > the case for UFS1: > > > > Index: sbin/dumpfs/dumpfs.c > > =================================================================== > > --- sbin/dumpfs/dumpfs.c (revision 283516) > > +++ sbin/dumpfs/dumpfs.c (working copy) > > @@ -165,7 +165,7 @@ > > fstime = afs.fs_time; > > printf("magic\t%x (UFS2)\ttime\t%s", > > afs.fs_magic, ctime(&fstime)); > > - printf("superblock location\t%jd\tid\t[ %x %x ]\n", > > + printf("superblock location\t%jd\tid\t[ %08x %08x > > ]\n", (intmax_t)afs.fs_sblockloc, afs.fs_id[0], afs.fs_id[1]); > > printf("ncg\t%d\tsize\t%jd\tblocks\t%jd\n", > > afs.fs_ncg, (intmax_t)fssize, > > (intmax_t)afs.fs_dsize); > > > > Applied patch ... > > rm -f dumpfs dumpfs.o dumpfs.8.gz dumpfs.8.cat.gz > /usr/obj/usr/src/sbin/dumpfs created for /usr/src/sbin/dumpfs > rm -f .depend > mkdep -f .depend -a -std=gnu99 /usr/src/sbin/dumpfs/dumpfs.c > echo dumpfs: /usr/lib/libc.a /usr/lib/libufs.a >> .depend > cc -O2 -pipe -march=prescott -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /usr/src/sbin/dumpfs/dumpfs.c > cc -O2 -pipe -march=prescott -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -o dumpfs dumpfs.o -lufs > gzip -cn /usr/src/sbin/dumpfs/dumpfs.8 > dumpfs.8.gz > install -s -o root -g wheel -m 555 dumpfs /sbin/dumpfs > install -o root -g wheel -m 444 dumpfs.8.gz /usr/share/man/man8 > rm -f dumpfs dumpfs.o dumpfs.8.gz dumpfs.8.cat.gz > > > And ... > # dumpfs ada0s1h | head -2 > magic 19540119 (UFS2) time Sun Sep 9 03:46:40 2001 > superblock location 65536 id [ 3b9aca00 00000001 ] > > > Ok, it works! > Could you now commit it ASAP? I'm glad to see the patch works. Sorry, I don't have committer's priviledge, nor would I undertake such a commitment (hah, wordplay). But I could add my patch to your PR, and hopefully someone will pick it up. > Thanks. > > > Domagoj Smol?i? > > -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-hackers@FreeBSD.ORG Tue May 26 21:58:39 2015 Return-Path: <owner-freebsd-hackers@FreeBSD.ORG> Delivered-To: freebsd-hackers@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 3438585A; Tue, 26 May 2015 21:58:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 EF2A783A; Tue, 26 May 2015 21:58:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcau1 with SMTP id au1so24747igc.1; Tue, 26 May 2015 14:58:38 -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:content-transfer-encoding; bh=O1JCFCOfun1InhigWx0spqSnjb2Izh2uMT/dH0LLj2g=; b=XONY0YUAZGrqkx2DXHBoxjDv+kYLd7a1CzgPDi1g6AThp4zddMPX/H3OhCqdrtslTl N9w88C8TNwAnZxPLflIUG5UkNEj0hvCUJ7dLKR9ZwrtwY7+wx9Iq2jGoFAA+Ut2w7xX8 eGLuUuSjweSfEgKCuIqxmcb3Lnf92kgCRp5cjEReJR3seoL54dHlXLu1DWKVau+5WdAK KltjrxZqF2g7xdZnYR88ydbn4LqA5qy4GonOY+75DjQlqWqgPSuNY7TM9O2lxtBziufc ZGOAnFpBSonm2kBUU5UpO6s3YiICRpwZv7H2tBPIsBU1jAfrvyWVaiyh8B5grAqK74TH UYuw== MIME-Version: 1.0 X-Received: by 10.107.155.81 with SMTP id d78mr37787128ioe.29.1432677518268; Tue, 26 May 2015 14:58:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Tue, 26 May 2015 14:58:38 -0700 (PDT) In-Reply-To: <5564b545.0287440a.5871.7050@mx.google.com> References: <D1810169.136A5C%rpokala@panasas.com> <5564b545.0287440a.5871.7050@mx.google.com> Date: Tue, 26 May 2015 14:58:38 -0700 X-Google-Sender-Auth: _-7uPVPEeehmQChtfdNpOKupnPI Message-ID: <CAJ-VmomvkxxyG7RZj+Lg-DxciDaF4dWRTZk_5Naaehg6bWuV8w@mail.gmail.com> Subject: Re: Performance issues with Intel Fortville (XL710/ixl(4)) From: Adrian Chadd <adrian@freebsd.org> To: Lakshmi Narasimhan Sundararajan <lakshmi.n@msystechnologies.com> Cc: "Pokala, Ravi" <rpokala@panasas.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, "jfv@freebsd.org" <jfv@freebsd.org>, "erj@freebsd.org" <erj@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "Lewis, Fred" <flewis@panasas.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD <freebsd-hackers.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>; List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 26 May 2015 21:58:39 -0000 hi! Try enabling RSS and PCBGROUPS on -HEAD. The ixl driver should work. (I haven't tested it though; I've had other things going on here.) -adrian On 21 May 2015 at 15:20, Lakshmi Narasimhan Sundararajan <lakshmi.n@msystechnologies.com> wrote: > Hi FreeBSD Team! > > We seem to have found a problem to Tx performance. > > We found that the tx handling is spread on all CPUs causing probably cach= e trashing resulting in poor performance. > > But once we used cpuset to bind interrupt thread and iperf process to the= same CPU, performance was close to line rate. I used userland cpuset comma= nd to perform this manually. I want this constrained in the kernel config/c= ode through some tunables, and I am seeking your help/pointers in that rega= rd. > > > My followup questions are as follows. > > a) How are Tx interrupts steered from the NIC to the CPU on the transmit = path? Would tx_complete# interrupt for packets transmitted from CPU#x, be s= erviced on the same CPU? If not, how to get this binding done? > > > b) I would like to use a pool of CPUs dedicated to service NIC interrupts= . Especially on the transmit path, I would want the tx_interrupts to be han= dled on the same CPU on which request was submitted. How to get this done? > > > I played with the current ISR setting but I did not see any difference in= how Interrupts are scheduled across CPU. The max interrupt threads even th= ough set to one, the interrupt threads are scheduled on any CPU. Even if I = set bindthreads to =E2=80=981=E2=80=99. There is no difference in interrupt= thread scheduling. > > > root@mau-da-27-4-1:~ # sysctl net.isr > net.isr.dispatch: direct > net.isr.maxthreads: 1 > net.isr.bindthreads: 0 > net.isr.maxqlimit: 10240 > net.isr.defaultqlimit: 256 > net.isr.maxprot: 16 > net.isr.numthreads: 1 > > > I would sincerely appreciate if you can provide some pointers on these it= ems above. > > > > > Thanks > > LN > > > > > > > > From: Pokala, Ravi > Sent: =E2=80=8EWednesday=E2=80=8E, =E2=80=8EMay=E2=80=8E =E2=80=8E20=E2= =80=8E, =E2=80=8E2015 =E2=80=8E3=E2=80=8E:=E2=80=8E34=E2=80=8E =E2=80=8EAM > To: freebsd-net@freebsd.org, jfv@freebsd.org, erj@freebsd.org > Cc: freebsd-hackers@freebsd.org, Lewis, Fred, Sundararajan, Lakshmi > > > > > > Hi folks, > > At Panasas, we are working with the Intel XL710 40G NIC (aka Fortville), > and we're seeing some performance issues w/ 11-CURRENT (r282653). > > Motherboard: Intel S2600KP (aka Kennedy Pass) > CPU: E5-2660 v3 @ 2.6GHz (aka Haswell Xeon) > (1 socket x 10 physical cores x 2 SMT threads) =3D 20 logical cor= es > NIC: Intel XL710, 2x40Gbps QSFP, configured in 4x10Gbps mode > RAM: 4x 16GB DDR4 DIMMs > > What we've seen so far: > > - TX performance is pretty consistently lower than RX performance. All > numbers below are for unidrectional tests using `iperf': > 10Gbps links threads/link TX Gbps RX Gbps TX/RX > 1 1 9.02 9.85 91.57% > 1 8 8.49 9.91 85.67% > 1 16 7.00 9.91 70.63% > 1 32 6.68 9.92 67.40% > > - With multiple active links, both TX and RX performance suffer greatly= ; > the aggregate bandwidth tops out at about a third of the theoretical > 40Gbps implied by 4x 10Gbps. > 10Gbps links threads/link TX Gbps RX Gbps % of 40Gb= ps > 4 1 13.39 13.38 33.4% > > - Multi-link bidirectional throughput is absolutely terrible; the > aggregate is less than a tenth of the theoretical 40Gbps. > 10Gbps links threads/link TX Gbps RX Gbps % of 40Gb= ps > 4 1 3.83 2.96 9.6% / 7.= 4% > > - Occasional interrupt storm messages are seen from the IRQs associated > with the NICs. Since that can impact performance, those runs were not > included in the data listed above. > > Our questions: > > - How stable is ixl(4) in -CURRENT? By that, we mean both how quickly i= s > the driver changing, and does the driver cause any system instability? > > - What type of performance have others been getting w/ Fortville? In > 40Gbps mode? In 4x10Gbps mode? > > - Does anyone have any tuning parameters they can recommend for this > card? > > - We did our testing w/ 11-CURRENT, but we will initially ship Fortvill= e > running on 10.1-RELEASE or 10.2-RELEASE. The presence of RSS - even thoug= h > it is disabled by default - makes the driver back-port non-trivial. Is > there an estimate on when the 11-CURRENT version of the driver (1.4.1) > will get MFCed to 10-STABLE? > > My colleagues Lakshmi and Fred (CCed) are working on this; please make > sure to include them if you have any comments. > > Thanks, > > Ravi > _______________________________________________ > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1505261848410.12925>