#
6cf87ec8 |
| 13-Jul-2012 |
Xin LI <delphij@FreeBSD.org> |
IFC @238412.
|
#
b652778e |
| 11-Jul-2012 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r238370
|
#
3cca425b |
| 12-Jun-2012 |
Michael Tuexen <tuexen@FreeBSD.org> |
Add a IP_RECVTOS socket option to receive for received UDP/IPv4 packets a cmsg of type IP_RECVTOS which contains the TOS byte. Much like IP_RECVTTL does for TTL. This allows to implement a protocol o
Add a IP_RECVTOS socket option to receive for received UDP/IPv4 packets a cmsg of type IP_RECVTOS which contains the TOS byte. Much like IP_RECVTTL does for TTL. This allows to implement a protocol on top of UDP and implementing ECN.
MFC after: 3 days
show more ...
|
#
6a068746 |
| 15-May-2012 |
Alexander Motin <mav@FreeBSD.org> |
MFC
|
#
38f1b189 |
| 26-Apr-2012 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r234692
sys/amd64/include/cpufunc.h sys/amd64/include/fpu.h sys/amd64/amd64/fpu.c sys/amd64/vmm/vmm.c
- Add API to allow vmm FPU state init/save/restore.
FP stuff discussed with: kib
|
Revision tags: release/8.3.0_cvs, release/8.3.0 |
|
#
8833b15f |
| 03-Apr-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r232686 through r233825 into projects/pf/head.
|
#
75410f02 |
| 17-Mar-2012 |
Robert Millan <rmh@FreeBSD.org> |
Hide a few declarations from userland (including `struct inpcbgroup'). This removes the dependency on <machine/param.h> which was introduced with SVN rev 222748 (due to CACHE_LINE_SIZE).
Reviewed by
Hide a few declarations from userland (including `struct inpcbgroup'). This removes the dependency on <machine/param.h> which was introduced with SVN rev 222748 (due to CACHE_LINE_SIZE).
Reviewed by: bde MFC after: 10 days
show more ...
|
#
8fa0b743 |
| 23-Jan-2012 |
Xin LI <delphij@FreeBSD.org> |
IFC @230489 (pending review).
|
Revision tags: release/9.0.0 |
|
#
3ee1a36e |
| 22-Nov-2011 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r227804
Pull in the virtio drivers from head.
|
#
fc06cd42 |
| 06-Nov-2011 |
Mikolaj Golub <trociny@FreeBSD.org> |
Cache SO_REUSEPORT socket option in inpcb-layer in order to avoid inp_socket->so_options dereference when we may not acquire the lock on the inpcb.
This fixes the crash due to NULL pointer dereferen
Cache SO_REUSEPORT socket option in inpcb-layer in order to avoid inp_socket->so_options dereference when we may not acquire the lock on the inpcb.
This fixes the crash due to NULL pointer dereference in in_pcbbind_setup() when inp_socket->so_options in a pcb returned by in_pcblookup_local() was checked.
Reported by: dave jones <s.dave.jones@gmail.com>, Arnaud Lacombe <lacombar@gmail.com> Suggested by: rwatson Glanced by: rwatson Tested by: dave jones <s.dave.jones@gmail.com>
show more ...
|
#
bd2228ab |
| 19-Jul-2011 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r224187
|
#
c462f54d |
| 18-Jul-2011 |
Justin T. Gibbs <gibbs@FreeBSD.org> |
Integrate from head into ZFSD feature branch as of revision 224171.
|
#
d9a36286 |
| 17-Jul-2011 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Add spares to the network stack for FreeBSD-9: - TCP keep* timers - TCP UTO (adjust from what was there already) - netmap - route caching - user cookie (temporary to allow for the real fix)
Slightly
Add spares to the network stack for FreeBSD-9: - TCP keep* timers - TCP UTO (adjust from what was there already) - netmap - route caching - user cookie (temporary to allow for the real fix)
Slightly re-shuffle struct ifnet moving fields out of the middle of spares and to better align.
Discussed with: rwatson (slightly earlier version)
show more ...
|
#
a5615c90 |
| 28-Jun-2011 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r222830
|
#
9c68ff47 |
| 07-Jun-2011 |
Attilio Rao <attilio@FreeBSD.org> |
MFC
|
#
1417604e |
| 06-Jun-2011 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Unbreak kernels with non-default PCBGROUP included but no WITNESS. Rather than including lock.h in in_pcbgroup.c in right order, fix it for all consumers of in_pcb.h by further header file pollution
Unbreak kernels with non-default PCBGROUP included but no WITNESS. Rather than including lock.h in in_pcbgroup.c in right order, fix it for all consumers of in_pcb.h by further header file pollution under #ifdef KERNEL.
Reported by: Pan Tsu (inyaoo gmail.com)
show more ...
|
#
81c02539 |
| 06-Jun-2011 |
Attilio Rao <attilio@FreeBSD.org> |
MFC
|
#
52cd27cb |
| 06-Jun-2011 |
Robert Watson <rwatson@FreeBSD.org> |
Implement a CPU-affine TCP and UDP connection lookup data structure, struct inpcbgroup. pcbgroups, or "connection groups", supplement the existing inpcbinfo connection hash table, which when pcbgrou
Implement a CPU-affine TCP and UDP connection lookup data structure, struct inpcbgroup. pcbgroups, or "connection groups", supplement the existing inpcbinfo connection hash table, which when pcbgroups are enabled, might now be thought of more usefully as a per-protocol 4-tuple reservation table.
Connections are assigned to connection groups base on a hash of their 4-tuple; wildcard sockets require special handling, and are members of all connection groups. During a connection lookup, a per-connection group lock is employed rather than the global pcbinfo lock. By aligning connection groups with input path processing, connection groups take on an effective CPU affinity, especially when aligned with RSS work placement (see a forthcoming commit for details). This eliminates cache line migration associated with global, protocol-layer data structures in steady state TCP and UDP processing (with the exception of protocol-layer statistics; further commit to follow).
Elements of this approach were inspired by Willman, Rixner, and Cox's 2006 USENIX paper, "An Evaluation of Network Stack Parallelization Strategies in Modern Operating Systems". However, there are also significant differences: we maintain the inpcb lock, rather than using the connection group lock for per-connection state.
Likewise, the focus of this implementation is alignment with NIC packet distribution strategies such as RSS, rather than pure software strategies. Despite that focus, software distribution is supported through the parallel netisr implementation, and works well in configurations where the number of hardware threads is greater than the number of NIC input queues, such as in the RMI XLR threaded MIPS architecture.
Another important difference is the continued maintenance of existing hash tables as "reservation tables" -- these are useful both to distinguish the resource allocation aspect of protocol name management and the more common-case lookup aspect. In configurations where connection tables are aligned with hardware hashes, it is desirable to use the traditional lookup tables for loopback or encapsulated traffic rather than take the expense of hardware hashes that are hard to implement efficiently in software (such as RSS Toeplitz).
Connection group support is enabled by compiling "options PCBGROUP" into your kernel configuration; for the time being, this is an experimental feature, and hence is not enabled by default.
Subject to the limited MFCability of change dependencies in inpcb, and its change to the inpcbinfo init function signature, this change in principle could be merged to FreeBSD 8.x.
Reviewed by: bz Sponsored by: Juniper Networks, Inc.
show more ...
|
#
3bce356e |
| 05-Jun-2011 |
Attilio Rao <attilio@FreeBSD.org> |
MFC
|
#
d3c1f003 |
| 04-Jun-2011 |
Robert Watson <rwatson@FreeBSD.org> |
Add _mbuf() variants of various inpcb-related interfaces, including lookup, hash install, etc. For now, these are arguments are unused, but as we add RSS support, we will want to use hashes extracte
Add _mbuf() variants of various inpcb-related interfaces, including lookup, hash install, etc. For now, these are arguments are unused, but as we add RSS support, we will want to use hashes extracted from mbufs, rather than manually calculated hashes of header fields, due to the expensive of the software version of Toeplitz (and similar hashes).
Add notes that it would be nice to be able to pass mbufs into lookup routines in pf(4), optimising firewall lookup in the same way, but the code structure there doesn't facilitate that currently.
(In principle there is no reason this couldn't be MFCed -- the change extends rather than modifies the KBI. However, it won't be useful without other previous possibly less MFCable changes.)
Reviewed by: bz Sponsored by: Juniper Networks, Inc.
show more ...
|
#
5b6ea0b5 |
| 31-May-2011 |
Attilio Rao <attilio@FreeBSD.org> |
MFC
|
#
fa046d87 |
| 30-May-2011 |
Robert Watson <rwatson@FreeBSD.org> |
Decompose the current single inpcbinfo lock into two locks:
- The existing ipi_lock continues to protect the global inpcb list and inpcb counter. This lock is now relegated to a small number of
Decompose the current single inpcbinfo lock into two locks:
- The existing ipi_lock continues to protect the global inpcb list and inpcb counter. This lock is now relegated to a small number of allocation and free operations, and occasional operations that walk all connections (including, awkwardly, certain UDP multicast receive operations -- something to revisit).
- A new ipi_hash_lock protects the two inpcbinfo hash tables for looking up connections and bound sockets, manipulated using new INP_HASH_*() macros. This lock, combined with inpcb locks, protects the 4-tuple address space.
Unlike the current ipi_lock, ipi_hash_lock follows the individual inpcb connection locks, so may be acquired while manipulating a connection on which a lock is already held, avoiding the need to acquire the inpcbinfo lock preemptively when a binding change might later be required. As a result, however, lookup operations necessarily go through a reference acquire while holding the lookup lock, later acquiring an inpcb lock -- if required.
A new function in_pcblookup() looks up connections, and accepts flags indicating how to return the inpcb. Due to lock order changes, callers no longer need acquire locks before performing a lookup: the lookup routine will acquire the ipi_hash_lock as needed. In the future, it will also be able to use alternative lookup and locking strategies transparently to callers, such as pcbgroup lookup. New lookup flags are, supplementing the existing INPLOOKUP_WILDCARD flag:
INPLOOKUP_RLOCKPCB - Acquire a read lock on the returned inpcb INPLOOKUP_WLOCKPCB - Acquire a write lock on the returned inpcb
Callers must pass exactly one of these flags (for the time being).
Some notes:
- All protocols are updated to work within the new regime; especially, TCP, UDPv4, and UDPv6. pcbinfo ipi_lock acquisitions are largely eliminated, and global hash lock hold times are dramatically reduced compared to previous locking. - The TCP syncache still relies on the pcbinfo lock, something that we may want to revisit. - Support for reverting to the FreeBSD 7.x locking strategy in TCP input is no longer available -- hash lookup locks are now held only very briefly during inpcb lookup, rather than for potentially extended periods. However, the pcbinfo ipi_lock will still be acquired if a connection state might change such that a connection is added or removed. - Raw IP sockets continue to use the pcbinfo ipi_lock for protection, due to maintaining their own hash tables. - The interface in6_pcblookup_hash_locked() is maintained, which allows callers to acquire hash locks and perform one or more lookups atomically with 4-tuple allocation: this is required only for TCPv6, as there is no in6_pcbconnect_setup(), which there should be. - UDPv6 locking remains significantly more conservative than UDPv4 locking, which relates to source address selection. This needs attention, as it likely significantly reduces parallelism in this code for multithreaded socket use (such as in BIND). - In the UDPv4 and UDPv6 multicast cases, we need to revisit locking somewhat, as they relied on ipi_lock to stablise 4-tuple matches, which is no longer sufficient. A second check once the inpcb lock is held should do the trick, keeping the general case from requiring the inpcb lock for every inpcb visited. - This work reminds us that we need to revisit locking of the v4/v6 flags, which may be accessed lock-free both before and after this change. - Right now, a single lock name is used for the pcbhash lock -- this is undesirable, and probably another argument is required to take care of this (or a char array name field in the pcbinfo?).
This is not an MFC candidate for 8.x due to its impact on lookup and locking semantics. It's possible some of these issues could be worked around with compatibility wrappers, if necessary.
Reviewed by: bz Sponsored by: Juniper Networks, Inc.
show more ...
|
#
87c3644c |
| 24-May-2011 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r222256
|
#
3ac3f600 |
| 24-May-2011 |
Attilio Rao <attilio@FreeBSD.org> |
MFC
|
#
79bdc6e5 |
| 23-May-2011 |
Robert Watson <rwatson@FreeBSD.org> |
Continue to refine inpcb reference counting and locking, in preparation for reworking of inpcbinfo locking:
(1) Convert inpcb reference counting from manually manipulated integers to the refcoun
Continue to refine inpcb reference counting and locking, in preparation for reworking of inpcbinfo locking:
(1) Convert inpcb reference counting from manually manipulated integers to the refcount(9) KPI. This allows the refcount to be managed atomically with an inpcb read lock rather than write lock, or even with no inpcb lock at all. As a result, in_pcbref() also no longer requires an inpcb lock, so can be performed solely using the lock used to look up an inpcb.
(2) Shift more inpcb freeing activity from the in_pcbrele() context (via in_pcbfree_internal) to the explicit in_pcbfree() context. This means that the inpcb refcount is increasingly used only to maintain memory stability, not actually defer the clean up of inpcb protocol parts. This is desirable as many of those protocol parts required the pcbinfo lock, which we'd like not to acquire in in_pcbrele() contexts. Document this in comments better.
(3) Introduce new read-locked and write-locked in_pcbrele() variations, in_pcbrele_rlocked() and in_pcbrele_wlocked(), which allow the inpcb to be properly unlocked as needed. in_pcbrele() is a wrapper around the latter, and should probably go away at some point. This makes it easier to use this weak reference model when holding only a read lock, as will happen in the future.
This may well be safe to MFC, but some more KBI analysis is required.
Reviewed by: bz MFC after: 3 weeks Sponsored by: Juniper Networks, Inc.
show more ...
|