This repository has been archived by the owner on Sep 7, 2020. It is now read-only.
[Refactor] Agent: single executable per radio #435
Assignees
Labels
Milestone
Comments
|
I think the first step should moving out the ap_manager thread out to monitor the process, and call it radio manager, which will have to classes inside it: ap_manager and monitor (I really consider to change its name to "measurment_manager"). second, make the son_slave be derived from btl instead of the backhaul_manager, and move out all parts of backhaul_manager that are not related to physical link establishment to the son_slave. third, make the master thread to be derived from btl instead of mrouter, and remove mrouter. I think that the backhaul manager should have a thread of its own since we don't want the agent to be blocked while waiting for some radio operation (like scanning). |
ghost
added
the
morantr
added a commit
that referenced
this issue
Feb 16, 2020
The "conf_initialized" is responsible for reading the common configurations only once as long there was no change in the operational state. Remove this flag because it solves some it causing some issues which the configuration is not being updated if there is no change in the operational flag on the platform manager and it allows removing a lot of irrelevant code which responsible on updating the bpl on the ifaces status. For now, we will read the common configuration twice but when we will move to unified agent, we will read it only once. See issue: #435 Signed-off-by: Moran Shoeg <[email protected]>
morantr
added a commit
that referenced
this issue
Feb 17, 2020
The "conf_initialized" is responsible for reading the common configurations only once as long there was no change in the operational state. Remove this flag because it solves some it causing some issues which the configuration is not being updated if there is no change in the operational flag on the platform manager and it allows removing a lot of irrelevant code which responsible on updating the bpl on the ifaces status. For now, we will read the common configuration twice but when we will move to unified agent, we will read it only once. See issue: #435 Signed-off-by: Moran Shoeg <[email protected]>
morantr
added a commit
that referenced
this issue
Mar 8, 2020
The controller needs to be able to add and remove the radio node from its database based on the data that is coming from the Topology Response message. Add dummy data on the wireless fronthaul interfaces in the tlvDeviceInformation which is in the Topology Response message. The reason that it is dummy values is that this is something that cannot be done at this moment because the MediaType field must be computed with information obtained through NL80211_CMD_GET_WIPHY command of DWPAL, which is currently not supported. See "Send standard NL80211 commands using DWPAL #782 The filled band data is based on the information we have about the band but it is not accurate. The fields ap_channel_bandwidth, ap_channel_center_frequency_index1 and ap_channel_center_frequency_index2 we could get (the bw for sure, the others not so sure), but it not worth it since it will require to create more internal messaging which will be deleted after moving to a unified Agent (#435). Signed-off-by: Moran Shoeg <[email protected]>
morantr
added a commit
that referenced
this issue
Mar 8, 2020
The controller needs to be able to add and remove the radio node from its database based on the data that is coming from the Topology Response message. Add dummy data on the wireless fronthaul interfaces in the tlvDeviceInformation which is in the Topology Response message. The reason that it is dummy values is that this is something that cannot be done at this moment because the MediaType field must be computed with information obtained through NL80211_CMD_GET_WIPHY command of DWPAL, which is currently not supported. See "Send standard NL80211 commands using DWPAL #782 The filled band data is based on the information we have about the band but it is not accurate. The fields ap_channel_bandwidth, ap_channel_center_frequency_index1 and ap_channel_center_frequency_index2 we could get (the bw for sure, the others not so sure), but it not worth it since it will require to create more internal messaging which will be deleted after moving to a unified Agent (#435). Signed-off-by: Moran Shoeg <[email protected]>
morantr
added a commit
that referenced
this issue
Mar 10, 2020
The controller needs to be able to add and remove the radio node from its database based on the data that is coming from the Topology Response message. Add dummy data on the wireless fronthaul interfaces in the tlvDeviceInformation which is in the Topology Response message. The reason that it is dummy values is that this is something that cannot be done at this moment because the MediaType field must be computed with information obtained through NL80211_CMD_GET_WIPHY command of DWPAL, which is currently not supported. See "Send standard NL80211 commands using DWPAL #782 The filled band data is based on the information we have about the band but it is not accurate. The fields ap_channel_bandwidth, ap_channel_center_frequency_index1 and ap_channel_center_frequency_index2 we could get (the bw for sure, the others not so sure), but it not worth it since it will require to create more internal messaging which will be deleted after moving to a unified Agent (#435). Signed-off-by: Moran Shoeg <[email protected]>
morantr
added a commit
that referenced
this issue
Mar 10, 2020
The controller needs to be able to add and remove the radio node from its database based on the data that is coming from the Topology Response message. Add dummy data on the wireless fronthaul interfaces in the tlvDeviceInformation which is in the Topology Response message. The reason that it is dummy values is that this is something that cannot be done at this moment because the MediaType field must be computed with information obtained through NL80211_CMD_GET_WIPHY command of DWPAL, which is currently not supported. See "Send standard NL80211 commands using DWPAL #782 The filled band data is based on the information we have about the band but it is not accurate. The fields ap_channel_bandwidth, ap_channel_center_frequency_index1 and ap_channel_center_frequency_index2 we could get (the bw for sure, the others not so sure), but it not worth it since it will require to create more internal messaging which will be deleted after moving to a unified Agent (#435). Signed-off-by: Moran Shoeg <[email protected]>
morantr
added a commit
that referenced
this issue
Mar 11, 2020
The controller needs to be able to add and remove the radio node from its database based on the data that is coming from the TOPOLOGY RESPONSE message. Add dummy data on the wireless fronthaul interfaces in the tlvDeviceInformation which is in the Topology Response message. The reason that it is dummy values is that this is something that cannot be done at this moment because the MediaType field must be computed with information obtained through NL80211_CMD_GET_WIPHY command of DWPAL, which is currently not supported. See "Send standard NL80211 commands using DWPAL #782 The filled band data is based on the information we have about the band but it is not accurate. The fields ap_channel_bandwidth, ap_channel_center_frequency_index1 and ap_channel_center_frequency_index2 we could get (the bw for sure, the others not so sure), but it not worth it since it will require to create more internal messaging which will be deleted after moving to a unified Agent (#435). Signed-off-by: Moran Shoeg <[email protected]>
morantr
added a commit
that referenced
this issue
Mar 12, 2020
The controller needs to be able to add and remove the radio node from its database based on the data that is coming from the TOPOLOGY RESPONSE message. Add dummy data on the wireless fronthaul interfaces in the tlvDeviceInformation which is in the Topology Response message. The reason that it is dummy values is that this is something that cannot be done at this moment because the MediaType field must be computed with information obtained through NL80211_CMD_GET_WIPHY command of DWPAL, which is currently not supported. See "Send standard NL80211 commands using DWPAL #782 The filled band data is based on the information we have about the band but it is not accurate. The fields ap_channel_bandwidth, ap_channel_center_frequency_index1 and ap_channel_center_frequency_index2 we could get (the bw for sure, the others not so sure), but it not worth it since it will require to create more internal messaging which will be deleted after moving to a unified Agent (#435). Signed-off-by: Moran Shoeg <[email protected]>
morantr
added a commit
that referenced
this issue
Mar 12, 2020
The controller needs to be able to add and remove the radio node from its database based on the data that is coming from the TOPOLOGY RESPONSE message. Add dummy data on the wireless fronthaul interfaces in the tlvDeviceInformation which is in the Topology Response message. The reason that it is dummy values is that this is something that cannot be done at this moment because the MediaType field must be computed with information obtained through NL80211_CMD_GET_WIPHY command of DWPAL, which is currently not supported. See "Send standard NL80211 commands using DWPAL #782 The filled band data is based on the information we have about the band but it is not accurate. The fields ap_channel_bandwidth, ap_channel_center_frequency_index1 and ap_channel_center_frequency_index2 we could get (the bw for sure, the others not so sure), but it not worth it since it will require to create more internal messaging which will be deleted after moving to a unified Agent (#435). Signed-off-by: Moran Shoeg <[email protected]>
morantr
added a commit
that referenced
this issue
Mar 12, 2020
The controller needs to be able to add and remove the radio node from its database based on the data that is coming from the TOPOLOGY RESPONSE message. Add dummy data on the wireless fronthaul interfaces in the tlvDeviceInformation which is in the Topology Response message. The reason that it is dummy values is that this is something that cannot be done at this moment because the MediaType field must be computed with information obtained through NL80211_CMD_GET_WIPHY command of DWPAL, which is currently not supported. See "Send standard NL80211 commands using DWPAL #782 The filled band data is based on the information we have about the band but it is not accurate. The fields ap_channel_bandwidth, ap_channel_center_frequency_index1 and ap_channel_center_frequency_index2 we could get (the bw for sure, the others not so sure), but it not worth it since it will require to create more internal messaging which will be deleted after moving to a unified Agent (#435). Signed-off-by: Moran Shoeg <[email protected]>
morantr
added a commit
that referenced
this issue
Mar 15, 2020
The controller needs to be able to add and remove the radio node from its database based on the data that is coming from the TOPOLOGY RESPONSE message. Add dummy data on the wireless fronthaul interfaces in the tlvDeviceInformation which is in the Topology Response message. The reason that it is dummy values is that this is something that cannot be done at this moment because the MediaType field must be computed with information obtained through NL80211_CMD_GET_WIPHY command of DWPAL, which is currently not supported. See "Send standard NL80211 commands using DWPAL #782 The filled band data is based on the information we have about the band but it is not accurate. The fields ap_channel_bandwidth, ap_channel_center_frequency_index1 and ap_channel_center_frequency_index2 we could get (the bw for sure, the others not so sure), but it not worth it since it will require to create more internal messaging which will be deleted after moving to a unified Agent (#435). Signed-off-by: Moran Shoeg <[email protected]>
arnout
pushed a commit
that referenced
this issue
Mar 16, 2020
The controller needs to be able to add and remove the radio node from its database based on the data that is coming from the TOPOLOGY RESPONSE message. Add dummy data on the wireless fronthaul interfaces in the tlvDeviceInformation which is in the Topology Response message. The reason that it is dummy values is that this is something that cannot be done at this moment because the MediaType field must be computed with information obtained through NL80211_CMD_GET_WIPHY command of DWPAL, which is currently not supported. See "Send standard NL80211 commands using DWPAL #782 The filled band data is based on the information we have about the band but it is not accurate. The fields ap_channel_bandwidth, ap_channel_center_frequency_index1 and ap_channel_center_frequency_index2 we could get (the bw for sure, the others not so sure), but it not worth it since it will require to create more internal messaging which will be deleted after moving to a unified Agent (#435). Signed-off-by: Moran Shoeg <[email protected]>
mergify bot
pushed a commit
that referenced
this issue
Mar 16, 2020
The controller needs to be able to add and remove the radio node from its database based on the data that is coming from the TOPOLOGY RESPONSE message. Add dummy data on the wireless fronthaul interfaces in the tlvDeviceInformation which is in the Topology Response message. The reason that it is dummy values is that this is something that cannot be done at this moment because the MediaType field must be computed with information obtained through NL80211_CMD_GET_WIPHY command of DWPAL, which is currently not supported. See "Send standard NL80211 commands using DWPAL #782 The filled band data is based on the information we have about the band but it is not accurate. The fields ap_channel_bandwidth, ap_channel_center_frequency_index1 and ap_channel_center_frequency_index2 we could get (the bw for sure, the others not so sure), but it not worth it since it will require to create more internal messaging which will be deleted after moving to a unified Agent (#435). Signed-off-by: Moran Shoeg <[email protected]>
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
The agent architecture is currently a bit weird. It has an agent process with a main thread that is mostly idle and a backhaul manager thread and a platform manager thread. Then for each radio, there is a separately forked slave, again with a main thread that is mostly idle, and a slave thread and an ap manager thread. Each slave again forks a separate monitor process.
This is too complicated.
In a first step, we want to merge the monitor into the slave, still as a separate thread.
In a second step, we want to connect the slaves directly to the bus. Currently, the backhaul manager is responsible for forwarding some 1905/map messages to the slaves, but they could just as well receive them directly.
In a third step, we want to reduce the number of threads. Since all these threads are listening to sockets, we can have just a single select that monitors all sockets. Only the platform manager may need a separate thread since it has to interact with the platform bus mainloop.
The text was updated successfully, but these errors were encountered: