#
369531 |
|
30-Mar-2021 |
freqlabs |
Fix array out of bound panic introduced in r306219.
As I see, different NICs in different configurations may have different numbers of TX and RX queues. The code was assuming 1:1 mapping between event queues (interrupts) and TX/RX queues. Since number of interrupts is set to maximum of TX and RX queues, when those two are different, the system is doomed.
I have no documentation or deep knowledge about this hardware, so this change is based on general observations and code reading. If some of my guesses are wrong, please do better. I just confirmed HP NC550SFP NICs are working now.
MFC after: 2 weeks Sponsored by: iXsystems, Inc.
(cherry picked from commit 3582828053556ca0e05ed9aab3e78008a0595e09)
Git Hash: a42a0b77f0de636a91f79fa2fde8a507d88b79b7 Git Author: mav@FreeBSD.org
|
#
362511 |
|
22-Jun-2020 |
freqlabs |
MFC r362201:
Avoid trying to toggle TSO twice
Remove TSO from the toggle mask when automatically disabled by TXCKSUM* in various NIC drivers.
Reviewed by: hselasky, np, gallatin, jpaetzel Approved by: mav (mentor) Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D25120
|
#
356090 |
|
26-Dec-2019 |
markj |
MFC r356047: oce: Disallow the passthrough ioctl for unprivileged users.
|
#
351143 |
|
16-Aug-2019 |
kevans |
MFC r350630, r350657: static analysis fixes from Haiku
r350630: oce(4): potential out of bounds access before vector validation
r350657: ral: rt2860: fix wcid2ni access/size issue
RT2860_WCID_MAX is supposed to describe the max STA index for wcid2ni, and was instead being used as the size -- off-by-one.
rt2860_drain_stats_fifo was range-checking wcid only after accessing out-of-bounds potentially.
|
#
343300 |
|
22-Jan-2019 |
delphij |
MFC r342856: Added support for the SIOCGI2C ioctl.
Submitted by: Ram Kishore Vegesna <ram.vegesna@broadcom.com> Obtained from: Broadcom
|
#
338938 |
|
25-Sep-2018 |
jpaetzel |
MFC r306219:
Update oce to version 11.0.50.0
Submitted by: Venkat Duvvuru <venkatkumar.duvvuru@broadcom.com>
|
#
332288 |
|
08-Apr-2018 |
brooks |
MFC r331797:
Use an accessor function to access ifr_data.
This fixes 32-bit compat (no ioctl command defintions are required as struct ifreq is the same size).
Reviewed by: kib Obtained from: CheriBSD Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D14900
|
#
331722 |
|
29-Mar-2018 |
eadler |
Revert r330897:
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)
|
#
330897 |
|
14-Mar-2018 |
eadler |
Partial merge of the SPDX changes
These changes are incomplete but are making it difficult to determine what other changes can/should be merged.
No objections from: pfg
|
#
302408 |
|
07-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
297482 |
|
01-Apr-2016 |
sephe |
tcp/lro: Use tcp_lro_flush_all in device drivers to avoid code duplication
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 <decui microsoft com> Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D5725
|
#
296272 |
|
01-Mar-2016 |
jhb |
Remove taskqueue_enqueue_fast().
taskqueue_enqueue() was changed to support both fast and non-fast taskqueues 10 years ago in r154167. It has been a compat shim ever since. It's time for the compat shim to go.
Submitted by: Howard Su <howard0su@gmail.com> Reviewed by: sephe Differential Revision: https://reviews.freebsd.org/D5131
|
#
283291 |
|
22-May-2015 |
jkim |
CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten years for head. However, it is continuously misused as the mpsafe argument for callout_init(9). Deprecate the flag and clean up callout_init() calls to make them more consistent.
Differential Revision: https://reviews.freebsd.org/D2613 Reviewed by: jhb MFC after: 2 weeks
|
#
275358 |
|
01-Dec-2014 |
hselasky |
Start process of removing the use of the deprecated "M_FLOWID" flag from the FreeBSD network code. The flag is still kept around in the "sys/mbuf.h" header file, but does no longer have any users. Instead the "m_pkthdr.rsstype" field in the mbuf structure is now used to decide the meaning of the "m_pkthdr.flowid" field. To modify the "m_pkthdr.rsstype" field please use the existing "M_HASHTYPE_XXX" macros as defined in the "sys/mbuf.h" header file.
This patch introduces new behaviour in the transmit direction. Previously network drivers checked if "M_FLOWID" was set in "m_flags" before using the "m_pkthdr.flowid" field. This check has now now been replaced by checking if "M_HASHTYPE_GET(m)" is different from "M_HASHTYPE_NONE". In the future more hashtypes will be added, for example hashtypes for hardware dedicated flows.
"M_HASHTYPE_OPAQUE" indicates that the "m_pkthdr.flowid" value is valid and has no particular type. This change removes the need for an "if" statement in TCP transmit code checking for the presence of a valid flowid value. The "if" statement mentioned above is now a direct variable assignment which is then later checked by the respective network drivers like before.
Additional notes: - The SCTP code changes will be committed as a separate patch. - Removal of the "M_FLOWID" flag will also be done separately. - The FreeBSD version has been bumped.
MFC after: 1 month Sponsored by: Mellanox Technologies
|
#
271946 |
|
22-Sep-2014 |
hselasky |
Improve transmit sending offload, TSO, algorithm in general.
The current TSO limitation feature only takes the total number of bytes in an mbuf chain into account and does not limit by the number of mbufs in a chain. Some kinds of hardware is limited by two factors. One is the fragment length and the second is the fragment count. Both of these limits need to be taken into account when doing TSO. Else some kinds of hardware might have to drop completely valid mbuf chains because they cannot loaded into the given hardware's DMA engine. The new way of doing TSO limitation has been made backwards compatible as input from other FreeBSD developers and will use defaults for values not set.
Reviewed by: adrian, rmacklem Sponsored by: Mellanox Technologies MFC after: 1 week
|
#
271849 |
|
19-Sep-2014 |
glebius |
Mechanically convert to if_inc_counter().
|
#
271551 |
|
13-Sep-2014 |
hselasky |
Revert r271504. A new patch to solve this issue will be made.
Suggested by: adrian @
|
#
271504 |
|
13-Sep-2014 |
hselasky |
Improve transmit sending offload, TSO, algorithm in general.
The current TSO limitation feature only takes the total number of bytes in an mbuf chain into account and does not limit by the number of mbufs in a chain. Some kinds of hardware is limited by two factors. One is the fragment length and the second is the fragment count. Both of these limits need to be taken into account when doing TSO. Else some kinds of hardware might have to drop completely valid mbuf chains because they cannot loaded into the given hardware's DMA engine. The new way of doing TSO limitation has been made backwards compatible as input from other FreeBSD developers and will use defaults for values not set.
MFC after: 1 week Sponsored by: Mellanox Technologies
|
#
268156 |
|
02-Jul-2014 |
luigi |
Various bugfixes from Stefano Garzarella:
1. oce_multiq_start(): make sure the buffer is consumed even on ENXIO 2. oce_multiq_transmit(): there is an extra call to drbr_enqueue() causing the mbuf to be enqueued twice when the NIC's queue is full, and potential panics 3. oce_multiq_transmit(): same problem fixed recently in ixgbe (r267187) and other drivers: if the mbuf is enqueued, the proper return value is 0
Submitted by: Stefano Garzarella MFC after: 3 days
|
#
267839 |
|
24-Jun-2014 |
delphij |
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 <VenkatKumar.Duvvuru Emulex.Com> MFC after: 3 days
|
#
263102 |
|
13-Mar-2014 |
glebius |
Since 32-bit if_baudrate isn't enough to describe a baud rate of a 10 Gbit interface, in the r241616 a crutch was provided. It didn't work well, and finally we decided that it is time to break ABI and simply make if_baudrate a 64-bit value. Meanwhile, the entire struct if_data was reviewed.
o Remove the if_baudrate_pf crutch.
o Make all fields of struct if_data fixed machine independent size. The notion of data (packet counters, etc) are by no means MD. And it is a bug that on amd64 we've got a 64-bit counters, while on i386 32-bit, which at modern speeds overflow within a second.
This also removes quite a lot of COMPAT_FREEBSD32 code.
o Give 16 bit for the ifi_datalen field. This field was provided to make future changes to if_data less ABI breaking. Unfortunately the 8 bit size of it had effectively limited sizeof if_data to 256 bytes.
o Give 32 bits to ifi_mtu and ifi_metric. o Give 64 bits to the rest of fields, since they are counters.
__FreeBSD_version bumped.
Discussed with: emax Sponsored by: Netflix Sponsored by: Nginx, Inc.
|
#
260110 |
|
30-Dec-2013 |
delphij |
Eliminate unused drbr_stats_update implementation in oce(4) driver.
Noticed by: dim MFC after: 2 weeks
|
#
258941 |
|
04-Dec-2013 |
delphij |
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 <VenkatKumar.Duvvuru Emulex Com> MFC after: 3 days
|
#
257007 |
|
23-Oct-2013 |
delphij |
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 after: 3 day
|
#
252869 |
|
06-Jul-2013 |
delphij |
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 after: 1 day
|
#
247880 |
|
06-Mar-2013 |
delphij |
Update driver to version 4.6.95.0.
Submitted by: "Duvvuru,Venkat Kumar" <VenkatKumar.Duvvuru Emulex.Com> MFC after: 3 days
|
#
246799 |
|
14-Feb-2013 |
jpaetzel |
Resolve issue that caused WITNESS to report LORs.
PR: kern/171838 Submitted by: Venkat Duvvuru <venkatduvvuru.ml@gmail.com> MFC after: 2 weeks
|
#
246482 |
|
07-Feb-2013 |
rrs |
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
|
#
246128 |
|
30-Jan-2013 |
sbz |
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
|
#
243857 |
|
04-Dec-2012 |
glebius |
Mechanically substitute flags from historic mbuf allocator with malloc(9) flags in sys/dev.
|
#
241844 |
|
22-Oct-2012 |
eadler |
remove duplicate semicolons where possible.
Approved by: cperciva MFC after: 1 week
|
#
241691 |
|
18-Oct-2012 |
jhb |
Use if_initbaudrate().
|
#
241037 |
|
28-Sep-2012 |
glebius |
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
|
#
231879 |
|
17-Feb-2012 |
luigi |
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
|
#
231511 |
|
11-Feb-2012 |
bz |
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.
|
#
231509 |
|
11-Feb-2012 |
bz |
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.
|
#
231437 |
|
10-Feb-2012 |
luigi |
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)
|