src/sys/dev/oce, branch release/10.1.0

MFC r267839:

2014-06-30T16:23:31Z

Apply vendor fixes for big endian support and 20GBps/25GBps link speeds. Many thanks to Emulex for their continued support of FreeBSD! Submitted by: Venkata Duvvuru

MFC r260110:

2014-01-13T19:34:23Z

Eliminate unused drbr_stats_update implementation in oce(4) driver. Noticed by: dim

MFC r258941:

2013-12-06T23:30:46Z

Apply vendor improvements to oce(4) driver: - Add support to 40Gbps devices; - Add support to control adaptive interrupt coalescing (AIC) via sysctl; - Improve support of BE3 devices; Many thanks to Emulex for their continued support of FreeBSD. Submitted by: Venkata Duvvuru Approved by: re (rodrigc)

MFC r257007:

2013-10-26T19:02:39Z

Update driver to version 10.0.664.0. Many thanks to Emulex for their continued support of FreeBSD. Submitted by: Venkata Duvvuru Approved by: re (glebius)

Update driver with recent vendor improvements, most notably support

2013-07-06T08:30:45Z

of Skyhawk adapters. Many thanks to Emulex for their continued support of FreeBSD. Submitted by: "Duvvuru,Venkat Kumar" MFC after: 1 day

Eliminate excessive $FreeBSD$ headers.

2013-03-08T18:08:12Z

Noticed by: jmallett

Update driver to version 4.6.95.0.

2013-03-06T09:53:38Z

Submitted by: "Duvvuru,Venkat Kumar" MFC after: 3 days

Resolve issue that caused WITNESS to report LORs.

2013-02-14T17:34:17Z

PR: kern/171838 Submitted by: Venkat Duvvuru MFC after: 2 weeks

This fixes a out-of-order problem with several

2013-02-07T15:20:54Z

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

Use DEVMETHOD_END macro defined in sys/bus.h instead of {0, 0} sentinel on device_method_t arrays

2013-01-30T18:01:20Z

Reviewed by: cognet Approved by: cognet