History log of /freebsd/sys/netinet/in_pcb.h (Results 126 – 150 of 514)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


12345678910>>...21