src/sys/dev/qlxge, branch upstream/11.1.0

net: Use M_HASHTYPE_OPAQUE_HASH if the mbuf flowid has hash properties

2016-06-07T04:51:50+00:00

Reviewed by:	hps, erj, tuexen
Sponsored by:	Microsoft OSTC
Differential Revision:	https://reviews.freebsd.org/D6688

sys/dev: minor spelling fixes.

2016-05-03T03:41:25+00:00

Most affect comments, very few have user-visible effects.

tcp/lro: Use tcp_lro_flush_all in device drivers to avoid code duplication

2016-04-01T06:28:33+00:00

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 
Sponsored by:	Microsoft OSTC
Differential Revision:	https://reviews.freebsd.org/D5725

CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than ten

2015-05-22T17:05:21+00:00

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

Start process of removing the use of the deprecated "M_FLOWID" flag

2014-12-01T11:45:24+00:00

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

Mechanically convert to if_inc_counter().

2014-09-19T03:51:26+00:00

Use define from if_var.h to access a field inside struct if_data,

2014-08-30T19:55:54+00:00

that resides in struct ifnet.

Sponsored by:	Nginx, Inc.

Unload maps for DMA buffers allocated via bus_dmamem_alloc() before

2014-06-11T20:44:02+00:00

freeing the buffers.

Reviewed by:	davidcs

Since 32-bit if_baudrate isn't enough to describe a baud rate of a 10 Gbit

2014-03-13T03:42:24+00:00

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.

Another round of removing historical mbuf(9) allocator flags.

2014-01-16T13:44:47+00:00

They are breeding! New ones arouse since last round.

Sponsored by:	Nginx, Inc.