aboutsummaryrefslogtreecommitdiffstats
path: root/host/include
diff options
context:
space:
mode:
authorAaron Rossetto <aaron.rossetto@ni.com>2021-05-25 13:57:55 -0500
committermichael-west <michael.west@ettus.com>2021-06-01 11:03:10 -0700
commitc7c2f186b470c6cd02cd24c6d95f13758869859f (patch)
treee53ba6cfaaaa52131fd0c9100bdb8abbcbbcab32 /host/include
parent3b2814aa25fe5d396ebed004f686e8aca2c6ad6b (diff)
downloaduhd-c7c2f186b470c6cd02cd24c6d95f13758869859f.tar.gz
uhd-c7c2f186b470c6cd02cd24c6d95f13758869859f.tar.bz2
uhd-c7c2f186b470c6cd02cd24c6d95f13758869859f.zip
rfnoc: Fix MTU prop resolver refactoring
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.
Diffstat (limited to 'host/include')
0 files changed, 0 insertions, 0 deletions