Commit Graph

16 Commits

Author SHA1 Message Date
Xin LI
1f14e0cb94 Eliminate excessive $FreeBSD$ headers.
Noticed by:	jmallett
2013-03-08 18:08:12 +00:00
Xin LI
cdaba8920e Update driver to version 4.6.95.0.
Submitted by:	"Duvvuru,Venkat Kumar" <VenkatKumar.Duvvuru Emulex.Com>
MFC after:	3 days
2013-03-06 09:53:38 +00:00
Josh Paetzel
beb0f7e7d4 Resolve issue that caused WITNESS to report LORs.
PR:	kern/171838
Submitted by:	Venkat Duvvuru <venkatduvvuru.ml@gmail.com>
MFC after:	2 weeks
2013-02-14 17:34:17 +00:00
Randall Stewart
ded5ea6a25 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
2013-02-07 15:20:54 +00:00
Sofian Brabez
61bfd86762 Use DEVMETHOD_END macro defined in sys/bus.h instead of {0, 0} sentinel on device_method_t arrays
Reviewed by:	cognet
Approved by:	cognet
2013-01-30 18:01:20 +00:00
Gleb Smirnoff
c6499eccad Mechanically substitute flags from historic mbuf allocator with
malloc(9) flags in sys/dev.
2012-12-04 09:32:43 +00:00
Eitan Adler
db702c59cf remove duplicate semicolons where possible.
Approved by:	cperciva
MFC after:	1 week
2012-10-22 03:00:37 +00:00
John Baldwin
6d9190b49c Use if_initbaudrate(). 2012-10-18 15:14:13 +00:00
Gleb Smirnoff
063efed28c 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
2012-09-28 18:28:27 +00:00
John Baldwin
cda6c6abf9 Use pci_find_cap() instead of pci_find_extcap() to locate PCI
find capabilities as the latter API is deprecated for this purpose.

MFC after:	2 weeks
2012-03-03 18:03:50 +00:00
Luigi Rizzo
9bd3250a02 Patches from Naresh Raju Gottumukkala
- Feature: UMC - Universal Multi Channel support
- Bugfix: BE3 Firmware Flashing bug.
- Code improvements:
  - Removed duplicate switch cases in the oce_ioctl routine.
  - Made changes to mcc_async notifications routine(oce_mq_handler)

MFC after:	1 week
2012-02-17 13:55:17 +00:00
John Baldwin
0187124bee Use if_maddr_*lock() routines to lock the per-interface multicast
address list rather than manipulating the lock directly.
2012-02-13 19:35:35 +00:00
Bjoern A. Zeeb
ad5129589c Start to try to hide LRO (and some TSO) bits behind #ifdefs as especially
the symbols are not there when compiling a kernel without IP support and
we do have users doing so.
2012-02-11 08:33:52 +00:00
Bjoern A. Zeeb
84c2fd2f94 Use the more common macro to set the if_baudrate to 10Gbit/s. Just use
UL not ULL, which should make 32bit archs more happy.
2012-02-11 07:47:06 +00:00
Bjoern A. Zeeb
c3ed30eb19 Make use of the read-only variant of the IF_ADDR_*LOCK() macros introduced
in r229614 rather than the compat one.
2012-02-11 07:43:33 +00:00
Luigi Rizzo
2f345d8ed5 Add a driver for Emulex OneConnect ethernet cards (10 Gbit PCIe)
A manpage will come in a future commit.

Submitted by:   Naresh Raju Gottumukkala (emulex)
2012-02-10 21:03:04 +00:00