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

[rpc] Implemented rpc logging #10967

Merged
merged 1 commit into from
May 5, 2022
Merged

[rpc] Implemented rpc logging #10967

merged 1 commit into from
May 5, 2022

Conversation

mkatanbaf
Copy link
Contributor

@mkatanbaf mkatanbaf commented Apr 11, 2022

This adds logging to rpc communications, by adding a wrapper around "RPCChannel". The wrapper, "RPCChannelLogging", has a "NanoRPCListener" that only listens to ongoing communication and log them in a human readable way. "NanoRPCListener" uses a "MinRPCSniffer" to decode the rpc commands. "MinRPCSniffer" is based on "MinRPCServer" and shares the same code to decode the packets, but replaces the execution and return handling with no-operation functions. The log is disabled by default for backward compatibility, and a test case ("test_rpc_simple_wlog") is added to the "test_runtime_rpc.py" with logging enabled.

@mehrdadh mehrdadh self-assigned this Apr 11, 2022
@mkatanbaf mkatanbaf marked this pull request as ready for review April 13, 2022 22:18
@mkatanbaf mkatanbaf force-pushed the rpc_logger branch 4 times, most recently from 6ff5271 to b3a00c5 Compare April 14, 2022 20:53
Copy link
Contributor

@kparzysz-quic kparzysz-quic left a comment

Choose a reason for hiding this comment

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

This is looking pretty good, but there is one more issue.

Comment on lines 588 to 589
ret_handler_(new MinRPCReturns<TIOHandler>(io_)),
exec_handler_(new MinRPCExecute<TIOHandler>(io_, ret_handler_)) {}
Copy link
Contributor

Choose a reason for hiding this comment

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

These two members are allocated, but never deleted. In the logging classes you pass addresses of members to the MinRPCServer constructor, so it doesn't have a way of knowing whether it should delete these objects or not. This needs to be fixed or it will cause memory leaks.

Copy link
Contributor Author

@mkatanbaf mkatanbaf Apr 20, 2022

Choose a reason for hiding this comment

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

Thank you very much for taking the time to read through the code, and for valuable comments.
Initially, I wanted to address this using unique_ptrs, but including "memory" resulted in "redefinition of operator new" error in rpc_server.cc. So, I simply use the "ret_handler_" variable as a flag to infer which constructor is used, and delete the allocated variables when needed.

Copy link
Contributor

Choose a reason for hiding this comment

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

ah i see. i think we could likely remove operator new in rpc_server.cc if it's defined in . it's been long enough that I don't remember why i needed to explicitly override that anyhow--i do think though that we should verify by testing on Zephyr/Arduino to make sure behaves the same way there.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this needs a better solution---where the object ownership is fixed, i.e. either this class owns these objects or not. This will need a few more changes to the code creating objects of this class. I'm not sure what solution is the best for this, though.

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 changed the implementation to use smart pointer for exec_handler_, I hope that addresses the object ownership concern.

Copy link
Contributor

@areusch areusch left a comment

Choose a reason for hiding this comment

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

thanks @mkatanbaf ! i have a few suggestions around the overall interface, mainly fixes to arguments/names and the way things are passed around to remove reinterpret_casts. otherwise this all looks pretty good.

it would be nice to find a way to test the logger output. right now i think we could merge without that explicitly, since we at least have a test that it doesn't crash, though.

@@ -505,7 +508,7 @@ def connect(url, port, key="", session_timeout=0, session_constructor_args=None)
client_via_proxy = rpc.connect(
proxy_server_url, proxy_server_port, proxy_server_key,
session_constructor_args=[
"rpc.Connect", internal_url, internal_port, internal_key])
"rpc.Connect", internal_url, internal_port, internal_key, enable_logging])
Copy link
Contributor

Choose a reason for hiding this comment

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

i think here you mean

