FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F12.3.0 2018-10-25T17:00:39Z 2018-10-25T17:00:39Z Brooks Davis brooks@FreeBSD.org 2018-10-25T17:00:39Z urn:sha1:68742e0d2ef18dd78daafdb37dcf8184b601b3f0 Deprecate a number of less used 10 and 10/100 Ethernet devices. The current deprecated list is: ae, bm, cs, de, dme, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe The list was defined as part of FCP-0101. Per the FCP, devices may be removed from the deprecation list if enough users are found or they are converted to iflib. FCP: https://github.com/freebsd/fcp/blob/master/fcp-0101.md Approved by: re (gjb) Reviewed by: rgrimes Differential Revision: https://reviews.freebsd.org/D17654 2018-05-18T20:13:34Z Matt Macy mmacy@FreeBSD.org 2018-05-18T20:13:34Z urn:sha1:d7c5a620e2b99e914f1770abde956cf0d0a970b7 Run on LLNW canaries and tested by pho@ gallatin: Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5 based ConnectX 4-LX NIC, I see an almost 12% improvement in received packet rate, and a larger improvement in bytes delivered all the way to userspace. When the host receiving 64 streams of netperf -H $DUT -t UDP_STREAM -- -m 1, I see, using nstat -I mce0 1 before the patch: InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree 4.98 0.00 4.42 0.00 4235592 33 83.80 4720653 2149771 1235 247.32 4.73 0.00 4.20 0.00 4025260 33 82.99 4724900 2139833 1204 247.32 4.72 0.00 4.20 0.00 4035252 33 82.14 4719162 2132023 1264 247.32 4.71 0.00 4.21 0.00 4073206 33 83.68 4744973 2123317 1347 247.32 4.72 0.00 4.21 0.00 4061118 33 80.82 4713615 2188091 1490 247.32 4.72 0.00 4.21 0.00 4051675 33 85.29 4727399 2109011 1205 247.32 4.73 0.00 4.21 0.00 4039056 33 84.65 4724735 2102603 1053 247.32 After the patch InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree 5.43 0.00 4.20 0.00 3313143 33 84.96 5434214 1900162 2656 245.51 5.43 0.00 4.20 0.00 3308527 33 85.24 5439695 1809382 2521 245.51 5.42 0.00 4.19 0.00 3316778 33 87.54 5416028 1805835 2256 245.51 5.42 0.00 4.19 0.00 3317673 33 90.44 5426044 1763056 2332 245.51 5.42 0.00 4.19 0.00 3314839 33 88.11 5435732 1792218 2499 245.52 5.44 0.00 4.19 0.00 3293228 33 91.84 5426301 1668597 2121 245.52 Similarly, netperf reports 230Mb/s before the patch, and 270Mb/s after the patch Reviewed by: gallatin Sponsored by: Limelight Networks Differential Revision: https://reviews.freebsd.org/D15366 2017-11-27T14:52:40Z Pedro F. Giffuni pfg@FreeBSD.org 2017-11-27T14:52:40Z urn:sha1:718cf2ccb9956613756ab15d7a0e28f2c8e91cab Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. 2016-05-03T03:41:25Z Pedro F. Giffuni pfg@FreeBSD.org 2016-05-03T03:41:25Z urn:sha1:453130d9bfc1c6d68b366dfcb041689d69f81295 Most affect comments, very few have user-visible effects. 2016-03-18T01:28:41Z Justin Hibbits jhibbits@FreeBSD.org 2016-03-18T01:28:41Z urn:sha1:da1b038af9f9551a0b2f33d312b4eede00aa1542 On some architectures, u_long isn't large enough for resource definitions. Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but type `long' is only 32-bit. This extends rman's resources to uintmax_t. With this change, any resource can feasibly be placed anywhere in physical memory (within the constraints of the driver). Why uintmax_t and not something machine dependent, or uint64_t? Though it's possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on 32-bit architectures. 64-bit architectures should have plenty of RAM to absorb the increase on resource sizes if and when this occurs, and the number of resources on memory-constrained systems should be sufficiently small as to not pose a drastic overhead. That being said, uintmax_t was chosen for source clarity. If it's specified as uint64_t, all printf()-like calls would either need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t aren't horrible, but it would also bake into the API for resource_list_print_type() either a hidden assumption that entries get cast to uintmax_t for printing, or these calls would need the PRI*64 macros. Since source code is meant to be read more often than written, I chose the clearest path of simply using uintmax_t. Tested on a PowerPC p5020-based board, which places all device resources in 0xfxxxxxxxx, and has 8GB RAM. Regression tested on qemu-system-i386 Regression tested on qemu-system-mips (malta profile) Tested PAE and devinfo on virtualbox (live CD) Special thanks to bz for his testing on ARM. Reviewed By: bz, jhb (previous) Relnotes: Yes Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D4544 2016-02-27T03:38:01Z Justin Hibbits jhibbits@FreeBSD.org 2016-02-27T03:38:01Z urn:sha1:c47476d7e6801deffc8b3c057d0fbf7d2335a0c2 Most calls to bus_alloc_resource() use "anywhere" as the range, with a given count. Migrate these to use the new bus_alloc_resource_anywhere() API. Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D5370 2016-02-01T17:41:21Z Gleb Smirnoff glebius@FreeBSD.org 2016-02-01T17:41:21Z urn:sha1:8ec07310fa37cb32a6fb0347014913bb825c6e7b via sys/mbuf.h 2015-12-11T05:27:56Z Warner Losh imp@FreeBSD.org 2015-12-11T05:27:56Z urn:sha1:f6cea53f9db2d88883ea7d7cee5fac10e186650b block. Use it in all the PNP drivers to export either the current PNP table. For uart, create a custom table and export it using MODULE_PNP_INFO since it's the only one that matches on function number. Differential Review: https://reviews.freebsd.org/D3461 2015-01-06T12:59:37Z Robert Watson rwatson@FreeBSD.org 2015-01-06T12:59:37Z urn:sha1:2a8c860fe3f3bcfc6ba9206f34d067d998d89c7e socket-buffer implementations, introduce a return value for MCLGET() (and m_cljget() that underlies it) to allow the caller to avoid testing M_EXT itself. Update all callers to use the return value. With this change, very few network device drivers remain aware of M_EXT; the primary exceptions lie in mbuf-chain pretty printers for debugging, and in a few cases, custom mbuf and cluster allocation implementations. NB: This is a difficult-to-test change as it touches many drivers for which I don't have physical devices. Instead we've gone for intensive review, but further post-commit review would definitely be appreciated to spot errors where changes could not easily be made mechanically, but were largely mechanical in nature. Differential Revision: https://reviews.freebsd.org/D1440 Reviewed by: adrian, bz, gnn Sponsored by: EMC / Isilon Storage Division 2014-09-19T03:51:26Z Gleb Smirnoff glebius@FreeBSD.org 2014-09-19T03:51:26Z urn:sha1:c8dfaf382fa6df9dc6fd1e1c3356e0c8bf607e6a