History log of /freebsd/sys/netinet/raw_ip.c (Results 151 – 175 of 667)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 80dbff4e 04-Jan-2012 Sean Bruno <sbruno@FreeBSD.org>

IFC to head to catch up the bhyve branch

Approved by: grehan@


Revision tags: release/9.0.0
# 762ad1d6 02-Jan-2012 Bjoern A. Zeeb <bz@FreeBSD.org>

As I came by and noticed add a comment that inp locking is a bit optistic
(read: non-existent) here and should be fixed.


# 70d8f36a 27-Oct-2011 Peter Grehan <grehan@FreeBSD.org>

IFC @ r226824


# 50b1479e 07-Oct-2011 Andre Oppermann <andre@FreeBSD.org>

Add back the IP header length to the total packet length field on
raw IP sockets. It was deducted in ip_input() in preparation for
protocols interested only in the payload.

On raw sockets the IP he

Add back the IP header length to the total packet length field on
raw IP sockets. It was deducted in ip_input() in preparation for
protocols interested only in the payload.

On raw sockets the IP header should be delivered as it at came in
from the network except for the byte order swaps in some fields.

This brings us in line with all other OS'es that provide raw
IP sockets.

Reported by: Matthew Cini Sarreo <mcins1-at-gmail.com>
MFC after: 3 days

show more ...


# 935205e2 17-Jul-2011 Justin T. Gibbs <gibbs@FreeBSD.org>

Integrate from Head into ZFSD feature branch as of revision r224141.


# 23300944 30-Jun-2011 Peter Grehan <grehan@FreeBSD.org>

IFC @ r223696 to pick up dfr's userboot


# 40a03457 28-Jun-2011 Attilio Rao <attilio@FreeBSD.org>

MFC


# e0bfbfce 28-Jun-2011 Bjoern A. Zeeb <bz@FreeBSD.org>

Update packet filter (pf) code to OpenBSD 4.5.

You need to update userland (world and ports) tools
to be in sync with the kernel.

Submitted by: mlaier
Submitted by: eri


# a5615c90 28-Jun-2011 Peter Grehan <grehan@FreeBSD.org>

IFC @ r222830


# 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 ...


# 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


# 76273fcb 21-May-2011 Attilio Rao <attilio@FreeBSD.org>

MFC


# 5b84dc78 20-May-2011 Qing Li <qingli@FreeBSD.org>

The statically configured (permanent) ARP entries are removed when an
interface is brought down, even though the interface address is still
valid. This patch maintains the permanent ARP entries as lo

The statically configured (permanent) ARP entries are removed when an
interface is brought down, even though the interface address is still
valid. This patch maintains the permanent ARP entries as long as the
interface address (having the same prefix as that of the ARP entries)
is valid.

Reviewed by: delphij
MFC after: 5 days

show more ...


# 74e9dcf7 27-Apr-2011 Bjoern A. Zeeb <bz@FreeBSD.org>

MfP4 CH=192004:

Move ip_defttl to raw_ip.c where it is actually used. In an IPv6
only world we do not want to compile ip_input.c in for that and
it is a shared default with INET6.

Reviewed by: gnn

MfP4 CH=192004:

Move ip_defttl to raw_ip.c where it is actually used. In an IPv6
only world we do not want to compile ip_input.c in for that and
it is a shared default with INET6.

Reviewed by: gnn
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
MFC after: 4 days

show more ...


# 00c081e9 20-Apr-2011 Bjoern A. Zeeb <bz@FreeBSD.org>

MFp4 CH=191760:

When compiling out INET we still need the initialization routines
as well as the tuning and montoring sysctls shared with IPv6.

Move the two send/recvspace variables up from the mid

MFp4 CH=191760:

When compiling out INET we still need the initialization routines
as well as the tuning and montoring sysctls shared with IPv6.

Move the two send/recvspace variables up from the middle of the
file to ease compiling out the INET only code.

Reviewed by: gnn
Sponsored by: The FreeBSD Foundation
Sponsored by: iXsystems
MFC after: 3 days

show more ...


# 9b4fcf85 18-Feb-2011 Marcel Moolenaar <marcel@FreeBSD.org>

Merge svn+ssh://svn.freebsd.org/base/head@218816


Revision tags: release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0
# 79c3d51b 18-Jan-2011 Matthew D Fleming <mdf@FreeBSD.org>

Specify a CTLTYPE_FOO so that a future sysctl(8) change does not need
to rely on the format string. For SYSCTL_PROC instances that I
noticed a discrepancy between the CTLTYPE and the format specifie

Specify a CTLTYPE_FOO so that a future sysctl(8) change does not need
to rely on the format string. For SYSCTL_PROC instances that I
noticed a discrepancy between the CTLTYPE and the format specifier,
fix the CTLTYPE.

show more ...


# 6f3544cd 26-Oct-2010 Marcel Moolenaar <marcel@FreeBSD.org>

Merge svn+ssh://svn.freebsd.org/base/head@214309


# a458eaa0 12-Sep-2010 Qing Li <qingli@FreeBSD.org>

Adding an address on an interface also requires the loopback route to
that address be installed.

PR: kern/150481
Submitted by: Ingo Flaschberger <if at xip.at>
MFC after: 5 days


# c007b96a 17-Aug-2010 John Baldwin <jhb@FreeBSD.org>

Ensure a minimum "slop" of 10 extra pcb structures when providing a
memory size estimate to userland for pcb list sysctls. The previous
behavior of a "slop" of n/8 does not work well for small value

Ensure a minimum "slop" of 10 extra pcb structures when providing a
memory size estimate to userland for pcb list sysctls. The previous
behavior of a "slop" of n/8 does not work well for small values of n
(e.g. no slop at all if you have less than 8 open UDP connections).

Reviewed by: bz
MFC after: 1 week

show more ...


Revision tags: release/8.1.0_cvs, release/8.1.0
# 9307d8bd 08-May-2010 Marcel Moolenaar <marcel@FreeBSD.org>

Merge svn+ssh://svn.freebsd.org/base/head@207793


# 945f418a 06-May-2010 Kirk McKusick <mckusick@FreeBSD.org>

Final update to current version of head in preparation for reintegration.


12345678910>>...27