Merge remote-tracking branch 'upstream/master' into celeval_constructor
Iterate through policies and store CEL condition
git push origin ce Merge remote-tracking branch 'upstream/master' into celeval_constructor
added class and constructor comments for CelEvaluationEngine
CelEvaluationEngine class and constructor
Added cel_evaluation_engine to build
ran clang_tidy_code.sh
updated BUILD with cel_evaluation_engine
added rbac.upb.h/cc to BUILD
Rewrote cel_evaluation_engine code with upb conventions
removed unnecessary deps for cel_evaluation_engine in BUILD
Cel_evaluation_engine uses arenas to manage condition pointers
Used upb::Arena instead of upb_arena*, added temp_arena to save memory
Added action_allow_ member variable
Added fullstops to comments
initialize action_allow_
changed variable names to be more clear
removed unnecessary headers
correctly initialize the action_allow_ variable
changed constructor to use an initializer list
ran clang_tidy and clang_format scripts
added cel_engine_test
resolved merge conflicts and rewrote cel engine constructor to use new map api
changed variables to be more clear and made them const
changed syntax.upb.h so the build succeeds
changed syntax.upb.h so the build succeeds
changed version of upb in bazel_dpes
regenerated upb files with new upb version
added TODO regarding two-policy design
modified CelEvaluationEngine and tests to use two rbac policies
Made test messages consistent and added a case with too many policies
changed name from cel_engine to authorization_engine
fixed merge issues and updated authorization engine to v3 rbac
made constructor public and added namespace grpc_core
1) Statically pre-compute static slice indices to save some ALU ops when linking
batched metadata.
2) Change some asserts to debug_asserts since they can provably not be triggered
with the current implementation.
3) Save some slice comparison cycles inside CH2 parsing.
In several cases, we create grpc mdelem structures using known-static
metadata inputs. Furthermore, in several cases we create a slice on
the heap (e.g. grpc_slice_from_copied_buffer) where we know we are
transferring refcount ownership. In several cases, then, we can:
1) Avoid unnecessary ref/unref operations that are no-ops (for static
slices) or superfluous (if we're transferring ownership).
2) Avoid unnecessarily comprehensive calls to grpc_slice_eq (since
they'd only be called with static or interned slice arguments,
which by construction would have equal refcounts if they were
in fact equal.
3) Avoid unnecessary checks to see if a slice is interned (when we
know that they are).
To avoid polluting the internal API, we introduce the notion of
strongly-typed grpc_slice objects. We draw a distinction between
Internal (interned and static-storage) slices and Extern (inline and
non-statically allocated). We introduce overloads to
grpc_mdelem_create() and grpc_mdelem_from_slices() for the fastpath
cases identified above based on these slice types.
From the programmer's point of view, though, nothing changes - they
need only use grpc_mdelem_create() and grpc_mdelem_from_slices() as
before, and the appropriate fastpath will be picked based on type
inference. If no special knowledge exists for the slice type (i.e. we
pass in generic grpc_slice objects), the slowpath method will still
always return correct behaviour.
This is good for:
- Roughly 1-3% reduction in CPU time for several unary/streaming
ping pong fullstack microbenchmarks.
- Reduction of about 15-20% in CPU time for some hpack parser
microbenchmarks.
- 10-12% reduction of CPU time for metadata microbenchmarks involving
interned slice comparisons.
All these changes need to go together to make sense
- changes to use new version of upb in bazel
- allowing includes in build target option
- script for generating c code (upb) for protos
- generated code for example protos
- adding changes for non-bazel builds
- change sanity tests to ignore the generated files.
protos
All these changes need to go together to make sense
- changes to use new version of upb in bazel
- allowing includes in build target option
- script for generating c code for protos
- generated code for example build
- adding changes for non-bazel builds
- change sanity tests to ignore the generated files.
Ashitha Santhosh