src-test2/sys/dev/mxge, branch release/11.3.0

Revert r330897:

2018-03-29T02:50:57Z

This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code. Revert with prejudice. This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes. Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes. Requested by: gjb (re)

Partial merge of the SPDX changes

2018-03-14T03:19:51Z

These changes are incomplete but are making it difficult to determine what other changes can/should be merged. No objections from: pfg

MFC r329295:

2018-02-22T19:39:44Z

Panasas discovered that ioctl(SIOCGLAGGPORT) returns ENOTTY for mxge(4) when the NIC is not a member of a lagg. This came as a surprise, because the SIOCGLAGGPORT handler in if_lagg.c only returns ENOENT (if run against the laggX interface, rather than a physical port) or EINVAL (if run against a non-member physical port). This behavior was not seen with other drivers, such as bge(4), igb(4), and cxl(4). When I compared their respective ioctl handlers, I found that they all called ether_ioctl() for the default (i.e. unhandled) case; by contrast, mxge(4) only calls ether_ioctl() for two specific cases, and returns ENOTTY for the default case. Remove the two cases which explicitly call ether_ioctl(), and let the default case call it instead. This matches what the vast majority of the NIC drivers do.

mxge: Setup mbuf flowid before calling tcp_lro_rx().

2016-05-12T03:36:49Z

Reviewed by: gallatin MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D6320

sys/dev: use our nitems() macro when it is avaliable through param.h.

2016-04-19T23:37:24Z

No functional change, only trivial cases are done in this sweep, Drivers that can get further enhancements will be done independently. Discussed in: freebsd-current

tcp/lro: Use tcp_lro_flush_all in device drivers to avoid code duplication

2016-04-01T06:28:33Z

And factor out tcp_lro_rx_done, which deduplicates the same logic with netinet/tcp_lro.c Reviewed by: gallatin (1st version), hps, zbb, np, Dexuan Cui Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D5725

Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.

2016-03-18T01:28:41Z

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

Replace several bus_alloc_resource() calls using default arguments with bus_alloc_resource_any()

2016-02-19T03:37:56Z

Since these calls only use default arguments, bus_alloc_resource_any() is the right call. Differential Revision: https://reviews.freebsd.org/D5306

Add optimizing LRO wrapper:

2016-01-19T15:33:28Z

- Add optimizing LRO wrapper which pre-sorts all incoming packets according to the hash type and flowid. This prevents exhaustion of the LRO entries due to too many connections at the same time. Testing using a larger number of higher bandwidth TCP connections showed that the incoming ACK packet aggregation rate increased from ~1.3:1 to almost 3:1. Another test showed that for a number of TCP connections greater than 16 per hardware receive ring, where 8 TCP connections was the LRO active entry limit, there was a significant improvement in throughput due to being able to fully aggregate more than 8 TCP stream. For very few very high bandwidth TCP streams, the optimizing LRO wrapper will add CPU usage instead of reducing CPU usage. This is expected. Network drivers which want to use the optimizing LRO wrapper needs to call "tcp_lro_queue_mbuf()" instead of "tcp_lro_rx()" and "tcp_lro_flush_all()" instead of "tcp_lro_flush()". Further the LRO control structure must be initialized using "tcp_lro_init_args()" passing a non-zero number into the "lro_mbufs" argument. - Make LRO statistics 64-bit. Previously 32-bit integers were used for statistics which can be prone to wrap-around. Fix this while at it and update all SYSCTL's which expose LRO statistics. - Ensure all data is freed when destroying a LRO control structures, especially leftover LRO entries. - Reduce number of memory allocations needed when setting up a LRO control structure by precomputing the total amount of memory needed. - Add own memory allocation counter for LRO. - Bump the FreeBSD version to force recompilation of all KLDs due to change of the LRO control structure size. Sponsored by: Mellanox Technologies Reviewed by: gallatin, sbruno, rrs, gnn, transport Tested by: Netflix Differential Revision: https://reviews.freebsd.org/D4914

Move zlib.c from net to libkern.

2015-04-22T14:38:58Z

It is not network-specific code and would be better as part of libkern instead. Move zlib.h and zutil.h from net/ to sys/ Update includes to use sys/zlib.h and sys/zutil.h instead of net/ Submitted by: Steve Kiernan stevek@juniper.net Obtained from: Juniper Networks, Inc. GitHub Pull Request: https://github.com/freebsd/freebsd/pull/28 Relnotes: yes