Skip to content

quiche: implement QuicClock interface#7028

Merged
htuch merged 6 commits intoenvoyproxy:masterfrom
danzh2010:envoyclock
May 28, 2019
Merged

quiche: implement QuicClock interface#7028
htuch merged 6 commits intoenvoyproxy:masterfrom
danzh2010:envoyclock

Conversation

@danzh2010
Copy link
Copy Markdown
Contributor

Implement QuicClock using Event::TimeSystem.
Currently implement ApproximateNow() as Now() because TimeSystem doesn't support approximate time.

Risk Level: low, not in use
Testing: added test/extentions/quic_listeners/quiche/platform:envoy_quic_clock_test
Part of #2557

danzh1989 added 3 commits May 17, 2019 17:16
Signed-off-by: Dan Zhang <danzh@google.com>
Signed-off-by: Dan Zhang <danzh@google.com>
Signed-off-by: Dan Zhang <danzh@google.com>
@danzh2010
Copy link
Copy Markdown
Contributor Author

/assign @wu-bin

wu-bin
wu-bin previously approved these changes May 22, 2019
Copy link
Copy Markdown
Contributor

@wu-bin wu-bin left a comment

Choose a reason for hiding this comment

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

LGTM minus some nits. Also, should we find a better place for this library? Maybe directly under source/extensions/quic_listeners, along with other integration code?


class EnvoyQuicClock : public quic::QuicClock {
public:
EnvoyQuicClock(Event::TimeSystem& time_system) : quic::QuicClock(), time_system_(time_system) {}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

quic::QuicClock() is not needed, it is called by default.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

removed

}

quic::QuicWallTime EnvoyQuicClock::WallNow() const {
return quic::QuicWallTime::FromUNIXMicroseconds(timePointToInt64(time_system_.systemTime()));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The standard says std::chrono::system_clock, the source of systemTime(), has a unspecified epoch, although

  • Most implementations already uses Unix epoch.
  • It will be Unix epoch from c++ 20.

So I guess this is fine in practice?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This is also the system time used by Envoy, so I guess it's okay. Plus Quic doesn't need to know the absolute time anyway.

quic::QuicWallTime WallNow() const override;

private:
template <typename T> int64_t timePointToInt64(std::chrono::time_point<T> time) const {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit: Suggest to rename to "MicrosecondsSinceEpoch".

Copy link
Copy Markdown
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: Dan Zhang <danzh@google.com>
@danzh2010
Copy link
Copy Markdown
Contributor Author

LGTM minus some nits. Also, should we find a better place for this library? Maybe directly under source/extensions/quic_listeners, along with other integration code?

QuicClock is part of quic API. So I think put EnvoyQuicClock under platform is fine too.

wu-bin
wu-bin previously approved these changes May 22, 2019

quic::QuicTime EnvoyQuicClock::Now() const {
return quic::QuicTime::Zero() + quic::QuicTime::Delta::FromMicroseconds(
microsecondsSinceEpoch(time_system_.monotonicTime()));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit: remove empty line.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

which line?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Sorry, it looked like there is an empty line between line 12 and 13, but it's not.

@danzh2010
Copy link
Copy Markdown
Contributor Author

/assign @alyssawilk


quic::QuicTime EnvoyQuicClock::ApproximateNow() const {
// This might be expensive as Dispatcher doesn't store approximate time_point.
return Now();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

worst case we can have a thread local alarm which latches time once per dispatcher loop.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

LibeventScheduler::onPrepare() is called each libevent loop. But there are some plumbing to pass the timestamp get from onPrepare() to TimeSystem. But it's doable, and can be an future improvement.

Event::TestRealTimeSystem time_system;
EnvoyQuicClock clock(time_system);
quic::QuicTime last_now = clock.Now();
for (int i = 0; i < 1e5; ++i) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

how long does this take? I'd think that lowering would be OK given many CI runs

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

//test/extensions/quic_listeners/quiche/platform:envoy_quic_clock_test PASSED in 0.8s
Is this ok?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'd still prefer to lower it - it's not a huge deal but it'll be longer running on asan and tsan and I think the gains are minimal.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

reduced it to 1000.

@danzh2010
Copy link
Copy Markdown
Contributor Author

/retest

@repokitteh-read-only
Copy link
Copy Markdown

🔨 rebuilding ci/circleci: docs (failed build)

🐱

Caused by: a #7028 (comment) was created by @danzh2010.

see: more, trace.

@danzh2010
Copy link
Copy Markdown
Contributor Author

/retest

@repokitteh-read-only
Copy link
Copy Markdown

🔨 rebuilding ci/circleci: docs (failed build)

🐱

Caused by: a #7028 (comment) was created by @danzh2010.

see: more, trace.

Copy link
Copy Markdown
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.

If you do a master merge I think you'll pick up the fix to the docs build.

Event::TestRealTimeSystem time_system;
EnvoyQuicClock clock(time_system);
quic::QuicTime last_now = clock.Now();
for (int i = 0; i < 1e5; ++i) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'd still prefer to lower it - it's not a huge deal but it'll be longer running on asan and tsan and I think the gains are minimal.

danzh1989 added 2 commits May 28, 2019 13:13
Signed-off-by: Dan Zhang <danzh@google.com>
Signed-off-by: Dan Zhang <danzh@google.com>
@htuch htuch merged commit 47d3a52 into envoyproxy:master May 28, 2019
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