#
becbad1f |
| 13-Oct-2015 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Merge from head
|
#
f94594b3 |
| 12-Sep-2015 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Finish merging from head, messed up in previous attempt
|
#
00176600 |
| 09-Sep-2015 |
Navdeep Parhar <np@FreeBSD.org> |
Merge r286744-r287584 from head.
|
#
d9442b10 |
| 05-Sep-2015 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r286858 through r287489.
|
#
388909a1 |
| 05-Sep-2015 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Use Jenkins hash for TCP syncache.
o Unlike xor, in Jenkins hash every bit of input affects virtually every bit of output, thus salting the hash actually works. With xor salting only provides a
Use Jenkins hash for TCP syncache.
o Unlike xor, in Jenkins hash every bit of input affects virtually every bit of output, thus salting the hash actually works. With xor salting only provides a false sense of security, since if hash(x) collides with hash(y), then of course, hash(x) ^ salt would also collide with hash(y) ^ salt. [1] o Jenkins provides much better distribution than xor, very close to ideal.
TCP connection setup/teardown benchmark has shown a 10% increase with default hash size, and with bigger hashes that still provide possibility for collisions. With enormous hash size, when dataset is by an order of magnitude smaller than hash size, the benchmark has shown 4% decrease in performance decrease, which is expected and acceptable.
Noticed by: Jeffrey Knockel <jeffk cs.unm.edu> [1] Benchmarks by: jch Reviewed by: jch, pkelsey, delphij Security: strengthens protection against hash collision DoS Sponsored by: Nginx, Inc.
show more ...
|
#
ab875b71 |
| 14-Aug-2015 |
Navdeep Parhar <np@FreeBSD.org> |
Catch up with head, primarily for the 1.14.4.0 firmware.
|
#
f98ee844 |
| 12-Aug-2015 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r286422 through r286684.
|
Revision tags: release/10.2.0 |
|
#
764a768e |
| 09-Aug-2015 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Merge from HEAD
|
#
079672cb |
| 08-Aug-2015 |
Julien Charbon <jch@FreeBSD.org> |
Fix a kernel assertion issue introduced with r286227: Avoid too strict INP_INFO_RLOCK_ASSERT checks due to tcp_notify() being called from in6_pcbnotify().
Reported by: Larry Rosenman <ler@lerctr.org
Fix a kernel assertion issue introduced with r286227: Avoid too strict INP_INFO_RLOCK_ASSERT checks due to tcp_notify() being called from in6_pcbnotify().
Reported by: Larry Rosenman <ler@lerctr.org> Submitted by: markj, jch
show more ...
|
#
1347814c |
| 07-Aug-2015 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r285924 through r286421.
|
#
ff9b006d |
| 03-Aug-2015 |
Julien Charbon <jch@FreeBSD.org> |
Decompose TCP INP_INFO lock to increase short-lived TCP connections scalability:
- The existing TCP INP_INFO lock continues to protect the global inpcb list stability during full list traversal (e
Decompose TCP INP_INFO lock to increase short-lived TCP connections scalability:
- The existing TCP INP_INFO lock continues to protect the global inpcb list stability during full list traversal (e.g. tcp_pcblist()).
- A new INP_LIST lock protects inpcb list actual modifications (inp allocation and free) and inpcb global counters.
It allows to use TCP INP_INFO_RLOCK lock in critical paths (e.g. tcp_input()) and INP_INFO_WLOCK only in occasional operations that walk all connections.
PR: 183659 Differential Revision: https://reviews.freebsd.org/D2599 Reviewed by: jhb, adrian Tested by: adrian, nitroboost-gmail.com Sponsored by: Verisign, Inc.
show more ...
|
#
98e0ffae |
| 27-May-2015 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge sync of head
|
#
d899be7d |
| 19-Jan-2015 |
Glen Barber <gjb@FreeBSD.org> |
Reintegrate head: r274132-r277384
Sponsored by: The FreeBSD Foundation
|
#
8f0ea33f |
| 13-Jan-2015 |
Glen Barber <gjb@FreeBSD.org> |
Reintegrate head revisions r273096-r277147
Sponsored by: The FreeBSD Foundation
|
#
da976f9d |
| 05-Dec-2014 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead @ r275496
|
#
60c317af |
| 01-Dec-2014 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r275262 through r275363.
|
#
c2529042 |
| 01-Dec-2014 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
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. In
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
show more ...
|
#
4d56c133 |
| 21-Nov-2014 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Sync to HEAD@r274766
|
#
9268022b |
| 19-Nov-2014 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge from head@274682
|
Revision tags: release/10.1.0 |
|
#
603eaf79 |
| 09-Nov-2014 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Renove faith(4) and faithd(8) from base. It looks like industry have chosen different (and more traditional) stateless/statuful NAT64 as translation mechanism. Last non-trivial commits to both faith(
Renove faith(4) and faithd(8) from base. It looks like industry have chosen different (and more traditional) stateless/statuful NAT64 as translation mechanism. Last non-trivial commits to both faith(4) and faithd(8) happened more than 12 years ago, so I assume it is time to drop RFC3142 in FreeBSD.
No objections from: net@
show more ...
|
#
1ce4b357 |
| 04-Oct-2014 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Sync to HEAD@r272516.
|
#
4e27d36d |
| 17-Sep-2014 |
Neel Natu <neel@FreeBSD.org> |
IFC @r271694
|
#
028bdf28 |
| 10-Sep-2014 |
Andrey V. Elsukov <ae@FreeBSD.org> |
Add scope zone id to the in_endpoints and hc_metrics structures.
A non-global IPv6 address can be used in more than one zone of the same scope. This zone index is used to identify to which zone a no
Add scope zone id to the in_endpoints and hc_metrics structures.
A non-global IPv6 address can be used in more than one zone of the same scope. This zone index is used to identify to which zone a non-global address belongs.
Also we can have many foreign hosts with equal non-global addresses, but from different zones. So, they can have different metrics in the host cache.
Obtained from: Yandex LLC Sponsored by: Yandex LLC
show more ...
|
#
1b44e5ff |
| 10-Sep-2014 |
Andrey V. Elsukov <ae@FreeBSD.org> |
Introduce INP6_PCBHASHKEY macro. Replace usage of hardcoded part of IPv6 address as hash key in all places.
Obtained from: Yandex LLC
|
#
9d3ddf43 |
| 09-Sep-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
Add support for receiving and setting flowtype, flowid and RSS bucket information as part of recvmsg().
This is primarily used for debugging/verification of the various processing paths in the IP, P
Add support for receiving and setting flowtype, flowid and RSS bucket information as part of recvmsg().
This is primarily used for debugging/verification of the various processing paths in the IP, PCB and driver layers.
Unfortunately the current implementation of the control message path results in a ~10% or so drop in UDP frame throughput when it's used.
Differential Revision: https://reviews.freebsd.org/D527 Reviewed by: grehan
show more ...
|