Revision tags: release/12.2.0 |
|
#
662c1305 |
| 01-Sep-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
net: clean up empty lines in .c and .h files
|
Revision tags: release/11.4.0 |
|
#
c1be8399 |
| 16-May-2020 |
Mark Johnston <markj@FreeBSD.org> |
pf: Add a new zone for per-table entry counters.
Right now we optionally allocate 8 counters per table entry, so in addition to memory consumed by counters, we require 8 pointers worth of space in e
pf: Add a new zone for per-table entry counters.
Right now we optionally allocate 8 counters per table entry, so in addition to memory consumed by counters, we require 8 pointers worth of space in each entry even when counters are not allocated (the default).
Instead, define a UMA zone that returns contiguous per-CPU counter arrays for use in table entries. On amd64 this reduces sizeof(struct pfr_kentry) from 216 to 160. The smaller size also results in better slab efficiency, so memory usage for large tables is reduced by about 28%.
Reviewed by: kp MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24843
show more ...
|
Revision tags: release/12.1.0, release/11.3.0 |
|
#
2aaf9152 |
| 18-Mar-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead@r345275
|
#
59048686 |
| 15-Mar-2019 |
Kristof Provost <kp@FreeBSD.org> |
pf :Use counter(9) in pf tables.
The counters of pf tables are updated outside the rule lock. That means state updates might overwrite each other. Furthermore allocation and freeing of counters happ
pf :Use counter(9) in pf tables.
The counters of pf tables are updated outside the rule lock. That means state updates might overwrite each other. Furthermore allocation and freeing of counters happens outside the lock as well.
Use counter(9) for the counters, and always allocate the counter table element, so that the race condition cannot happen any more.
PR: 230619 Submitted by: Kajetan Staszkiewicz <vegeta@tuxpowered.net> Reviewed by: glebius MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D19558
show more ...
|
#
c981cbbd |
| 15-Feb-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r343956 through r344177.
|
#
8f2ac656 |
| 11-Feb-2019 |
Patrick Kelsey <pkelsey@FreeBSD.org> |
Reduce the time it takes the kernel to install a new PF config containing a large number of queues
In general, the time savings come from separating the active and inactive queues lists into separat
Reduce the time it takes the kernel to install a new PF config containing a large number of queues
In general, the time savings come from separating the active and inactive queues lists into separate interface and non-interface queue lists, and changing the rule and queue tag management from list-based to hash-bashed.
In HFSC, a linear scan of the class table during each queue destroy was also eliminated.
There are now two new tunables to control the hash size used for each tag set (default for each is 128):
net.pf.queue_tag_hashsize net.pf.rule_tag_hashsize
Reviewed by: kp MFC after: 1 week Sponsored by: RG Nets Differential Revision: https://reviews.freebsd.org/D19131
show more ...
|
Revision tags: release/12.0.0 |
|
#
2a22df74 |
| 04-Nov-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r339813 through r340125.
|
#
fbbf436d |
| 02-Nov-2018 |
Kristof Provost <kp@FreeBSD.org> |
pfsync: Handle syncdev going away
If the syncdev is removed we no longer need to clean up the multicast entry we've got set up for that device.
Pass the ifnet detach event through pf to pfsync, and
pfsync: Handle syncdev going away
If the syncdev is removed we no longer need to clean up the multicast entry we've got set up for that device.
Pass the ifnet detach event through pf to pfsync, and remove our multicast handle, and mark us as no longer having a syncdev.
Note that this callback is always installed, even if the pfsync interface is disabled (and thus it's not a per-vnet callback pointer).
MFC after: 2 weeks Sponsored by: Orange Business Services Differential Revision: https://reviews.freebsd.org/D17502
show more ...
|
#
5f6cf24e |
| 02-Nov-2018 |
Kristof Provost <kp@FreeBSD.org> |
pfsync: Make pfsync callbacks per-vnet
The callbacks are installed and removed depending on the state of the pfsync device, which is per-vnet. The callbacks must also be per-vnet.
MFC after: 2 week
pfsync: Make pfsync callbacks per-vnet
The callbacks are installed and removed depending on the state of the pfsync device, which is per-vnet. The callbacks must also be per-vnet.
MFC after: 2 weeks Sponsored by: Orange Business Services Differential Revision: https://reviews.freebsd.org/D17499
show more ...
|
#
790194cd |
| 02-Nov-2018 |
Kristof Provost <kp@FreeBSD.org> |
pf: Limit the fragment entry queue length to 64 per bucket.
So we have a global limit of 1024 fragments, but it is fine grained to the region of the packet. Smaller packets may have less fragments.
pf: Limit the fragment entry queue length to 64 per bucket.
So we have a global limit of 1024 fragments, but it is fine grained to the region of the packet. Smaller packets may have less fragments. This costs another 16 bytes of memory per reassembly and devides the worst case for searching by 8.
Obtained from: OpenBSD Differential Revision: https://reviews.freebsd.org/D17734
show more ...
|
#
fd2ea405 |
| 02-Nov-2018 |
Kristof Provost <kp@FreeBSD.org> |
pf: Split the fragment reassembly queue into smaller parts
Remember 16 entry points based on the fragment offset. Instead of a worst case of 8196 list traversals we now check a maximum of 512 list
pf: Split the fragment reassembly queue into smaller parts
Remember 16 entry points based on the fragment offset. Instead of a worst case of 8196 list traversals we now check a maximum of 512 list entries or 16 array elements.
Obtained from: OpenBSD Differential Revision: https://reviews.freebsd.org/D17733
show more ...
|
#
7847e041 |
| 24-Aug-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r338026 through r338297, and resolve conflicts.
|
#
249cc75f |
| 22-Aug-2018 |
Patrick Kelsey <pkelsey@FreeBSD.org> |
Extended pf(4) ioctl interface and pfctl(8) to allow bandwidths of 2^32 bps or greater to be used. Prior to this, bandwidth parameters would simply wrap at the 2^32 boundary. The computations in th
Extended pf(4) ioctl interface and pfctl(8) to allow bandwidths of 2^32 bps or greater to be used. Prior to this, bandwidth parameters would simply wrap at the 2^32 boundary. The computations in the HFSC scheduler and token bucket regulator have been modified to operate correctly up to at least 100 Gbps. No other algorithms have been examined or modified for correct operation above 2^32 bps (some may have existing computation resolution or overflow issues at rates below that threshold). pfctl(8) will now limit non-HFSC bandwidth parameters to 2^32 - 1 before passing them to the kernel.
The extensions to the pf(4) ioctl interface have been made in a backwards-compatible way by versioning affected data structures, supporting all versions in the kernel, and implementing macros that will cause existing code that consumes that interface to use version 0 without source modifications. If version 0 consumers of the interface are used against a new kernel that has had bandwidth parameters of 2^32 or greater configured by updated tools, such bandwidth parameters will be reported as 2^32 - 1 bps by those old consumers.
All in-tree consumers of the pf(4) interface have been updated. To update out-of-tree consumers to the latest version of the interface, define PFIOC_USE_LATEST ahead of any includes and use the code of pfctl(8) as a guide for the ioctls of interest.
PR: 211730 Reviewed by: jmallett, kp, loos MFC after: 2 weeks Relnotes: yes Sponsored by: RG Nets Differential Revision: https://reviews.freebsd.org/D16782
show more ...
|
#
14b841d4 |
| 11-Aug-2018 |
Kyle Evans <kevans@FreeBSD.org> |
MFH @ r337607, in preparation for boarding
|
#
f9c0a512 |
| 10-Aug-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r337286 through r337585.
|
#
91e0f2d2 |
| 05-Aug-2018 |
Kristof Provost <kp@FreeBSD.org> |
pf: Increase default hash table size
Now that we (by default) limit the number of states to 100.000 it makse sense to also adjust the default size of the hash table.
Based on the benchmarking resul
pf: Increase default hash table size
Now that we (by default) limit the number of states to 100.000 it makse sense to also adjust the default size of the hash table.
Based on the benchmarking results in https://github.com/ocochard/netbenches/blob/master/Atom_C2758_8Cores-Chelsio_T540-CR/pf-states_hashsize/results/fbsd12-head.r332390/README.md 128K entries offers a good compromise between performance and memory use.
Users may still overrule this setting with the net.pf.states_hashsize and net.pf.source_nodes_hashsize loader(8) tunables.
show more ...
|
#
b895839d |
| 12-Jul-2018 |
Kristof Provost <kp@FreeBSD.org> |
pf: Fix typo in r336221
Reported by: olivier@
|
#
f4cdb8ae |
| 12-Jul-2018 |
Kristof Provost <kp@FreeBSD.org> |
pf: Increate default state table size
The typical system now has a lot more memory than when pf was new, and is also expected to handle more connections. Increase the default size of the state table
pf: Increate default state table size
The typical system now has a lot more memory than when pf was new, and is also expected to handle more connections. Increase the default size of the state table. Note that users can overrule this using 'set limit states' in pf.conf.
From OpenBSD: The year is 2018. Mercury, Bowie, Cash, Motorola and DEC all left us. Just pf still has a default state table limit of 10000. Had! Now it's a tiny little bit more, 100k. lead guitar: me ok chorus: phessler theo claudio benno background school girl laughing: bob
Obtained from: OpenBSD
show more ...
|
#
cc535c95 |
| 04-Jul-2018 |
Will Andrews <will@FreeBSD.org> |
Revert r335833.
Several third-parties use at least some of these ioctls. While it would be better for regression testing if they were used in base (or at least in the test suite), it's currently no
Revert r335833.
Several third-parties use at least some of these ioctls. While it would be better for regression testing if they were used in base (or at least in the test suite), it's currently not worth the trouble to push through removal.
Submitted by: antoine, markj
show more ...
|
#
c1887e9f |
| 01-Jul-2018 |
Will Andrews <will@FreeBSD.org> |
pf: remove unused ioctls.
Several ioctls are unused in pf, in the sense that no base utility references them. Additionally, a cursory review of pf-based ports indicates they're not used elsewhere e
pf: remove unused ioctls.
Several ioctls are unused in pf, in the sense that no base utility references them. Additionally, a cursory review of pf-based ports indicates they're not used elsewhere either. Some of them have been unused since the original import. As far as I can tell, they're also unused in OpenBSD. Finally, removing this code removes the need for future pf work to take them into account.
Reviewed by: kp Differential Revision: https://reviews.freebsd.org/D16076
show more ...
|
Revision tags: release/11.2.0 |
|
#
d25c25dc |
| 30-May-2018 |
Kristof Provost <kp@FreeBSD.org> |
pf: Add missing include statement
rmlocks require <sys/lock.h> as well as <sys/rmlock.h>. Unbreak mips build.
|
#
455969d3 |
| 30-May-2018 |
Kristof Provost <kp@FreeBSD.org> |
pf: Replace rwlock on PF_RULES_LOCK with rmlock
Given that PF_RULES_LOCK is a mostly read lock, replace the rwlock with rmlock. This change improves packet processing rate in high pps environments.
pf: Replace rwlock on PF_RULES_LOCK with rmlock
Given that PF_RULES_LOCK is a mostly read lock, replace the rwlock with rmlock. This change improves packet processing rate in high pps environments. Benchmarking by olivier@ shows a 65% improvement in pps.
While here, also eliminate all appearances of "sys/rwlock.h" includes since it is not used anymore.
Submitted by: farrokhi@ Differential Revision: https://reviews.freebsd.org/D15502
show more ...
|
#
adfe2f6a |
| 06-Apr-2018 |
Kristof Provost <kp@FreeBSD.org> |
pf: Improve ioctl validation for DIOCRGETTABLES, DIOCRGETTSTATS, DIOCRCLRTSTATS and DIOCRSETTFLAGS
These ioctls can process a number of items at a time, which puts us at risk of overflow in mallocar
pf: Improve ioctl validation for DIOCRGETTABLES, DIOCRGETTSTATS, DIOCRCLRTSTATS and DIOCRSETTFLAGS
These ioctls can process a number of items at a time, which puts us at risk of overflow in mallocarray() and of impossibly large allocations even if we don't overflow.
Limit the allocation to required size (or the user allocation, if that's smaller). That does mean we need to do the allocation with the rules lock held (so the number doesn't change while we're doing this), so it can't M_WAITOK.
MFC after: 1 week
show more ...
|
#
effaab88 |
| 23-Mar-2018 |
Kristof Provost <kp@FreeBSD.org> |
netpfil: Introduce PFIL_FWD flag
Forwarded packets passed through PFIL_OUT, which made it difficult for firewalls to figure out if they were forwarding or producing packets. This in turn is an issue
netpfil: Introduce PFIL_FWD flag
Forwarded packets passed through PFIL_OUT, which made it difficult for firewalls to figure out if they were forwarding or producing packets. This in turn is an issue for pf for IPv6 fragment handling: it needs to call ip6_output() or ip6_forward() to handle the fragments. Figuring out which was difficult (and until now, incorrect). Having pfil distinguish the two removes an ugly piece of code from pf.
Introduce a new variant of the netpfil callbacks with a flags variable, which has PFIL_FWD set for forwarded packets. This allows pf to reliably work out if a packet is forwarded.
Reviewed by: ae, kevans Differential Revision: https://reviews.freebsd.org/D13715
show more ...
|
#
bf56a3fe |
| 25-Feb-2018 |
Kristof Provost <kp@FreeBSD.org> |
pf: Cope with overly large net.pf.states_hashsize
If the user configures a states_hashsize or source_nodes_hashsize value we may not have enough memory to allocate this. This used to lock up pf, bec
pf: Cope with overly large net.pf.states_hashsize
If the user configures a states_hashsize or source_nodes_hashsize value we may not have enough memory to allocate this. This used to lock up pf, because these allocations used M_WAITOK.
Cope with this by attempting the allocation with M_NOWAIT and falling back to the default sizes (with M_WAITOK) if these fail.
PR: 209475 Submitted by: Fehmi Noyan Isi <fnoyanisi AT yahoo.com> MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D14367
show more ...
|