This is taken verbatim from the ext_proc gRFC A102:
gRPC implementations should structure their xDS HTTP filter APIs such that the filter
has access to the serialized bytes of each message rather than the deserialized message,
to avoid the overhead of repeated serialization/deserialization on each message. In other
words, on the client side, the filters should run after the message is serialized, and on the
server side, the filters should run before the message is deserialized.
Currently, our xDS HTTP filters can wrap the stream implementation in the gRPC channel to override any of the stream functionality. But the SendMsg and RecvMsg methods accept protobuf structs and not serialized bytes of the message. The serialization is triggered only from the stream implementation in the gRPC channel:
|
hdr, data, payload, pf, err := prepareMsg(m, cs.codec, cs.compressorV0, cs.compressorV1, cs.cc.dopts.copts.BufferPool) |
This means that we incur additional serialization and deserialization costs for every message sent and received to/from the proc_server.
This is taken verbatim from the ext_proc gRFC A102:
Currently, our xDS HTTP filters can wrap the stream implementation in the gRPC channel to override any of the stream functionality. But the
SendMsgandRecvMsgmethods accept protobuf structs and not serialized bytes of the message. The serialization is triggered only from the stream implementation in the gRPC channel:grpc-go/stream.go
Line 958 in 9a130aa
This means that we incur additional serialization and deserialization costs for every message sent and received to/from the proc_server.