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

http3: make quic/quiche core code #15720

Merged
merged 5 commits into from
Mar 29, 2021
Merged

http3: make quic/quiche core code #15720

merged 5 commits into from
Mar 29, 2021

Conversation

mattklein123
Copy link
Member

@mattklein123 mattklein123 commented Mar 26, 2021

Part of #12829. The transport
extension will stay a built-in extension since it fits well. UDP
listener and UDP writer extension points have been removed. GSO is
still only enabled for QUIC because it currently depends on QUICHE, has
some obvious perf issues, and is failing non-QUIC integration tests.
Futher work is needed to remove codec extension factories.

Risk Level: Low
Testing: Existing/modified tests
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

Part of #12829. The transport
extension will stay a built-in extension since it fits well. UDP
listener and UDP writer extension points have been removed. GSO is
still only enabled for QUIC because it currently depends on QUICHE, has
some obvious perf issues, and is failing non-QUIC integration tests.
Futher work is needed to remove codec extension factories.

Part of #12829

Signed-off-by: Matt Klein <[email protected]>
@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/envoy/.
API shepherd assignee is @markdroth
CC @envoyproxy/api-watchers: FYI only for changes made to api/envoy/.

🐱

Caused by: #15720 was opened by mattklein123.

see: more, trace.

@mattklein123
Copy link
Member Author

cc @moderation if you want to test this I believe this should allow you to compile out H3. There is some more cleanup work to do but let me know if that's not the case.

@mattklein123
Copy link
Member Author

I might have missed a few spots for fully compiling out. Will continue in the next follow up.

@moderation
Copy link
Contributor

@mattklein123 I can confirm that this allowed me to compile on Red Hat 8 with Clang 10. Thanks

@mattklein123
Copy link
Member Author

I believe the clang tidy issues are pre-existing. I will poke around a bit but my preference would be to merge this modulo any other PR comments, just to avoid merge conflicts.

Signed-off-by: Matt Klein <[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.

Awesome, thanks for tackling this.

source/common/quic/BUILD Show resolved Hide resolved
source/server/listener_manager_impl.cc Outdated Show resolved Hide resolved
@@ -1,7 +1,8 @@
#include <algorithm>
#include <memory>

#include "extensions/quic_listeners/quiche/envoy_quic_proof_verifier.h"
#include "common/quic/envoy_quic_proof_verifier.h"
Copy link
Contributor

Choose a reason for hiding this comment

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

so I'm all for QUIC being built in, but why the big file move? If we have TLS in extensions why not QUIC?
(I'm also happy with everything core being in core, but we have a bunch of other exceptions so I'd like to make sure we have a plan and maybe file a follow up issue for others)

Copy link
Member Author

Choose a reason for hiding this comment

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

The other things that are "core extensions" fall into 2 buckets today:

  1. TLS which is an extension because technically there is an openssl port out there.
  2. Extensions that actually are true extensions in terms of documentation, proto build, etc. but we force into the build because they are needed for core functionality (like admin server, etc.).

IMO QUIC doesn't fall into either of those categories which is why I moved the code. I just can't see any situation in which we will override the QUICHE code realistically.

test/common/quic/integration/BUILD Show resolved Hide resolved
@alyssawilk
Copy link
Contributor

Hey Matt, can you fold this into your mega PR:
https://github.com/envoyproxy/envoy/compare/main...alyssawilk:quic_upstream?expand=1
I'm also happy to send it out as a standalone but I figure it's easier for you to do it than deal with merge conflicts.

@moderation caught that Envoy currently doesn't do quic upstream because I didn't stick client_connection_factory_lib in the envoy select for the server build, I only included it in the integration tests.

@mattklein123
Copy link
Member Author

@moderation caught that Envoy currently doesn't do quic upstream because I didn't stick client_connection_factory_lib in the envoy select for the server build, I only included it in the integration tests.

Yeah I will merge that in. FYI I'm doing a follow up to this PR that will further clean all of the client/codec stuff up but we can have this in for now.

Signed-off-by: Matt Klein <[email protected]>
@mattklein123
Copy link
Member Author

@alyssawilk updated per comments

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 fine merging over clang tidy failures, as IMO there's no need to clean up all the things. I would suggest waiting for at least the other builds to pass as for example I wonder if "is_quic" is going to be 'unused' in opt mode.

cc @DavidSchinazi @danzh2010 as this is going to break everything we have in flight. Whee! =P

@@ -438,6 +438,7 @@ envoy_cc_library(
"@envoy_api//envoy/extensions/filters/listener/proxy_protocol/v3:pkg_cc_proto",
] + envoy_select_enable_http3([
"//source/common/quic:active_quic_listener_lib",
"//source/common/quic:client_connection_factory_lib",
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd like this removed from quic protocol test too in the hopes of future-proofing but I can do in one of my many quic PRS.

@@ -1022,7 +1022,9 @@ Network::DrainableFilterChainSharedPtr ListenerFilterChainFactoryBuilder::buildF
transport_socket.DebugString()));
}
#else
UNREFERENCED_PARAMETER(listener_);
// When QUIC is compiled out it should not be possible to configure either the QUIC transport
// socket or the QUIC listener and get to this point.
Copy link
Contributor

