| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two values where being mixed up in the code. To summarize:
- The MTU is the max CHDR packet size, including header & timestamp.
- The max payload is the total number of bytes regular payload plus
metadata that can be fit into into a CHDR packet. It is strictly
smaller than the MTU. For example, for 64-bit CHDR widths, if
a timestamp is desired, the max payload is 16 bytes smaller than
the MTU.
The other issue was that we were using a magic constant (DEFAULT_SPP)
which was causing conflicts with MTUs and max payloads.
This constant was harmful in multiple ways:
- The explanatory comment was incorrect (it stated it would cap packets
to 1500 bytes, which it didn't)
- It imposed random, hardcoded values that interfered with an 'spp
discovery', i.e., the ability to derive a good spp value from MTUs
- The current value capped packet sizes to 8000 bytes CHDR packets, even
when we wanted to use bigger ones
This patch changes the following:
- noc_block_base now has improved docs for MTU, and additional APIs
(get_max_payload_size(), get_chdr_hdr_len()) which return the
current payload size given MTU and CHDR width, and the CHDR header
length.
- The internally used graph nodes for TX and RX streamers also get
equipped with the same new two API calls.
- The radio, siggen, and replay block all where doing different
calculations for their spp/ipp values. Now, they all use the max
payload value to calculate spp/ipp. Unit tests where adapted
accordingly. Usage of DEFAULT_SPP was removed.
- The replay block used a hardcoded 16 bytes for header lengths, which
was replaced by get_chdr_hdr_len()
- The TX and RX streamers where discarding the MTU value and using the
max payload size as the MTU, which then propagated throughout the
graph. Now, both values are stored and can be used where appropriate.
|
| |
|
|
|
|
|
| |
This provides every block controller with a copy of its CHDR width.
Note: mock blocks always get configured with a 64-bit CHDR width, to
retain API compatibility.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 073574e24, the MTU property resolver in `noc_block_base` was
refactored to make the resolver's output sensitivity list less
broad. The broadness was intentional as a consequence of allowing the
MTU forwarding policy to be changed at will, but had the unintended side
effect of being incompatible with certain RFNoC graph use cases. The
refactoring solved the issues, but added a new restriction that the MTU
forwarding policy could only be called once per instance of a NoC block.
Unfortunately, that refactoring introduced a bug. By moving the
registration of MTU resolvers to `set_mtu_forwarding_policy()`, no
resolvers would be added if the MTU forwarding policy was never changed
from the default of `DROP` (which is the case for the vast majority of
NoC blocks). However, the resolver had code that would run in the `DROP`
case to coerce the incoming MTU edge property to be the smaller of the
new value or the existing MTU value on that edge. With the resolvers
only getting added when the MTU forwarding policy is changed, this
coercion behavior would never execute, thus breaking a number of
devtests.
This commit ensures that the default coercion behavior is always present
regardless of whether the MTU forwarding policy is changed or not.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this commit, the MTU property resolver in noc_block_base had an
issue: for every MTU edge property (both input and output on each port)
on the block, the property resolver listed every other MTU edge property
in its output sensitivity list, regardless of whether or not the output
edge properties would ever be affected by the current MTU forwarding
policy. This breaks an inherent (and up until now, unwritten) contract
between a property resolver and UHD that only properties that can be
affected by the resolver should be included in the output sensitivity
list. The result of breaking the contract leads to errors being thrown
when committing an RFNoC graph in certain multi-channel use cases.
This commit refactors the MTU property resolver to use the MTU
forwarding policy to determine the correct set of edge properties to
include in the output sensitivity list. The change also introduces a new
restriction--the MTU forwarding policy may only be set once per instance
of a noc_block_base. Typically, a subclass implementing an RFNoC block
will call `set_mtu_forwarding_policy()` in its constructor to set a
custom MTU forwarding policy (if desired) and leave it untouched for the
lifetime of the block.
|
| |
|
|
|
| |
Note: template_lvbitx.{cpp,hpp} need to be excluded from the list of
files that clang-format gets applied against.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MTUs are now tracked through the framework for all childs of
noc_block_base. Every edge gets an 'mtu' property. MTU can be set and
get either through the prop API, or through new API calls (get_mtu(),
set_mtu()). It is also possible to create custom properties that depend
on the MTU by asking for a reference to the MTU property, and then
adding that to the input list of a property resolver.
The radio_control_impl includes a change in this commit where it sets
the spp based on the MTU.
Blocks can also set an MTU forwarding policy. The DDC block includes a
change in this commit that sets a forwarding policy of ONE_TO_ONE,
meaning that the MTU on an input edge is forwarded to the corresponding
output edge (but not the other edges, as with the tick rate).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During registration, blocks must now specify which clock they are using
for the timebase (i.e., for timed commands) and for the ctrlport (this
is used to determine the length of sleeps and polls). For example, the
X300 provides bus_clk and radio_clk; typically, the former is used for
the control port, and the latter for the timebase clock.
Another virtual clock is called "__graph__", and it means the clock is
derived from property propagation via the graph.
The actual clocks are provided by the mb_iface. It has two new API
calls: get_timebase_clock() and get_ctrlport_clock(), which take an
argument as to which clock exactly is requested. On block
initialization, those clock_iface objects are copied into the block
controller.
The get_tick_rate() API call for blocks now exclusively checks the
timebase clock_iface, and will no longer cache the current tick rate in
a separate _tick_rate member variable. Block controllers can't manually
modify the clock_iface, unless they also have access to the
mb_controller (like the radio block), and that mb_controller has
provided said access.
This commit also adds the clock selection API changes to the DDC block,
the Null block, and the default block.
|
| |
|
|
|
|
|
|
| |
On destruction, the rfnoc_graph will call shutdown() on all blocks. This
allows a safe de-initialization of blocks independent of the lifetime of
the noc_block_base::sptr.
Also adds the shutdown feature to null_block_control.
|
| | |
|
| |
|
|
|
| |
These args come from the framework, e.g., because the UHD session was
launched with them.
|
| |
|
|
| |
This allows blocks to reduce the number of actual, available ports.
|
| |
|
|
|
|
|
|
|
| |
The mb_controller is an interface to hardware-specific functions of the
motherboard. The API works in two ways:
- The user can request access to it, and thus interact directly with the
motherboard
- RFNoC blocks can request access to it, if they need to interact with
the motherboard themselves.
|
| |
|
|
|
|
|
|
|
|
|
| |
All noc_block_base derivatives are now plugged into the tick rate
system. Connected nodes can only have one tick rate among them. This
implies there is also only ever one tick rate per block.
set_tick_rate() is a protected API call which can be called by blocks
such as radio blocks to actually set a tick rate. Other blocks would
only ever read the tick rate, which is handled by the get_tick_rate()
API call.
|
| |
|
|
|
|
| |
- noc_block_base now has a ctor defined
- The registry stores factory functions to the individual Noc-Block
implementations
|
|
|
This is a parent class for all block controllers.
|