Suggested change
"rpc.Connect", internal_url, internal_port, internal_key, enable_logging])
"rpc.Connect", internal_url, internal_port, internal_key],
enable_logging=True)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure if I understand your comment. This is not a function call, it's a list of parameters that would later pass to rpc.Connect on the device. so, I believe we cannot write down the param_name=value, it only has to be the value.

class MinRPCExecuteWithLog : public ExecInterface {
public:
explicit MinRPCExecuteWithLog(ExecInterface* next) : next_(next) {
ret_handler_ = reinterpret_cast<MinRPCReturnsWithLog*>(next_->GetReturnInterface());
Copy link
Contributor

Choose a reason for hiding this comment

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

since this is the logging version of the ExecInterface, it's reasonable that the constructor should explicitly take a Logger*. i think you could add that argument here and that would remove the need to reinterpret_cast here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done, but I still need to keep the reinterpret_cast, to access functions such as GetHandleName, UpdateHandleName, ...


if ((*tcodes)[i] == kTVMStr) {
if (strlen((*values)[i].v_str) > 0) {
ret_handler_->UpdateCurrHandleName((*values)[i].v_str);
Copy link
Contributor

Choose a reason for hiding this comment

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

i think this is specific to ModuleGetFunction and GetGlobalFunc and CallFunc, right?

Copy link
Contributor Author

@mkatanbaf mkatanbaf Apr 29, 2022

Choose a reason for hiding this comment

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

As we talked, I kept the code as is for the moment (i.e. it adds all the strings in parameters to the handle name). In future we can change it once we have a better vision of what should or should not be logged.

@mkatanbaf mkatanbaf force-pushed the rpc_logger branch 2 times, most recently from 3759a62 to 5fcf577 Compare April 30, 2022 02:08
Copy link
Contributor

@areusch areusch left a comment

Choose a reason for hiding this comment

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

thanks @mkatanbaf, i think just one last minor (but probably important to address) thing and then this is ready to go

Copy link
Contributor

@areusch areusch left a comment

Choose a reason for hiding this comment

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

@kparzysz-quic do you want to take another look?

Copy link
Contributor

@kparzysz-quic kparzysz-quic left a comment

Choose a reason for hiding this comment

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

LGTM, thanks!

@mehrdadh mehrdadh merged commit aa3bcd9 into apache:main May 5, 2022
@mehrdadh
Copy link
Member

mehrdadh commented May 5, 2022

Thanks @mkatanbaf @areusch @kparzysz-quic @alanmacd! This PR is merged now.

leandron added a commit to leandron/tvm that referenced this pull request May 6, 2022
This reverts commit aa3bcd9, because it
fails on Windows CI as reported in issue apache#11220. PR apache#11223 tries to address
it but is is failing in the regular CI with testing issue on Hexagon.
manupak pushed a commit that referenced this pull request May 6, 2022
This reverts commit aa3bcd9, because it
fails on Windows CI as reported in issue #11220. PR #11223 tries to address
it but is is failing in the regular CI with testing issue on Hexagon.
shtinsa pushed a commit to Deelvin/tvm that referenced this pull request May 17, 2022
Co-authored-by: Mohamad <mkatanbaf@users.noreply.github.com>
shtinsa pushed a commit to Deelvin/tvm that referenced this pull request May 17, 2022
This reverts commit aa3bcd9, because it
fails on Windows CI as reported in issue apache#11220. PR apache#11223 tries to address
it but is is failing in the regular CI with testing issue on Hexagon.
SebastianBoblest pushed a commit to SebastianBoblest/tvm that referenced this pull request May 27, 2022
Co-authored-by: Mohamad <mkatanbaf@users.noreply.github.com>
SebastianBoblest pushed a commit to SebastianBoblest/tvm that referenced this pull request May 27, 2022
This reverts commit aa3bcd9, because it
fails on Windows CI as reported in issue apache#11220. PR apache#11223 tries to address
it but is is failing in the regular CI with testing issue on Hexagon.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants