diff options
author | Aaron Rossetto <aaron.rossetto@ni.com> | 2021-05-25 13:57:55 -0500 |
---|---|---|
committer | michael-west <michael.west@ettus.com> | 2021-06-01 11:03:10 -0700 |
commit | c7c2f186b470c6cd02cd24c6d95f13758869859f (patch) | |
tree | e53ba6cfaaaa52131fd0c9100bdb8abbcbbcab32 /host/LICENSE | |
parent | 3b2814aa25fe5d396ebed004f686e8aca2c6ad6b (diff) | |
download | uhd-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/LICENSE')
0 files changed, 0 insertions, 0 deletions