Jaewan Park

> A brief overview of the approach that we would like to take is described here: [#5862 (comment)](https://github.com/grpc/grpc-go/pull/5862#issuecomment-1386243942). Once you get more familiar with the changes that would be needed...

@easwars > But, we would still not be able to accept the PR without multiple sync pools for different sized messages because this implementation has the same drawback as the...

@easwars > Also, we should think about a more comprehensive benchmarking plan for these changes Even though we are gating it behind a dial option, having some good benchmark data...

@easwars Would it be possible to consider releasing this in Milestone 1.54? The ETA is crucial information that would greatly benefit the performance of my project. I would appreciate it...

> I think the changes are mostly moving towards where we want it to be. Thanks for doing this. Thank you for taking the time to review my work! It's...

> In addition to the inline comments, there are no tests added in this PR. Let's make sure there's coverage for anything we add. I have added a test for...

> I think it would be useful to have a test at the gRPC API level.. Just something that does a few (10?) RPCs with a shared buffer pool used...

@dfawley Thank you for your review!

Thank you. We can certainly wait for @easwars to return for the final review. His insights would be valuable.

> Also, looks like there are some merge conflicts in the benchmark files. I would be OK to move them to separate PR as well, if that makes life easier....