Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-23 Thread Olivier Cochard-Labbé 
On Tue, Jan 24, 2017 at 2:40 AM, Sean Bruno  wrote:

>
>
> Which set of configs from your test suite are you using for this?
> Specifically, what packet size are you slamming across?
>
> https://github.com/ocochard/netbenches/tree/master/pktgen.configs
>

​Because I'm in the point of view of a Telco, I'm measuring the «worst»
case, this mean with the smallest frame size.
Here is the exact pkt-gen command line I'm using:
- 60 byte Ethernet frame size (excluding the 4 CRC bytes)
- 2000 UDP flows (20 IP sources * 100 IP destinations)

pkt-gen -U -i igb2 -f tx -n 8000 -l 60 -d
198.19.10.1:2000-198.19.10.20 -D 00:0d:b9:41:ca:3d -s
198.18.10.1:2000-198.18.10.100 -w 4

​Option -U is available on a patched netmap version [1]: It fix the
checksum calculation when using source/destination IP range on NIC that
didn't enable HW CHKSUM in netmap mode and IPv6 support.

[1]
https://github.com/ocochard/BSDRP/blob/master/BSDRPcur/patches/freebsd.pkt-gen.ae-ipv6.patch
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-23 Thread Sean Bruno 


On 01/23/17 08:39, Olivier Cochard-Labbé wrote:
> 
> On Thu, Jan 12, 2017 at 1:54 AM, Matthew Macy  > wrote:
> 
>  >  A flame graph for the core cycle count and a flame graph with
> cache miss stats from pmc would be a great start.
>  >
>  >
>  > ​I didn't know the exact event name to use for cache miss stats,
> but here are the flame graphs for CPU_CLK_UNHALTED_CORE:
>  > http://dev.bsdrp.net/netgate.r311848.CPU_CLK_UNHALTED_CORE.svg
> 
>  > http://dev.bsdrp.net/netgate.r311849.CPU_CLK_UNHALTED_CORE.svg
> 
> 
> Thanks. Having twice as many txqs would definitely help. It's also
> clear that there may be some sort of peformance issue in
> iflib_txq_drain. Although it could just be non-stop cache misses on
> the packet headers.
> 
> 
> ​Any news about the performance issue in iflib_txq_drain ?
> 
> On a different hardware (PC Engine APU2), I've got -20% performance drop:
> 
> x head r311848: packets per second
> + head r311849: packets per second
> +--+
> | ++  x|
> |+++ x xx x|
> | |_A_||
> ||A|   |
> +--+
> N   Min   MaxMedian   AvgStddev
> x   5580021588650585676  585406.1 3550.8673
> +   5463865467599465428  465638.6 1437.9347
> Difference at 95.0% confidence
> -119768 +/- 3950.78
> -20.4589% +/- 0.558328%
> (Student's t, pooled s = 2708.9)
> ​
>  
> ​Because it's an AMD processor I didn't found the pmc equivalent of
> CPU_CLK_UNHALTED_CORE, then I've used BU_CPU_CLK_UNHALTED but I've no
> idea if it's the good one.
> 
> http://dev.bsdrp.net/apu2.r311848.BU_CPU_CLK_UNHALTED.svg
> http://dev.bsdrp.net/apu2.r311849.BU_CPU_CLK_UNHALTED.svg
> ​
> ​Thanks​
> 
> 


Olivier:

Which set of configs from your test suite are you using for this?
Specifically, what packet size are you slamming across?

https://github.com/ocochard/netbenches/tree/master/pktgen.configs

sean



signature.asc
Description: OpenPGP digital signature

Re: command line environment and port to equal CURRENT clang?

2017-01-23 Thread Jeffrey Bouquet 


On Mon, 23 Jan 2017 20:18:18 +0100, Dimitry Andric  wrote:

> On 23 Jan 2017, at 05:32, Jeffrey Bouquet  wrote:
> > 
> > ... that may work in /usr/src/sbin for example?
> > make clang=[/usr/ports/lang/??]clang-foo clang+ depend;   make;   # so that 
> > a buildworld is not needed?
> > or that would have to be created as a feature..
> 
> The following appears to work:
> 
> pkg install llvm39
> export CC=/usr/local/bin/clang39
> export CXX=/usr/local/bin/clang++39
> export CPP=/usr/local/bin/clang-cpp
> cd /usr/src/sbin
> make obj
> make depend
> make
> 
> Note that this may pick up the wrong versions of libraries, so do not
> be amazed if stuff blows up.
> 
> Also note that clang in base has a few patches which might not be in the
> port, so you could also run into unexpected bugs in the port.
> 
> -Dimitry

Works! on 9 out of ten binaries at least. [1] Even so good from here that 
someone
may wish to put it in /usr/src/UPDATING but with an additional reference to how
to find the most likely llvm since that may change over time...

Tested in /usr/src/bin, sbin, usr.sbin, usr.bin...

[1] some build but do not install 'no such file or directory' so maybe did not 
build...

Made it into a .sh or .zsh that placed in another location and then run from the
location that is being reinstalled, /fsck_ffs/ for example... with the latter
as the $1 coded into the script, as the full path on the command line as a
parameter.  May need improvement... or more coding...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Fix /etc/rc.d/random umask handling (/entropy permissions)

2017-01-23 Thread Jilles Tjoelker 
On Mon, Jan 23, 2017 at 10:52:21AM -0800, Simon J. Gerraty wrote:
> Jilles Tjoelker  wrote:
> > Index: etc/rc.d/random
> > ===
> > --- etc/rc.d/random (revision 311446)
> > +++ etc/rc.d/random (working copy)
> > @@ -20,12 +20,14 @@
> >  
> >  save_dev_random()
> >  {
> > +   oumask=`umask`

> why not simply use a sub-shell to tighten umask

> (umask 077; what-ever)

With our /bin/sh, the save-restore method saves a fork. A command
substitution with a single umask command does not fork, while a subshell
containing umask and something else does.

The effect is fairly minor, but good performance is often the product of
many small optimizations.

-- 
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: command line environment and port to equal CURRENT clang?

2017-01-23 Thread Jeffrey Bouquet 


On Mon, 23 Jan 2017 20:18:18 +0100, Dimitry Andric  wrote:

> On 23 Jan 2017, at 05:32, Jeffrey Bouquet  wrote:
> > 
> > ... that may work in /usr/src/sbin for example?
> > make clang=[/usr/ports/lang/??]clang-foo clang+ depend;   make;   # so that 
> > a buildworld is not needed?
> > or that would have to be created as a feature..
> 
> The following appears to work:
> 
> pkg install llvm39
> export CC=/usr/local/bin/clang39
> export CXX=/usr/local/bin/clang++39
> export CPP=/usr/local/bin/clang-cpp
> cd /usr/src/sbin
> make obj
> make depend
> make
> 
> Note that this may pick up the wrong versions of libraries, so do not
> be amazed if stuff blows up.
> 
> Also note that clang in base has a few patches which might not be in the
> port, so you could also run into unexpected bugs in the port.
> 
> -Dimitry


Thanks.
pkg fetch is on the fourth 'timeout' to fetch the file, though, I emailed
the p...@freebsd.org list... wget -c -nd in this case did not help either, 
unless
that is more tricks to learn.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: command line environment and port to equal CURRENT clang?

2017-01-23 Thread Dimitry Andric 
On 23 Jan 2017, at 05:32, Jeffrey Bouquet  wrote:
> 
> ... that may work in /usr/src/sbin for example?
> make clang=[/usr/ports/lang/??]clang-foo clang+ depend;   make;   # so that a 
> buildworld is not needed?
> or that would have to be created as a feature..

The following appears to work:

pkg install llvm39
export CC=/usr/local/bin/clang39
export CXX=/usr/local/bin/clang++39
export CPP=/usr/local/bin/clang-cpp
cd /usr/src/sbin
make obj
make depend
make

Note that this may pick up the wrong versions of libraries, so do not
be amazed if stuff blows up.

Also note that clang in base has a few patches which might not be in the
port, so you could also run into unexpected bugs in the port.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Fix /etc/rc.d/random umask handling (/entropy permissions)

2017-01-23 Thread Simon J. Gerraty 
Jilles Tjoelker  wrote:
> Index: etc/rc.d/random
> ===
> --- etc/rc.d/random   (revision 311446)
> +++ etc/rc.d/random   (working copy)
> @@ -20,12 +20,14 @@
>  
>  save_dev_random()
>  {
> + oumask=`umask`

why not simply use a sub-shell to tighten umask

(umask 077; what-ever)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

libc++ missing in drm-next-4.7 [WAS: libstd++ missing in drm-next-4.7]

2017-01-23 Thread Christian Schwarz 
On Mon, Jan 23, 2017 at 10:36:40AM +, David Chisnall wrote:
> >  clang39 # now run clang, won't work, see below Shared object
> >  "libc++.so.1" not found, required by "clang"
> 
> For clarification, are you missing libc++ or libstdc++?  libstdc++
> hasn’t been a default part of the base system since 10.0 for x86
> architectures.

Please excuse my sloppiness in writing this message.
Of course, I mean libc++, as seen in the clan39 / ld message.

Changed the subject to reflect this.

Thanks,

  Christian

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-23 Thread Olivier Cochard-Labbé 
On Thu, Jan 12, 2017 at 1:54 AM, Matthew Macy  wrote:

>  >  A flame graph for the core cycle count and a flame graph with cache
> miss stats from pmc would be a great start.
>  >
>  >
>  > ​I didn't know the exact event name to use for cache miss stats, but
> here are the flame graphs for CPU_CLK_UNHALTED_CORE:
>  > http://dev.bsdrp.net/netgate.r311848.CPU_CLK_UNHALTED_CORE.svg
>  > http://dev.bsdrp.net/netgate.r311849.CPU_CLK_UNHALTED_CORE.svg
>
> Thanks. Having twice as many txqs would definitely help. It's also clear
> that there may be some sort of peformance issue in iflib_txq_drain.
> Although it could just be non-stop cache misses on the packet headers.
>
>
> ​Any news about the performance issue in iflib_txq_drain ?

On a different hardware (PC Engine APU2), I've got -20% performance drop:

x head r311848: packets per second
+ head r311849: packets per second
+--+
| ++  x|
|+++ x xx x|
| |_A_||
||A|   |
+--+
N   Min   MaxMedian   AvgStddev
x   5580021588650585676  585406.1 3550.8673
+   5463865467599465428  465638.6 1437.9347
Difference at 95.0% confidence
-119768 +/- 3950.78
-20.4589% +/- 0.558328%
(Student's t, pooled s = 2708.9)
​

​Because it's an AMD processor I didn't found the pmc equivalent of
CPU_CLK_UNHALTED_CORE, then I've used BU_CPU_CLK_UNHALTED but I've no idea
if it's the good one.

http://dev.bsdrp.net/apu2.r311848.BU_CPU_CLK_UNHALTED.svg
http://dev.bsdrp.net/apu2.r311849.BU_CPU_CLK_UNHALTED.svg
​
​Thanks​
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT [r308668] autofs kernel panic

2017-01-23 Thread Alex Deiter 
Hello Edward,

Thank you!

Alex Deiter
alex.dei...@gmail.com



> On 23 Jan 2017, at 14:51, Edward Tomasz Napierała  wrote:
> 
> For the record, this was fixed in r311284.
> 
> On 1115T2021, Alex Deiter wrote:
>> Hello Edward,
>> 
>> Thank you for the quick reply!
>> I was able to reproduce this panic on default GENERIC kernel (my test
>> system and laptop):
>> 
>> # kgdb /boot/kernel/kernel /var/crash/vmcore.2
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for details.
>> This GDB was configured as "amd64-marcel-freebsd"...
>> 
>> Unread portion of the kernel message buffer:
>> kernel trap 12 with interrupts disabled
>> 
>> 
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 3; apic id = 06
>> fault virtual address = 0xe0
>> fault code = supervisor read data, page not present
>> instruction pointer = 0x20:0x809fe487
>> stack pointer= 0x28:0xfe085f5d4560
>> frame pointer= 0x28:0xfe085f5d45b0
>> code segment = base 0x0, limit 0xf, type 0x1b
>> = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = resume, IOPL = 0
>> current process = 0 (pkg)
> 
> [..]
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT [r308668] autofs kernel panic

2017-01-23 Thread Edward Tomasz Napierała 
For the record, this was fixed in r311284.

On 1115T2021, Alex Deiter wrote:
> Hello Edward,
> 
> Thank you for the quick reply!
> I was able to reproduce this panic on default GENERIC kernel (my test
> system and laptop):
> 
> # kgdb /boot/kernel/kernel /var/crash/vmcore.2
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> kernel trap 12 with interrupts disabled
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 06
> fault virtual address = 0xe0
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0x809fe487
> stack pointer= 0x28:0xfe085f5d4560
> frame pointer= 0x28:0xfe085f5d45b0
> code segment = base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = resume, IOPL = 0
> current process = 0 (pkg)

[..]

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: libstd++ missing in drm-next-4.7

2017-01-23 Thread David Chisnall 
On 20 Jan 2017, at 14:06, Christian Schwarz  wrote:
> 
> I know clang is no longer built and installed as part of buildworld  in
> the FreeBSDDesktop repo,
> but why isn't libstd++ present?
> 
> …
> 
>  clang39 # now run clang, won't work, see below
>  Shared object "libc++.so.1" not found, required by "clang"

For clarification, are you missing libc++ or libstdc++?  libstdc++ hasn’t been 
a default part of the base system since 10.0 for x86 architectures.

David



smime.p7s
Description: S/MIME cryptographic signature