Choose a reason for hiding this comment

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

mind filing a tracking issue for upstream/downstream quic to have tests in the compile time options build that we fail gracefully if H3 is configured upstream/downstream while compiled out?

Copy link
Member Author

Choose a reason for hiding this comment

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

I made a note here: #12829 (comment)

I will work on this in the follow up PR I have ongoing to remove codec/client extension points for QUIC.

@mattklein123
Copy link
Member Author

I would suggest waiting for at least the other builds to pass as for example I wonder if "is_quic" is going to be 'unused' in opt mode.

I think the ASSERT macro handles this correctly but let's see. I will definitely wait for the builds to complete.

cc @DavidSchinazi @danzh2010 as this is going to break everything we have in flight. Whee! =P

Thank you for dealing with the pain!!!

@mattklein123 mattklein123 merged commit 8e8a21d into main Mar 29, 2021
@mattklein123 mattklein123 deleted the remove_quic_as_extension branch March 29, 2021 20:01
@PiotrSikora
Copy link
Contributor

FYI, this broke builds with --define boringssl=fips.

@ggreenway
Copy link
Contributor

FYI, this broke builds with --define boringssl=fips.

How did that pass CI? The compile_time_options build is compiled with boringssl=fips, and it looks like it passed.

@alyssawilk
Copy link
Contributor

alyssawilk commented Mar 30, 2021 via email

@PiotrSikora
Copy link
Contributor

FYI, this broke builds with --define boringssl=fips.

How did that pass CI? The compile_time_options build is compiled with boringssl=fips, and it looks like it passed.

I don't know, yet. I originally suspected compile_time_options passed because this PR added --@envoy//bazel:http3=False, but that doesn't seem to work for me.

@mattklein123
Copy link
Member Author

I will take a look and fix. I suspect also that fips with http3=False works, but not just fips.

@mattklein123
Copy link
Member Author

@PiotrSikora are you also passing --test_tag_filters=-nofips and --build_tag_filters=-nofips? I'm trying to figure clean this up further in #15752 but unfortunately this is not easy.

@mattklein123
Copy link
Member Author

I can confirm that bazel build //source/exe:envoy-static --define boringssl=fips --test_tag_filters=-nofips --build_tag_filters=-nofips is broken. I will try to fix it but as I said above I'm getting into a real bazel mess here.

@mattklein123
Copy link
Member Author

mattklein123 commented Mar 30, 2021

ubuntu@ip-10-1-0-68:~/Source/envoy$ git diff
diff --git a/bazel/BUILD b/bazel/BUILD
index 2cb2c4330..a0e97c5e8 100644
--- a/bazel/BUILD
+++ b/bazel/BUILD
@@ -363,6 +363,7 @@ config_setting(
     constraint_values = [
         "@bazel_tools//platforms:linux",
         "@bazel_tools//platforms:x86_64",
+        "disable_http3",
     ],
     values = {"define": "boringssl=fips"},
 )

At least makes this problem obvious, so I will add that to my other PR while I see if I can figure out something better.

Edit: nevermind that doesn't seem to work. Will keep poking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants