| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This reverts commit cf3bb1a7166bec431631defe01c8d4e706a99638.
TAG: CODEL
|
| |
|
|
|
|
|
|
|
| |
We should return OPAQUE from M_HASHTYPE_GET() if M_FLOWID is there and rsstype
is not set.
Submitted by: hans
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the field. It cannot be removed from stable/10 so restore it.
Change M_HASHTYPE_GET() and M_HASHTYPE_SET() to do the right thing when M_FLOWID
exists.
Also bumping the FreeBSD version to note the fact that M_FLOWID is brought back
in stable/10.
(Just a note that M_FLOWID has been removed from -head.)
Spotted by: np
Suggested by: hans
Reviewed by: hans, tuexen (earlier version)
Helped by: jhb, delphij, gjb
Sponsored by: Limelight Networks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r275358:
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.
r275483:
Remove M_FLOWID from SCTP code.
r276982:
Remove no longer used "M_FLOWID" flag from mbuf.h and update the netisr
manpage.
Note: The FreeBSD version has been bumped.
Reviewed by: hps, tuexen
Sponsored by: Limelight Networks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These macros are equivalent to the ones on head, except they are only exposed
when _KERNEL is defined, i.e. to kernel code, whereas the code on head is exposed
to userland as well
This is for improved forwards compatibility with mbuf(9) macros in head@r277203+,
and is required for a clean MFC of r279393
This is a direct commit to stable/10
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D2126
Reviewed by: glebius, rwatson
Sponsored by: EMC / Isilon Storage Division
|
|
|
|
|
|
| |
Clear an mbuf's external storage flags in m_extaddref(). They are cleared
in other places that set the external storage type (ext_type) such as
m_cljset(), m_extadd(), mb_ctor_clust(), and vn_sendfile().
|
|
|
|
|
|
|
|
|
| |
Add M_FLOWID to M_COPYFLAGS
The M_FLOWID flag should be propagated to the new mbuf pkthdr in
m_move_pkthdr() and m_dup_pkthdr(). The new mbuf already got the
existing flowid value, but would be ignored since the flag was
not set.
|
|
|
|
|
|
| |
Remove deprecated definition "m_act".
Suggested by: adrian, glebius
|
|
|
|
| |
Provide additional information in some panic strings.
|
|
|
|
|
|
| |
refcount. This one is willing to work with buffers that may already be
referenced. MEXTADD/m_extadd are suitable only for the first attachment
to a cluster -- they initialize the refcount to 1.
|
|
|
|
|
|
| |
Don't leak tags when M_NOFREE | M_PKTHDR mbufs are freed.
Reviewed by: andre
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
problems with the way MLEN, MHLEN, and struct mbuf are set up.
CTASSERT's are provided to detect such issues at compile time in the
future.
The #define MLEN and MHLEN calculation do not take actual compiler-
induced alignment and padding inside the complete struct mbuf into
account. Accordingly appropriate attention is required when changing
members of struct mbuf.
Ideally one would calculate MLEN as (MSIZE - sizeof(((struct mbuf *)0)->m_hdr)
but that doesn't work as the compiler refuses to operate on an as of
yet incomplete structure.
In particular ARM 32bit has more strict alignment requirements which
caused 4 bytes of padding between m_hdr and pkthdr in struct mbuf
because of the 64bit members in pkthdr. This wasn't picked up by MLEN
and MHLEN causing an overflow of the mbuf provided data storage by
overestimating its size.
I386 didn't show this problem because it handles unaligned access just
fine, albeit at a small performance penalty.
On 64bit architectures the struct mbuf layout is 64bit aligned in all
places.
Reported by: Thomas Skibo <ThomasSkibo-at-sbcglobal-dot-net>
Tested by: tuexen, ian, Thomas Skibo (extended patch)
Sponsored by: The FreeBSD Foundation
|
|
|
|
| |
Submitted by: tuexen
|
|
|
|
|
|
|
|
| |
external mbuf buffer management capabilities in the future.
For now only EXT_FREE_OK is defined with current legacy behavior.
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
| |
2 predictable branches nowadays. However as a pre-condition the
caller had to ensure that the mbuf pkthdr did not have any mtags
attached to it, costing some potential branches again.
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mbuf type is an enumerator with only a handful of types in use and
thus reduced from int to 8bits allowing for 255 types to be specified.
Only 5 types have been in use for a long time.
The flags field gets the remaining 24 bits with 12 bits for global
persistent flags and 12 bits for protocol/layer specific overlays.
Some of the global flags/functionality can be moved to the csum_flags
or ext_flags bits in the future.
MT_VENDOR[1-4] and MT_EXP[1-4] types for vendor-internal and
experimental local mapping are added.
The size of m_hdr shrinks from 24/40 to 20/32bytes (32/64bit architectures).
Sponsored by: The FreeBSD Foundation
|
|
|
|
| |
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
features. The changes in particular are:
o Remove rarely used "header" pointer and replace it with a 64bit protocol/
layer specific union PH_loc for local use. Protocols can flexibly overlay
their own 8 to 64 bit fields to store information while the packet is
worked on.
o Mechanically convert IP reassembly, IGMP/MLD and ATM to use pkthdr.PH_loc
instead of pkthdr.header.
o Extend csum_flags to 64bits to allow for additional future offload
information to be carried (e.g. iSCSI, IPsec offload, and others).
o Move the RSS hash type enumerator from abusing m_flags to its own 8bit
rsstype field. Adjust accessor macros.
o Add cosqos field to store Class of Service / Quality of Service information
with the packet. It is not yet supported in any drivers but allows us to
get on par with Cisco/Juniper in routing applications (plus MPLS QoS) with
a modernized ALTQ.
o Add four 8 bit fields l[2-5]hlen to store the relative header offsets
from the start of the packet. This is important for various offload
capabilities and to relieve the drivers from having to parse the packet
and protocol headers to find out location of checksums and other
information. Header parsing in drivers is a lot of copy-paste and
unhandled corner cases which we want to avoid.
o Add another flexible 64bit union to map various additional persistent
packet information, like ether_vtag, tso_segsz and csum fields.
Depending on the csum_flags settings some fields may have different usage
making it very flexible and adaptable to future capabilities.
o Restructure the CSUM flags to better signify their outbound (down the
stack) and inbound (up the stack) use. The CSUM flags used to be a bit
chaotic and rather poorly documented leading to incorrect use in many
places. Bring clarity into their use through better naming.
Compatibility mappings are provided to preserve the API. The drivers
can be corrected one by one and MFC'd without issue.
o The size of pkthdr stays the same at 48/56bytes (32/64bit architectures).
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
|
|
|
|
| |
free function access to the mbuf the external memory was attached
to.
Mechanically adjust all users to include the mbuf parameter.
This fixes a long standing annoyance for external free functions.
Before one had to sacrifice one of the argument pointers for this.
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to 8 bits. ext_type is an enumerator and the number of types we
have is a mere dozen.
A couple of ext_types are renumbered to fit within 8 bits.
EXT_VENDOR[1-4] and EXT_EXP[1-4] types for vendor-internal and
experimental local mapping.
The ext_flags field is currently unused but has a couple of flags
already defined for future use. Again vendor and experimental
flags are provided for local mapping.
EXT_FLAG_BITS is provided for the printf(9) %b identifier.
Initialize and copy ext_flags in the relevant mbuf functions.
Improve alignment and packing of struct m_ext on 32 and 64 archs
by carefully sorting the fields.
|
|
|
|
| |
Requested by: np, grehan
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
together.
Add M_FLAG_PRINTF for use with printf(9) %b indentifier.
Use the generic mbuf flags print names in the net80211 code and adjust
the protocol specific bits for their new positions.
Change SCTP M_PROTO mapping from 5 to 1 to fit within the 16bit field
they use internally to store some additional information.
Discussed with: trociny, glebius
|
|
|
|
|
|
|
|
| |
M_LASTFRAG flags to protocol specific flags.
Remove the now unused M_FRAG, M_FIRSTFRAG and M_LASTFRAG mbuf flags.
Discussed with: trociny, glebius, adrian
|
|
|
|
| |
Discussed with: trociny, glebius, adrian
|
|
|
|
|
|
|
|
| |
downwards layer crossings.
Consistently use it within IP, IPv6 and ethernet protocols.
Discussed with: trociny, glebius
|
|
|
|
|
|
|
| |
specific mbuf flag from sys/mbuf.h to netinet/sctp_os_bsd.h. It is
only relevant within SCTP.
Discussed with: tuexen
|
|
|
|
|
|
|
|
|
|
| |
for a very long time, if ever.
Should such a functionality ever be needed again the appropriate and
much better way to do it is through a custom EXT_SOMETHING external mbuf
type together with a dedicated *ext_free function.
Discussed with: trociny, glebius
|
|
|
|
|
|
|
|
|
|
| |
flag instead. The flag is only used within the IP and IPv6 layer 3
protocols.
Because some firewall packages treat IPv4 and IPv6 packets the same the
flag should have the same value for both.
Discussed with: trociny, glebius
|
|
|
|
|
|
| |
Now that r253351 moved sendfile() stats to a separate struct, the
last field used in mbstat is m_mcfail, which is updated, but never
read or obtained from userland.
|
|
|
|
|
|
|
| |
and remove corresponding fields from struct mbstat. Use PCPU counters
and SFSTAT_INC() macro for update these statistics.
Discussed with: glebius
|
|
|
|
| |
No effect as it wasn't used but was a) wrong b) clutter
|
| |
|
|
|
|
|
|
| |
4 flag bits. This was supposed to happen in 8.0, and again in 2012..
MFC after: never
|
|
|
|
| |
mbufs with external buffer.
|
|
|
|
|
|
|
| |
and that can drive someone crazy. While m_get2() is young and not
documented yet, change its order of arguments to match m_getm2().
Sorry for churn, but better now than later.
|
|
|
|
|
|
|
|
|
| |
- Make it return int, not void.
- Add wait parameter.
- Update MEXTADD() macro appropriately, defaults to M_NOWAIT, as
before this change.
Sponsored by: Nginx, Inc.
|
|
|
|
|
|
| |
constants to be integers.
Reviewed by: bde
|
|
|
|
|
|
| |
- style(9) fixes to mbuf.h
Reviewed by: bde
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tunable_mbinit() where it is next to where it is used later.
Change the sysinit level of tunable_mbinit() from SI_SUB_TUNABLES
to SI_SUB_KMEM after the VM is running. This allows to use better
methods to determine the effectively available physical and virtual
memory available to the kernel.
Update comments.
In a second step it can be merged into mbuf_init().
|
|
|
|
| |
Suggested by: glebius @
|
|
|
|
|
|
| |
Comparison between signed and unsigned.
MFC after: 1 week
|
|
|
|
|
|
|
|
|
| |
malloc(9) flags within sys.
Exceptions:
- sys/contrib not touched
- sys/mbuf.h edited manually
|
|
|
|
|
|
|
|
|
| |
variable as they may overflow on i386/PAE and i386 with > 2GB RAM.
Use 64bit quad_t instead. It has broader kernel infrastructure support
with TUNABLE_QUAD_FETCH() and qmin/qmax() than other available types.
Pointed out by: alc, bde
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
kernel memory, whichever is lower. The overall mbuf related memory
limit must be set so that mbufs (and clusters of various sizes)
can't exhaust physical RAM or KVM.
The limit is set to half of the physical RAM or KVM (whichever is
lower) as the baseline. In any normal scenario we want to leave
at least half of the physmem/kvm for other kernel functions and
userspace to prevent it from swapping too easily. Via a tunable
kern.maxmbufmem the limit can be upped to at most 3/4 of physmem/kvm.
At the same time divorce maxfiles from maxusers and set maxfiles to
physpages / 8 with a floor based on maxusers. This way busy servers
can make use of the significantly increased mbuf limits with a much
larger number of open sockets.
Tidy up ordering in init_param2() and check up on some users of
those values calculated here.
Out of the overall mbuf memory limit 2K clusters and 4K (page size)
clusters to get 1/4 each because these are the most heavily used mbuf
sizes. 2K clusters are used for MTU 1500 ethernet inbound packets.
4K clusters are used whenever possible for sends on sockets and thus
outbound packets. The larger cluster sizes of 9K and 16K are limited
to 1/6 of the overall mbuf memory limit. When jumbo MTU's are used
these large clusters will end up only on the inbound path. They are
not used on outbound, there it's still 4K. Yes, that will stay that
way because otherwise we run into lots of complications in the
stack. And it really isn't a problem, so don't make a scene.
Normal mbufs (256B) weren't limited at all previously. This was
problematic as there are certain places in the kernel that on
allocation failure of clusters try to piece together their packet
from smaller mbufs.
The mbuf limit is the number of all other mbuf sizes together plus
some more to allow for standalone mbufs (ACK for example) and to
send off a copy of a cluster. Unfortunately there isn't a way to
set an overall limit for all mbuf memory together as UMA doesn't
support such a limiting.
NB: Every cluster also has an mbuf associated with it.
Two examples on the revised mbuf sizing limits:
1GB KVM:
512MB limit for mbufs
419,430 mbufs
65,536 2K mbuf clusters
32,768 4K mbuf clusters
9,709 9K mbuf clusters
5,461 16K mbuf clusters
16GB RAM:
8GB limit for mbufs
33,554,432 mbufs
1,048,576 2K mbuf clusters
524,288 4K mbuf clusters
155,344 9K mbuf clusters
87,381 16K mbuf clusters
These defaults should be sufficient for even the most demanding
network loads.
MFC after: 1 month
|
|
|
|
|
|
| |
M_WAITOK over M_WAIT.
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
Checksumming the IP header of fragments is no different from doing
normal IP headers.
Discussed with: yongari
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into head. The most significant achievements in the new code:
o Fine grained locking, thus much better performance.
o Fixes to many problems in pf, that were specific to FreeBSD port.
New code doesn't have that many ifdefs and much less OpenBSDisms, thus
is more attractive to our developers.
Those interested in details, can browse through SVN log of the
projects/pf/head branch. And for reference, here is exact list of
revisions merged:
r232043, r232044, r232062, r232148, r232149, r232150, r232298, r232330,
r232332, r232340, r232386, r232390, r232391, r232605, r232655, r232656,
r232661, r232662, r232663, r232664, r232673, r232691, r233309, r233782,
r233829, r233830, r233834, r233835, r233836, r233865, r233866, r233868,
r233873, r234056, r234096, r234100, r234108, r234175, r234187, r234223,
r234271, r234272, r234282, r234307, r234309, r234382, r234384, r234456,
r234486, r234606, r234640, r234641, r234642, r234644, r234651, r235505,
r235506, r235535, r235605, r235606, r235826, r235991, r235993, r236168,
r236173, r236179, r236180, r236181, r236186, r236223, r236227, r236230,
r236252, r236254, r236298, r236299, r236300, r236301, r236397, r236398,
r236399, r236499, r236512, r236513, r236525, r236526, r236545, r236548,
r236553, r236554, r236556, r236557, r236561, r236570, r236630, r236672,
r236673, r236679, r236706, r236710, r236718, r237154, r237155, r237169,
r237314, r237363, r237364, r237368, r237369, r237376, r237440, r237442,
r237751, r237783, r237784, r237785, r237788, r237791, r238421, r238522,
r238523, r238524, r238525, r239173, r239186, r239644, r239652, r239661,
r239773, r240125, r240130, r240131, r240136, r240186, r240196, r240212.
I'd like to thank people who participated in early testing:
Tested by: Florian Smeets <flo freebsd.org>
Tested by: Chekaluk Vitaly <artemrts ukr.net>
Tested by: Ben Wilber <ben desync.com>
Tested by: Ian FREISLICH <ianf cloudseed.co.za>
|
|
|
|
|
|
|
| |
While there: remove some trainling whitespaces.
MFC after: 3 days
X-MFC with: 236170
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
headers for TSO but also for generic checksum offloading. Ideally we
would only have one common function shared amongst all drivers, and
perhaps when updating them for IPv6 we should introduce that.
Eventually we should provide the meta information along with mbufs to
avoid (re-)parsing entirely.
To not break IPv6 (checksums and offload) and to be able to MFC the
changes without risking to hurt 3rd party drivers, duplicate the v4
framework, as other OSes have done as well.
Introduce interface capability flags for TX/RX checksum offload with
IPv6, to allow independent toggling (where possible). Add CSUM_*_IPV6
flags for UDP/TCP over IPv6, and reserve further for SCTP, and IPv6
fragmentation. Define CSUM_DELAY_DATA_IPV6 as we do for legacy IP and
add an alias for CSUM_DATA_VALID_IPV6.
This pretty much brings IPv6 handling in line with IPv4.
TSO is still handled in a different way and not via if_hwassist.
Update ifconfig to allow (un)setting of the new capability flags.
Update loopback to announce the new capabilities and if_hwassist flags.
Individual driver updates will have to follow, as will SCTP.
Reported by: gallatin, dim, ..
Reviewed by: gallatin (glanced at?)
MFC after: 3 days
X-MFC with: r235961,235959,235958
|