MFS r267944 (MFC r258941,267839):

Apply vendor improvements to oce(4) driver:

- Add support to 20Gbps, 25Gbps, 40Gbps devices;
- Add support to control adaptive interrupt coalescing (AIC)
via sysctl;
- Improve support of BE3 devices;
- Big endian support fixes;

Many thanks to Emulex for their continued support of FreeBSD.

Submitted by: Venkata Duvvuru <VenkatKumar.Duvvuru Emulex.Com>
Approved by: re (gjb)

Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

MFC r260110:

Eliminate unused drbr_stats_update implementation in oce(4) driver.

Noticed by: dim

MFC r257007,258140:

Update driver to version 10.0.664.0.

Many thanks to Emulex for their continued support of FreeBSD.

Submitted by: Venkata Duvvuru <VenkatKumar.Duvvuru Emulex Com>

MFC r246482 (rrs) + r246581:

This fixes a out-of-order problem with several of the newer
drivers. The basic problem was that the driver was pulling
the mbuf off the drbr ring and then when sending with xmit(),
encounting a full transmit ring. Thus the lower layer xmit()
function would return an error, and the drivers would then
append the data back on to the ring. For TCP this is a
horrible scenario sure to bring on a fast-retransmit.

The fix is to use drbr_peek() to pull the data pointer but
not remove it from the ring. If it fails then we either call
the new drbr_putback or drbr_advance method. Advance moves
it forward (we do this sometimes when the xmit() function
frees the mbuf). When we succeed we always call advance.
The putback will always copy the mbuf back to the top of the
ring. Note that the putback *cannot* be used with a
drbr_dequeue() only with drbr_peek(). We most of the time,
in putback, would not need to copy it back since most likey
the mbuf is still the same, but sometimes xmit() functions
will change the mbuf via a pullup or other call. So the
optimial case for the single consumer is to always copy it
back. If we ever do a multiple_consumer (for lagg?) we
will need a test and atomic in the put back possibly a
seperate putback_mc() in the ring buf.

Reviewed by: jhb@freebsd.org, jlv@freebsd.org

MFC r252869:

Update driver with recent vendor improvements, most notably support
of Skyhawk adapters.

Many thanks to Emulex for their continued support of FreeBSD.

Submitted by: "Duvvuru,Venkat Kumar" <VenkatKumar.Duvvuru Emulex.Com>

MFC: r243857 (partial)

Mechanically substitute flags from historic mbuf allocator with
malloc(9) flags in sys/dev.

MFC r231879,246799,247880,248059:

Update driver to version 4.6.95.0.

Submitted by: "Duvvuru,Venkat Kumar" <VenkatKumar.Duvvuru Emulex.Com>

MFC 246799:

Resolve issue that caused WITNESS to report LORs.

Merge r241037 from head:
The drbr(9) API appeared to be so unclear, that most drivers in
tree used it incorrectly, which lead to inaccurate overrated
if_obytes accounting. The drbr(9) used to update ifnet stats on
drbr_enqueue(), which is not accurate since enqueuing doesn't
imply successful processing by driver. Dequeuing neither mean
that. Most drivers also called drbr_stats_update() which did
accounting again, leading to doubled if_obytes statistics. And
in case of severe transmitting, when a packet could be several
times enqueued and dequeued it could have been accounted several
times.

o Thus, make drbr(9) API thinner. Now drbr(9) merely chooses between
ALTQ queueing or buf_ring(9) queueing.
- It doesn't touch the buf_ring stats any more.
- It doesn't touch ifnet stats anymore.
- drbr_stats_update() no longer exists.

o buf_ring(9) handles its stats itself:
- It handles br_drops itself.
- br_prod_bytes stats are dropped. Rationale: no one ever
reads them but update of a common counter on every packet
negatively affects performance due to excessive cache
invalidation.
- buf_ring_enqueue_bytes() reduced to buf_ring_enqueue(), since
we no longer account bytes.

o Drivers handle their stats theirselves: if_obytes, if_omcasts.

o mlx4(4), igb(4), em(4), vxge(4), oce(4) and ixv(4) no longer
use drbr_stats_update(), and update ifnet stats theirselves.

o bxe(4) was the most correct driver, it didn't call
drbr_stats_update(), thus it was the only driver accurate under
moderate load. Now it also maintains stats itself.

o ixgbe(4) had already taken stats from hardware, so just
- drop software stats updating.
- take multicast packet count from hardware as well.

o mxge(4) just no longer needs NO_SLOW_STATS define.

o cxgb(4), cxgbe(4) need no change, since they obtain stats
from hardware.

Reviewed by: jfv, gnn

MFC r241844:
remove duplicate semicolons where possible.

Approved by: cperciva (implicit)

Toss bogus mergeinfo.

MFC r235634

Fix and update battery status bits according to linux driver

MFC 232470:
Use pci_find_cap() instead of pci_find_extcap() to locate PCI
find capabilities as the latter API is deprecated for this purpose.

MFC: the "oce" driver for Emulex OneConnect 10Gbit Ethernet.
This is the same exact code that you can find in HEAD