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

add a helper class for runtime-derived uint32 #16398

Merged
merged 10 commits into from
May 20, 2021

Conversation

WeavingGao
Copy link
Contributor

@WeavingGao WeavingGao commented May 8, 2021

Signed-off-by: gaoweiwen [email protected]

Envoy already has several runtime protobuf messages, such as RuntimeUInt32, RuntimePercent and RuntimeDouble. Each protobuf message has a corresponding C++ helper class to easily and safely obtain the runtime value, except for RuntimeUInt32. So this PR tries to add the missing helper class.

TODO(WeavingGao): use for #16392

Commit Message: helper class for RuntimeUInt32
Additional Description:
Risk Level: Low
Testing: Unit Test
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]

@WeavingGao WeavingGao changed the title add a helper class for runtime-derived uint32 (#16397) add a helper class for runtime-derived uint32 May 8, 2021
@WeavingGao
Copy link
Contributor Author

ready to be reviewed.

Copy link
Contributor

@antoniovicente antoniovicente left a comment

Choose a reason for hiding this comment

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

cc @tonya11en

Hey Tony, could you do a review pass on this code since you were involved in the implementation of the wrapper for doubles?

EXPECT_EQ(1024, test_uint32.value());

EXPECT_CALL(runtime_.snapshot_, getInteger("foo.bar", 99)).WillOnce(Return(1ull << 33));
EXPECT_EQ(0, test_uint32.value());
Copy link
Contributor

Choose a reason for hiding this comment

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

In cases where getInteger returns a value larger than uint32 max, should this mask the returned value down to 32 bits or return the default value? Consistency between the behavior of getDouble and getInteger for values larger than uint64 max suggest that we should return the default in this case.

https://github.com/envoyproxy/envoy/blob/main/source/common/runtime/runtime_impl.h#L104

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The default value is indeed more reasonable, I'll submit a commit to fix it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed in the latest commit. @antoniovicente

Copy link
Member

@tonya11en tonya11en left a comment

Choose a reason for hiding this comment

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

Just a minor comment, LG otherwise. Thanks!


uint32_t value() const {
uint64_t raw_value = runtime_.snapshot().getInteger(runtime_key_, default_value_);
return raw_value > std::numeric_limits<uint32_t>::max() ? default_value_
Copy link
Member

Choose a reason for hiding this comment

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

Can you please add an error or warning log (every ~1000 times or something along those lines) for when there is an invalid value parsed that causes a revert to the default value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This may introduce additional complexity. If we introduce additional variables to record the number of invalid parsing, this class will become thread-unsafe, making it either complicated or poor in performance.
I'm not sure if there are other solutions, I look forward to your suggestions.

Copy link
Member

Choose a reason for hiding this comment

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

I mean just put ENVOY_LOG_EVERY_POW_2() or ENVOY_LOG_EVERY_N() in a conditional instead of using that ternary operator. You don't need to get too clever here.

I would be genuinely surprised if that caused an appreciable decline in performance.

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 misunderstood what you meant before (embarrassing >_<). Now I understand your suggestion and submit a new commit.

uint64_t raw_value = runtime_.snapshot().getInteger(runtime_key_, default_value_);
if (raw_value > std::numeric_limits<uint32_t>::max()) {
ENVOY_LOG_EVERY_POW_2(warn,
"value:{} of {} is larger than uint32 max, return default instead",
Copy link
Member

Choose a reason for hiding this comment

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

Sorry one more-- can you mention in the message that it's a parsed runtime value and swap "return" for "returning".

It'll be good to go after that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure.

tonya11en
tonya11en previously approved these changes May 12, 2021
Copy link
Member

@tonya11en tonya11en left a comment

Choose a reason for hiding this comment

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

Thanks!

@WeavingGao
Copy link
Contributor Author

Could you please take a look since you had implemented a similar wrapper class and also have write access to merge. @alyssawilk

Copy link
Contributor

@alyssawilk alyssawilk left a comment

Choose a reason for hiding this comment

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

I'm happy to take a look, but I'm unclear on why we're landing this upstream if it's not being used. Maybe if you filled out the Pr description fields it would explain? I think largely if its not used in Envoy it's going to end up being cleaned up at some point.

@alyssawilk alyssawilk self-assigned this May 12, 2021
@WeavingGao
Copy link
Contributor Author

I'm happy to take a look, but I'm unclear on why we're landing this upstream if it's not being used. Maybe if you filled out the Pr description fields it would explain? I think largely if its not used in Envoy it's going to end up being cleaned up at some point.

When I tried to implement another feature (see #16392 ), I found that I need a RuntimeUInt32 helper class just like RuntimeDouble. I was going to implement the helper class in that PR, but I thought it was very general, so I submitted it in a separate PR. The helper class is not used currently, but the RuntimeUInt32 protobuf message does exists and any other place that uses this protobuf message can benefit from the helper class.

@tonya11en
Copy link
Member

@WeavingGao can you please update the description to include those details. This way other's don't have to fish through the comments to gather context.

@WeavingGao
Copy link
Contributor Author

WeavingGao commented May 16, 2021

@WeavingGao can you please update the description to include those details. This way other's don't have to fish through the comments to gather context.

I added some details in the PR description. @alyssawilk @tonya11en

Copy link
Contributor

@alyssawilk alyssawilk left a comment

Choose a reason for hiding this comment

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

Gotcha, thanks for the context.
I'd mildly prefer this land with the actual use in #16392, but if you'd prefer to land it separately how about a TODO(WeavingGao): use for #16392 just to make it clear it's not used yet, but what the plan is?

: runtime_key_(uint32_proto.runtime_key()), default_value_(uint32_proto.default_value()),
runtime_(runtime) {}

const std::string& runtimeKey() const { return runtime_key_; }
Copy link
Contributor

Choose a reason for hiding this comment

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

Mind adding a unit test for this?

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.

Signed-off-by: gaoweiwen <[email protected]>
Copy link
Contributor

@alyssawilk alyssawilk left a comment

Choose a reason for hiding this comment

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

lgtm modulo one nit - could you put the TODO in the code, rather than the PR description? Sorry that wasn't clear!

@alyssawilk alyssawilk merged commit 2174fd0 into envoyproxy:main May 20, 2021
leyao-daily pushed a commit to leyao-daily/envoy that referenced this pull request Sep 30, 2021
Adding runtime helper protobuf messages for RuntimeUInt32.
TODO(WeavingGao): use for 

Risk Level: Low
Testing: Unit Test
Docs Changes: N/A
Release Notes: N/A
part of envoyproxy#16392


Signed-off-by: gaoweiwen <[email protected]>
@WeavingGao WeavingGao deleted the runtime_proto branch October 18, 2021 09:59
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.

4 participants