Summary:
Change kDefaultZeroCopyThreshold to 0 to avoid a regression when using a buffer chain that exceeds 32K but each buffer is small.
Change the benchmark to set it's own threshold. Also use calloc vs malloc (in the benchmark only) to get around some weird kernel interaction on non zero copy enabled systems - 2 back to back tests report very different results.
Reviewed By: djwatson
Differential Revision:
D6112299
fbshipit-source-id:
3895d3ece2925c4626284ff364495708293edc3e
void setReadCB(ReadCallback* callback) override;
ReadCallback* getReadCallback() const override;
void setReadCB(ReadCallback* callback) override;
ReadCallback* getReadCallback() const override;
- static const size_t kDefaultZeroCopyThreshold = 32768; // 32KB
+ static const size_t kDefaultZeroCopyThreshold = 0;
bool setZeroCopy(bool enable);
bool getZeroCopy() const {
bool setZeroCopy(bool enable);
bool getZeroCopy() const {
+static constexpr auto const kZeroCopyThreshold = 4096;
+
class TestAsyncSocket {
public:
explicit TestAsyncSocket(
class TestAsyncSocket {
public:
explicit TestAsyncSocket(
zeroCopy_ = enable;
if (sock_) {
sock_->setZeroCopy(zeroCopy_);
zeroCopy_ = enable;
if (sock_) {
sock_->setZeroCopy(zeroCopy_);
+ if (zeroCopy_) {
+ sock_->setZeroCopyWriteChainThreshold(kZeroCopyThreshold);
+ }
+ // use calloc to make sure the memory is touched
+ // if the memory is just malloc'd, running the zeroCopyOn
+ // and the zeroCopyOff back to back on a system that does not support
+ // zerocopy leads to the second test being much slower
- folly::IOBuf::takeOwnership(::malloc(bufferSize_), bufferSize_);
+ folly::IOBuf::takeOwnership(::calloc(1, bufferSize_), bufferSize_);
if (sock_ && writeBuffer_) {
sock_->writeChain(
if (sock_ && writeBuffer_) {
sock_->writeChain(