diff options
author | Aaron Rossetto <aaron.rossetto@ni.com> | 2021-05-12 16:20:54 -0500 |
---|---|---|
committer | Aaron Rossetto <aaron.rossetto@ni.com> | 2021-05-18 09:15:22 -0500 |
commit | 073574e24c777afcab40205b506d76ab29aa2309 (patch) | |
tree | 194ffed897d551dc21358f80e6174c8f5c4d314a /host/CMakeLists.txt | |
parent | d44d8712437ba732ed593192aeab6f1501760c6e (diff) | |
download | uhd-073574e24c777afcab40205b506d76ab29aa2309.tar.gz uhd-073574e24c777afcab40205b506d76ab29aa2309.tar.bz2 uhd-073574e24c777afcab40205b506d76ab29aa2309.zip |
rfnoc: noc_block_base: Refactor MTU prop resolver
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.
Diffstat (limited to 'host/CMakeLists.txt')
0 files changed, 0 insertions, 0 deletions