You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the FDL can only deal with one upper-layer application. This is rather limiting for more complex usecases. The FDL should be designed to allow an arbitrary amount of applications to run ontop of it and somehow allocate resources between them fairly.
Thoughs:
We already have a conflict between low-priority message cycles and the GAP scan (currently the GAP scan always has priority).
When multiple applications are present, should their cycles be synchronized?
Is round-robin scheduling enough or do we need actual priority management?
The list of applications is passed at every poll step. A user could pass a different list on each cycle which would disrupt any state kept in the FDL driver. Need a collection type in between? How does access work, then?
Motivating Use-Cases:
Running a bus scan in addition to active DP communication.
Non-DP protocols alongside the DP master (e.g. an ethernet bridge, or a programming upload/download interface)
MPI communication alongside DP?
FMS?
The text was updated successfully, but these errors were encountered:
Basic multi-application FDL support was implemented in commit f644cf6 ("fdl: active: Implement multi application polling"). This already takes care of most things, there are only two edge-cases that are not entirely clean yet:
Priority of telegrams is not taken into consideration. One application does its full cycle before the next application gets a chance at high priority telegrams. In practice, this is fine, but it's not nice to have this delay present.
The GAP scan is not really integrated into the scheduling and always takes precedence over other low priority communication.
Right now the FDL can only deal with one upper-layer application. This is rather limiting for more complex usecases. The FDL should be designed to allow an arbitrary amount of applications to run ontop of it and somehow allocate resources between them fairly.
Thoughs:
Motivating Use-Cases:
The text was updated successfully, but these errors were encountered: