The NIC router used to handle each type of packet-stream signal with a distinct
method in the Interface class. However, merging those methods has advantages.
It ensures that sent packets that were already acknowledged by the counter side
are always released before handling received packets. This frees packet stream
memory which facilitates the potential allocation of response packets while
handling received packets. Furthermore, it simplifies the code and reduces the
number of entry points into the router.
This commit also removes the installation of signal handlers at packet streams
for events that are of no interest for the router (TX-ready-to-ack /
RX-ready-to-submit at NIC sessions and RX-ready-to-ack / TX-ready-to-submit at
Uplink sessions).
Fixes#4470
The driver falls in line with the previous 'legacy_wifi_drv' component
where the ported wireless LAN stack and device driver is encapsulated
in a library. This library in return is used by the 'Libc::Component'
providing the necessary environment for the 'wpa_supplicant'.
In constrast to the old driver a 'wifi' VFS plugin is in charge of
initalizing the 'Lx_kit::Env' prior to executing any static
constructors.
Fixes#4455.
Move 'linux-firmware' portion from 'dde_linux' into its own port,
while it is used by the upcoming new WLAN driver keep it in place
for the legacy one.
Issue #4455.
Various libraries, like libnl and wpa_driver_nl80211, used hardcoded
values for the interface index (ifindex) and name (ifname).
To accomdate the legacy as well as the upcoming new driver we add
functions to query these information where at least the index differs.
Issue #4455.
The location of the used 'source.list' file is hard-coded and will not
work when the ported driver is implemented as a shared library. For
this use-case provide means to set the location differently.
Issue #4455.
In case where the ported driver or protocol stack is executed from
an already managed environment, e.g. the libc, the execution
of the static constructors will be performed at the appropriate
time.
Issue #4455.
Whenever the nic_router encounters ARP requests on an interface
that does not have a valid IP config it will ignore them. However,
When increasing the verbosity of the component for diagnostic
purposes the resulting 'Bad network protocol' message is misleading.
Issue #4455.
* Test DHCP RENEW by the test client in the unmanaged variant.
* Add event IDs to log output of test client in order to prevent false positive
result in the managed variant.
* Let managed and unmanaged variant have separate string patterns for
'run_genode_until' because they already had different output and it will
differ even more as we don't want to test DHCP RENEW with the managed
variant.
* Delay first test client DHCP in order to fix unexpected sporadic initial IP
config.
* Remove some unnecessary code from the run script
Fixes#4460
The NIC router did update the IP config of a domain on a completed DHCP
REQUEST but not on completed DHCP RENEW or DHCP REBIND. Thus, it didn't adapt
to "real" DHCP servers (not NIC router servers) that got restarted with a
changed configuration by the means of RENEW/REBIND. The commit fixes this.
Note, that testing this is complicated as we don't have the necessary
infrastructure (we cannot simply use the DHCP server of the NIC router as this
would apply a link down/up sequence in order to let the client restart DHCP)
Ref #4460
After reverting unused ranges during allocator destruction
'_meta_data.free_empty_blocks' may lead to more unused ranges because
meta data blocks maybe freed where the meta data for the blocks is
managed by other meta data blocks. This leads to dangling allocation
warnings which are caused by meta data. Therefore, we call
'_revert_unused_ranges' and 'free_empty_blocks' until no more ranges
can be freed.
issue #4466
by using the io_mem RPC of the platform session instead of parsing the
bar resources manually. This commits avoids and breakage on systems where
the Intel graphic cards just uses 64bits with addresses above 4G.
Issue #4450
Compared to the bytewise memset, a wordwise memset (or even multi-word)
achieves a speedup of ~6.
On Zynq-7000/Cortex-A9:
317 MiB/s -> 2040 MiB/s
On base-linux x86_64:
3580 MiB/s -> 23700 MiB/s
genodelabs/genode#4456
Preloading a few cache lines ahead brings a significant speedup in
memcpy throughput. Note, the particular (optimal) value was empirically
determined on a Cortex-A9 (Zynq-7000) SoC @ 666Mhz. It is best combined
with L2 prefetching enabled (including double linefills and prefetch
offset 7). Yet, even without L2 prefetching this seems to be the sweet
spot.
genodelabs/genode#4456
The implementation is not in use any more. Furthermore, on typical ARM
cores such as the Cortex-A9, the cached read appears to be the
bottleneck rather than instruction density. On a Zynq-7000 SoC, the vfp
implementation performed significantly worse than the standard load/store
multiple implementation with preloading.
genodelabs/genode#4456
When executed on Linux, the test was impaired by the copy-on-write
optimisation since the source buffer was never initialised. By default,
Linux only maps a zeroed page until the first write access to the page
occurs. Since the source buffer was never written, the corresponding
page was always present in the physically-indexed data cache. In
consequence, the test merely measured write performance (similar to memset).
genodelabs/genode#4454
