#
1b833d53 |
| 13-Aug-2014 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Sync to HEAD@r269943.
|
#
e167cb89 |
| 10-Aug-2014 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Fix string length argument passed to "sysctl_handle_string()" so that the complete string is returned by the function and not just only one byte.
PR: 192544 MFC after: 2 weeks
|
Revision tags: release/9.3.0, release/10.0.0, release/9.2.0, release/8.4.0, release/9.1.0, release/8.3.0_cvs, release/8.3.0, release/9.0.0 |
|
#
891b8ed4 |
| 12-Apr-2011 |
Lawrence Stewart <lstewart@FreeBSD.org> |
Use the full and proper company name for Swinburne University of Technology throughout the source tree.
Requested by: Grenville Armitage, Director of CAIA at Swinburne University of Technology MF
Use the full and proper company name for Swinburne University of Technology throughout the source tree.
Requested by: Grenville Armitage, Director of CAIA at Swinburne University of Technology 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 |
|
#
a66ac850 |
| 23-Jan-2011 |
Lawrence Stewart <lstewart@FreeBSD.org> |
An sbuf configured with SBUF_AUTOEXTEND will call malloc with M_WAITOK when a write to the buffer causes it to overflow. We therefore can't hold the CC list rwlock over a call to sbuf_printf() for an
An sbuf configured with SBUF_AUTOEXTEND will call malloc with M_WAITOK when a write to the buffer causes it to overflow. We therefore can't hold the CC list rwlock over a call to sbuf_printf() for an sbuf configured with SBUF_AUTOEXTEND.
Switch to a fixed length sbuf which should be of sufficient size except in the very unlikely event that the sysctl is being processed as one or more new algorithms are loaded. If that happens, we accept the race and may fail the sysctl gracefully if there is insufficient room to print the names of all the algorithms.
This should address a WITNESS warning and the potential panic that would occur if the sbuf call to malloc did sleep whilst holding the CC list rwlock.
Sponsored by: FreeBSD Foundation Reported by: Nick Hibma Reviewed by: bz MFC after: 3 weeks X-MFC with: r215166
show more ...
|
#
0c21a60c |
| 05-Dec-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
svn+ssh://svn.freebsd.org/base/head@216199
|
#
9977fc32 |
| 16-Nov-2010 |
Dimitry Andric <dim@FreeBSD.org> |
Sync: merge r215319 through r215395 from ^/head, so ports can actually build! :)
|
#
78b01840 |
| 16-Nov-2010 |
Lawrence Stewart <lstewart@FreeBSD.org> |
Make the CC framework more VIMAGE friendly by adding the machinery to allow vnets to select their own default CC algorithm independent of each other and the base system. If the base system or a vnet
Make the CC framework more VIMAGE friendly by adding the machinery to allow vnets to select their own default CC algorithm independent of each other and the base system. If the base system or a vnet has set a default which gets unloaded, we reset that netstack's default to NewReno.
Sponsored by: FreeBSD Foundation Tested by: Mikolaj Golub <to.my.trociny at gmail com> Reviewed by: bz (briefly) MFC after: 3 months
show more ...
|
#
ebf92e86 |
| 16-Nov-2010 |
Lawrence Stewart <lstewart@FreeBSD.org> |
- Querying the default CC algo is more common than setting it and the function is small, so there is no good reason not to declare the buffer at the top.
- Fix a whitespace nit.
Sponsored by: Fre
- Querying the default CC algo is more common than setting it and the function is small, so there is no good reason not to declare the buffer at the top.
- Fix a whitespace nit.
Sponsored by: FreeBSD Foundation MFC after: 11 weeks X-MFC with: r215166
show more ...
|
#
99065ae6 |
| 16-Nov-2010 |
Lawrence Stewart <lstewart@FreeBSD.org> |
Move protocol specific implementation detail out of the core CC framework.
Sponsored by: FreeBSD Foundation Tested by: Mikolaj Golub <to.my.trociny at gmail com> MFC after: 11 weeks X-MFC with: r215
Move protocol specific implementation detail out of the core CC framework.
Sponsored by: FreeBSD Foundation Tested by: Mikolaj Golub <to.my.trociny at gmail com> MFC after: 11 weeks X-MFC with: r215166
show more ...
|
#
4e805854 |
| 16-Nov-2010 |
Lawrence Stewart <lstewart@FreeBSD.org> |
On CC algorithm module unload, we walk the list of active TCP control blocks. Any found to be using the algorithm that is about to go away are switched back to NewReno to avoid leaving dangling point
On CC algorithm module unload, we walk the list of active TCP control blocks. Any found to be using the algorithm that is about to go away are switched back to NewReno to avoid leaving dangling pointers which would trigger a panic. For VIMAGE kernels, there is a list per vnet to walk, yet the implementation was only examining one of the vnet lists.
Fix the implementation of the above feature for VIMAGE kernels by looping through all active TCP control blocks across all vnets.
Sponsored by: FreeBSD Foundation Tested by: Mikolaj Golub <to.my.trociny at gmail com> Reviewed by: bz (briefly) MFC after: 11 weeks
show more ...
|
#
14f57a8b |
| 16-Nov-2010 |
Lawrence Stewart <lstewart@FreeBSD.org> |
cc_init() should only be run once on system boot, but with VIMAGE kernels it runs on boot and each time a vnet jail is created. Running cc_init() multiple times results in a panic when attempting to
cc_init() should only be run once on system boot, but with VIMAGE kernels it runs on boot and each time a vnet jail is created. Running cc_init() multiple times results in a panic when attempting to initialise the cc_list lock again, and so r215166 effectively broke the use of vnet jails.
Switch to using a SYSINIT to run cc_init() on boot. CC algorithm modules loaded on boot register in the same SI_SUB_PROTO_IFATTACHDOMAIN category as is used in this patch, so cc_init() is run at SI_ORDER_FIRST to ensure the framework is initialised before module registration is attempted.
Sponsored by: FreeBSD Foundation Reported and tested by: Mikolaj Golub <to.my.trociny at gmail com> MFC after: 11 weeks X-MFC with: r215166
show more ...
|
#
5fbbc222 |
| 12-Nov-2010 |
Dimitry Andric <dim@FreeBSD.org> |
Sync: merge r215141 through r215188 from ^/head.
|
#
dbc42409 |
| 12-Nov-2010 |
Lawrence Stewart <lstewart@FreeBSD.org> |
This commit marks the first formal contribution of the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. More details about the project are available at: htt
This commit marks the first formal contribution of the "Five New TCP Congestion Control Algorithms for FreeBSD" FreeBSD Foundation funded project. More details about the project are available at: http://caia.swin.edu.au/freebsd/5cc/
- Add a KPI and supporting infrastructure to allow modular congestion control algorithms to be used in the net stack. Algorithms can maintain per-connection state if required, and connections maintain their own algorithm pointer, which allows different connections to concurrently use different algorithms. The TCP_CONGESTION socket option can be used with getsockopt()/setsockopt() to programmatically query or change the congestion control algorithm respectively from within an application at runtime.
- Integrate the framework with the TCP stack in as least intrusive a manner as possible. Care was also taken to develop the framework in a way that should allow integration with other congestion aware transport protocols (e.g. SCTP) in the future. The hope is that we will one day be able to share a single set of congestion control algorithm modules between all congestion aware transport protocols.
- Introduce a new congestion recovery (TF_CONGRECOVERY) state into the TCP stack and use it to decouple the meaning of recovery from a congestion event and recovery from packet loss (TF_FASTRECOVERY) a la RFC2581. ECN and delay based congestion control protocols don't generally need to recover from packet loss and need a different way to note a congestion recovery episode within the stack.
- Remove the net.inet.tcp.newreno sysctl, which simplifies some portions of code and ensures the stack always uses the appropriate mechanisms for recovering from packet loss during a congestion recovery episode.
- Extract the NewReno congestion control algorithm from the TCP stack and massage it into module form. NewReno is always built into the kernel and will remain the default algorithm for the forseeable future. Implementations of additional different algorithms will become available in the near future.
- Bump __FreeBSD_version to 900025 and note in UPDATING that rebuilding code that relies on the size of "struct tcpcb" is required.
Many thanks go to the Cisco University Research Program Fund at Community Foundation Silicon Valley and the FreeBSD Foundation. Their support of our work at the Centre for Advanced Internet Architectures, Swinburne University of Technology is greatly appreciated.
In collaboration with: David Hayes <dahayes at swin edu au> and Grenville Armitage <garmitage at swin edu au> Sponsored by: Cisco URP, FreeBSD Foundation Reviewed by: rpaulo Tested by: David Hayes (and many others over the years) MFC after: 3 months
show more ...
|