Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modem cmux DCE #65955

Merged
merged 3 commits into from
Dec 8, 2023
Merged

Conversation

jheiskan81
Copy link
Contributor

@jheiskan81 jheiskan81 commented Nov 30, 2023

Modem cmux update

  • Added missing command and message handling for use existing modem CMUX for DCE role.
  • DCE CMUX connection can be now initialized from DTE side.

Modem test update

  • Added possibility for link 2 modem backend mock instance for validating P2P communication without any data stubbing.
  • Added unite test for for validate modem CMUX DTE & DCE role communication together.

@bjarki-andreasen
Copy link
Collaborator

Initial review is really promising, I will find time to review it in detail :)

Copy link
Collaborator

@bjarki-andreasen bjarki-andreasen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really like it, I want to discuss the flow control API, see my comment :)

* @return -EPIPE CMUX control channel is not open.
* @return -EALREADY Ongoing flow control request.
*/
int modem_cmux_flow_ctrl_set_asynch(struct modem_cmux *cmux, bool state);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you describe the usecase for this API? The CMUX instance has an RX buffer, if the RX buffer nears full, the CMUX instance should automatically disable flow IMO :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Main reason for this new API was that I try to test similar functionality than your unit test with stubbed. I was also wondering that 3GGP CMUX define flow control for / DLCI channel now all channels are active or disabled. Now both end could call it. It will disable or enable flow control at caller side and remote side.

Copy link
Collaborator

@bjarki-andreasen bjarki-andreasen Dec 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really not sold on the manual API...

The CMUX instance knows the state of all buffers, its TX buffer, the CMUX RX buffer, and every DLCI RX buffer. CMUX defines two types of flow control, the flow control messages FCOFF and FCON, and individual channel flow control through MSC. We know we need to disable flow control for all channels if the CMUX RX buffer nears full, and we know the same for each DLCI RX buffer, so we really should be handling it automatically from within the CMUX instance.

Flow control should probably be its own PR, or at least its own commit, and should be handled internally. Its the simplest and most scalable solution.

tests/subsys/modem/modem_cmux_pair/testcase.yaml Outdated Show resolved Hide resolved
tests/subsys/modem/modem_cmux_pair/src/main.c Outdated Show resolved Hide resolved
@jheiskan81 jheiskan81 force-pushed the modem_cmux_dce branch 2 times, most recently from dc52acf to b77808f Compare December 1, 2023 13:46
@jheiskan81
Copy link
Contributor Author

I update test with your comment's and added some extra verfify for test_modem_cmux_disconnect_connect_sync() and test_modem_cmux_dlci_close_open_sync() test cases for DCE.

@jheiskan81 jheiskan81 force-pushed the modem_cmux_dce branch 2 times, most recently from e21f323 to 1b54fc7 Compare December 1, 2023 18:01
Copy link
Collaborator

@bjarki-andreasen bjarki-andreasen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest you move flow control out into its own PR, it should be handled internally by CMUX. The DCE additions and test case look excellent :)

* @return -EPIPE CMUX control channel is not open.
* @return -EALREADY Ongoing flow control request.
*/
int modem_cmux_flow_ctrl_set_asynch(struct modem_cmux *cmux, bool state);
Copy link
Collaborator

@bjarki-andreasen bjarki-andreasen Dec 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really not sold on the manual API...

The CMUX instance knows the state of all buffers, its TX buffer, the CMUX RX buffer, and every DLCI RX buffer. CMUX defines two types of flow control, the flow control messages FCOFF and FCON, and individual channel flow control through MSC. We know we need to disable flow control for all channels if the CMUX RX buffer nears full, and we know the same for each DLCI RX buffer, so we really should be handling it automatically from within the CMUX instance.

Flow control should probably be its own PR, or at least its own commit, and should be handled internally. Its the simplest and most scalable solution.

@jheiskan81
Copy link
Contributor Author

@bjarki-trackunit Thanks for review. I remove Flow Control API and functionality. I have updated PR.

@bjarki-andreasen
Copy link
Collaborator

Nice, I will re-review later today

@bjarki-andreasen
Copy link
Collaborator

I will spend some time tomorrow as well, I'm fairly certain the changes to fcon and fcoff are not necessary, I will need to look more into it locally :)

@jheiskan81
Copy link
Contributor Author

@bjarki-trackunit Please review. I have put flow control to original format back.

Copy link
Collaborator

@bjarki-andreasen bjarki-andreasen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested the changes locally and it behaves as expected :) There is one spelling mistake, when that is fixed we are good to go :)

@@ -435,6 +446,40 @@ static void modem_cmux_on_control_frame_uih(struct modem_cmux *cmux)
}
}

static void modem_cmux_conect_response_transmit(struct modem_cmux *cmux)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be _connect_

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will be fix this after my bicycle ride. Thanks

Juha Heiskanen added 3 commits December 7, 2023 23:14
Added missing command and message handling for use existing
modem cmux for DCE role.
DCE CMUX connection can be now initialized from DTE side.

Signed-off-by: Juha Heiskanen <juha.heiskanen@nordicsemi.no>
Added possibility for link 2 modem mock instance for
validating P2P communication without any data stubbing.

Signed-off-by: Juha Heiskanen <juha.heiskanen@nordicsemi.no>
Added unite test for for validate modem CMUX DTE & DCE role
communication together.

Signed-off-by: Juha Heiskanen <juha.heiskanen@nordicsemi.no>
Copy link
Collaborator

@bjarki-andreasen bjarki-andreasen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work :)

@fabiobaltieri fabiobaltieri merged commit 34d4e50 into zephyrproject-rtos:main Dec 8, 2023
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants