Build a 128-entry redirection table to select which cpu services which
packet, when we have more cores than queues (and thus need to dispatch
internally).
Add a --hw-queue-weight to control the relative weight of the hardware queue.
With a weight of 0, the core that services the hardware queue will not
process any packets; with a weight of 1 (default) it will process an equal
share of packets, compared to proxy queues.
Unlike tcp::tcb::send() and tcp::connection::send() which send tcp
packets associated with tcb, tcp::send() only send packets associated
without tcb. We have a bunch of send() functions, rename it to make the
code more readable.
Tested with tcp_server + client.go using iptables dropping <SYN,ACK> or
<FIN,ACK> on client side.
I verified that the SYN or FIN packet is retransmitted and the
connection is closed after N (currently 5) retries.
Tell all waiters that something bad happened and they should all go away.
Can be used only once; waiters should clean up and there must not be any
new waiters.
Run the build command directly in docker, using a shell function, instead
of opening a shell. Forward the user/group IDs so the build artifacts belong
to the user, not root.
When size > align, we simply call the small allocator with the provided size,
but that does not guarantee any alignment above the default.
Round the allocation size to the nearest power of two in that case, to
guarantee alignment.
rss_bits should be equal to the number of bits HW used in its RSS calculation.
Use dev_info.max_rx_queues if dev_info.reta_size is not available.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Library-imposed smart pointers, such as std::exception_ptr, may free on
a cpu other than the one they were allocated on. Unfortunately it is
impossible to wrap std::exception_ptr, since it interacts directly with the
stack unwinder.
Fix by allowing cross-cpu frees. It's a slow path, so do not abuse.
Calling state.get() will throw the exception instead of calling the function,
thus denying the called function the chance to deal with the exception.
Fix by constructing the future directly from state.
Currently we require that memory be freed on the same cpu it was allocated.
This does not impose difficulties on the user code, since our code is already
smp-unsafe, and so must use message-passing to run the destructor on the
origin cpu, so memory is naturally freed there as well.
However, library code does not run under our assumptions, specifically
std::exception_ptr, which we do transport across cores.
To support this use case, add low-performance support for cross-cpu frees,
using an atomic singly linked list per core.
It only supports -help at the moment. It is quite annoying to see:
$ ./httpd -h
terminate called after throwing an instance of
'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::unknown_option> >'
what(): unrecognised option '-h'
Aborted
Support both -h and --help.
