In GR3, forecast() was pretty closely tied to the backpressure based scheduler - give me the number of inputs you need based on producing this many outputs.
This is why in GR4, we got rid of it, and let the work() function handle forecasting on its own and returning INSUFFICIENT if it doesn't line up
But here is a case where forecasting could be useful:
Want to wrap the work function of a block generically so that it can run work on a PDU - the block is not designed for PDU specifically
Given an input size, we need to know how many outputs to produce and create that sized PDU as input to the work function
We can use relative_rate, then see what was produced, and adjust??
Bottom line is there is a tradeoff:
Want to make it easiest for the block developer
Want to not tie block impl into a specific scheduling paradigm
In GR3,
forecast()was pretty closely tied to the backpressure based scheduler - give me the number of inputs you need based on producing this many outputs.This is why in GR4, we got rid of it, and let the work() function handle forecasting on its own and returning INSUFFICIENT if it doesn't line up
But here is a case where forecasting could be useful:
Bottom line is there is a tradeoff:
Thoughts?