FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F10.0.0 2013-11-16T00:31:32Z 2013-11-16T00:31:32Z Eric Davis edavis@FreeBSD.org 2013-11-16T00:31:32Z urn:sha1:77032326c5717aca6814205af5837cff9d9f406d Approved by: re@ (delphij) Approved by: davidch (mentor) 2013-10-11T20:38:04Z Dimitry Andric dim@FreeBSD.org 2013-10-11T20:38:04Z urn:sha1:0dc23f139a7aef5ab74efbc3faa6b339ab693411 gcc warnings for PAE kernels. Approved by: re (glebius) Reviewed by: davidch, edavis 2013-10-11T17:34:20Z Eric Davis edavis@FreeBSD.org 2013-10-11T17:34:20Z urn:sha1:66fc6b584553d653d8acf200af26df737fc65b2f Approved by: re@ (gjb) Approved by: davidch (mentor) 2013-09-20T20:18:49Z David Christensen davidch@FreeBSD.org 2013-09-20T20:18:49Z urn:sha1:4e4007688cf99b61408f5b604ccda2aa025cd59a BCM578XX controllers. Approved by: re MFC after: 4 weeks 2013-08-19T10:20:20Z Andre Oppermann andre@FreeBSD.org 2013-08-19T10:20:20Z urn:sha1:9d1c4ca773b4003fda9cf7cb5a94147c163982bd from bce(4), bxe(4), mge(4) and ti(4) drivers. 2013-02-07T15:20:54Z Randall Stewart rrs@FreeBSD.org 2013-02-07T15:20:54Z urn:sha1:ded5ea6a257d26cf323d9237eab59c78c13fdd1a 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 2012-12-04T09:32:43Z Gleb Smirnoff glebius@FreeBSD.org 2012-12-04T09:32:43Z urn:sha1:c6499eccad497913a5025fbde8ae76da70e08043 malloc(9) flags in sys/dev. 2012-11-27T19:31:49Z Andre Oppermann andre@FreeBSD.org 2012-11-27T19:31:49Z urn:sha1:da2299c5c7a8f2b66df3d7cc9b927b3c30c78c76 Checksumming the IP header of fragments is no different from doing normal IP headers. Discussed with: yongari MFC after: 1 week 2012-10-18T09:59:50Z Gleb Smirnoff glebius@FreeBSD.org 2012-10-18T09:59:50Z urn:sha1:470797ab8e747fca84a56ff9e65a9dd76612a692 2012-09-28T18:28:27Z Gleb Smirnoff glebius@FreeBSD.org 2012-09-28T18:28:27Z urn:sha1:063efed28c45a81e9f92c69b2fbe1f4f278c8f1a 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