History log of /freebsd/sys/dev/oce/oce_if.c (Results 51 – 75 of 104)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 970388bf 28-Sep-2014 Neel Natu <neel@FreeBSD.org>

IFC @r272185


# 9fd573c3 22-Sep-2014 Hans Petter Selasky <hselasky@FreeBSD.org>

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

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

show more ...


# b6cf6c8c 20-Sep-2014 Neel Natu <neel@FreeBSD.org>

IFC @r271887


# c8dfaf38 19-Sep-2014 Gleb Smirnoff <glebius@FreeBSD.org>

Mechanically convert to if_inc_counter().


# 72f31000 13-Sep-2014 Hans Petter Selasky <hselasky@FreeBSD.org>

Revert r271504. A new patch to solve this issue will be made.

Suggested by: adrian @


# eb93b77a 13-Sep-2014 Hans Petter Selasky <hselasky@FreeBSD.org>

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

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

show more ...


# 246e7a2b 02-Sep-2014 Neel Natu <neel@FreeBSD.org>

IFC @r269962

Submitted by: Anish Gupta (akgupt3@gmail.com)


# ee7b0571 19-Aug-2014 Simon J. Gerraty <sjg@FreeBSD.org>

Merge head from 7/28


# 1b833d53 13-Aug-2014 Alexander V. Chernikov <melifaro@FreeBSD.org>

Sync to HEAD@r269943.


Revision tags: release/9.3.0
# d398c863 02-Jul-2014 Luigi Rizzo <luigi@FreeBSD.org>

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

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

show more ...


# a4f734b4 24-Jun-2014 Xin LI <delphij@FreeBSD.org>

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>

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

show more ...


# 6cec9cad 03-Jun-2014 Peter Grehan <grehan@FreeBSD.org>

MFC @ r266724

An SVM update will follow this.


# 3b8f0845 28-Apr-2014 Simon J. Gerraty <sjg@FreeBSD.org>

Merge head


# 84e51a1b 23-Apr-2014 Alan Somers <asomers@FreeBSD.org>

IFC @264767


# 1709ccf9 29-Mar-2014 Martin Matuska <mm@FreeBSD.org>

Merge head up to r263906.


# b245f96c 13-Mar-2014 Gleb Smirnoff <glebius@FreeBSD.org>

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 an

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.

show more ...


# 5748b897 19-Feb-2014 Martin Matuska <mm@FreeBSD.org>

Merge head up to r262222 (last merge was incomplete).


# 485ac45a 04-Feb-2014 Peter Grehan <grehan@FreeBSD.org>

MFC @ r259205 in preparation for some SVM updates. (for real this time)


Revision tags: release/10.0.0
# e01ff621 09-Jan-2014 Glen Barber <gjb@FreeBSD.org>

MFH: tracking commit (head@r260486)

Sponsored by: The FreeBSD Foundation


# 198f5735 30-Dec-2013 Xin LI <delphij@FreeBSD.org>

Eliminate unused drbr_stats_update implementation in oce(4) driver.

Noticed by: dim
MFC after: 2 weeks


# b41206d8 04-Dec-2013 Xin LI <delphij@FreeBSD.org>

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 th

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

show more ...


# f9b2a21c 31-Oct-2013 Gleb Smirnoff <glebius@FreeBSD.org>

Merge head r232040 through r257457.
M usr.sbin/portsnap/portsnap/portsnap.8
M usr.sbin/portsnap/portsnap/portsnap.sh
M usr.sbin/tcpdump/tcpdump/Makefile


# 5fbb6830 23-Oct-2013 Xin LI <delphij@FreeBSD.org>

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


# 0bfd163f 18-Oct-2013 Gleb Smirnoff <glebius@FreeBSD.org>

Merge head r233826 through r256722.


Revision tags: release/9.2.0
# d1d01586 05-Sep-2013 Simon J. Gerraty <sjg@FreeBSD.org>

Merge from head


12345