Only one cpu can talk to virtio NIC directly (at least without
multiqueue), so other cpus receive packets from the one that drives
virtio and forward packets that need to be send back. This is done
by proxy net interface.
deleter::share() is causing massive amounts of allocation. First,
since usually a packet's deleter is not a shared_deleter, we need to
allocate that shared_deleter. Second, we need an external reference
count which requires yet another allocation.
Making reference counting part of the deleter class would solve both of
these problems, but we cannot easily do that, since users hold
std::unique_ptr<deleter> which is clearly not sharable.
We could do a massive s/unique_ptr/shared_ptr/ here, but that would have
the side effect of making sharing "too easy" - you simply copy the pointer.
We'd like to keep it explicit.
So to make the change easier, rename the existing unique_ptr<deleter> as
plain "deleter", whereas the old "deleter" becomes deleter::impl:
old name new name
-------- --------
deleter deleter::impl
unique_ptr<deleter> deleter
with exactly the same semantics. A later patch can then add explicit sharing.
Virtio net options:
--event-index arg (=on) Enable event_index feature (on / off)
By default, --event-index is enable. To disable, e.g.:
$ ./httpd --network-stack native --event-index off
With the current listen() -> future<connection> interface, if a new connection
is established before the connection handler is able to re-register for the
port, we have to drop the connection.
Fix by adding a queue for accepted connections, and switching to the more
standard listen() -> accept() -> future<connection> model.
This defines adapter classes for converting from the tcp<> class to the
abstractions that applications use.
Still very inefficient due to impedance mismatch between the data types used.