Zero copy for receive #222

ice1000 · 2018-08-25T21:33:16Z

This is not ready to merge yet, but I'm opening this PR so we can discuss changes related to #134 .

grpc-sys/src/lib.rs

ice1000 · 2018-08-25T22:55:57Z

I think the use of Option<MessageReader> in #134 should be eliminated. The only usage of passing None is

https://github.com/pingcap/grpc-rs/blob/8fff94905ca9bccc1875f7f5a9cae7d12aa17196/src/call/server.rs#L79

. Seems that we need some kind of MessageReader that reads nothing.

BusyJay · 2018-08-26T01:36:07Z

Why send another pull request? If you are going to "rework" somebody's pull request, better talk about it with the author first.

ice1000 · 2018-08-26T02:05:03Z

@BusyJay Because I cannot find you on Slack when I started work on this (I tried to, not once, because as you see I have some questions about your code).
@overvenus said you rarely respond to people online.

I opened this new PR because I consider #134 too old and it's completely diverse with the current master branch.

ice1000 · 2018-08-26T02:06:12Z

@BusyJay If you have any thoughts about this PR, don't hesitate to tell me now.

BusyJay · 2018-08-26T03:07:06Z

I'm not always online on weekend, better contact me on weekdays if you expect an instant response.

ice1000 · 2018-08-26T03:11:55Z

If you are going to "rework" somebody's pull request, better talk about it with the author first.

Now I'm talking to you. Do you have something to say? Or is it fine to continue this PR?

ice1000 · 2018-08-26T03:43:15Z

I have another question: none of the implemented functions of Read/BufRead for MessageReader are returning Errs. (Some seems to, say, read_to_end returns Err only when read returns Err, read returns Err only when fill_buf returns Err. I assumed these functions not to returning Err at all and you wrote them like that only to fit the interface's functions' type signatures. Then I provided *_directly versions for them. Is this proper? Have I missed anything? The old functions are not removed but changed implementations so there's backward compatibility.

c9ae7e9

BusyJay · 2018-08-26T03:52:12Z

Read and BufRead are traits from std library. MessageReader are only used to support serialization/deserialization, where both traits are commonly used. Implementing them by default makes it easier for people to write their own ser/de hooks.

ice1000 · 2018-08-26T06:06:10Z

This is basically done. PTAL @BusyJay @overvenus

ice1000

I have some questions, please review.

ice1000 · 2018-08-26T06:16:42Z

src/call/client.rs

        loop {
            if !self.read_done {
                if let Some(ref mut msg_f) = self.msg_f {
                    bytes = try_ready!(msg_f.poll());
-                    if bytes.is_none() {
+                    if bytes.empty {


I think I should make sure something here. IMO the expected behavior is:

bytes is created by MessageReader::default(), do read_done = true

bytes is created with recv_message

reads 0, do NOT read_done = true

reads non-0, do read_done = true

Because I want to reduce unnecessary Options but here I've changed the semantics and it's probably incorrect. Maybe I should still use Option here, but I'm just making sure.

Original code makes more sense to me. Option<MessageReader> is not the same as MessageReader. When Option<MessageReader> is None, it's not supposed to be read in the first place. Current implementation is easier to write bugs.

Because I want to reduce unnecessary Options ...

Does MessageReader::default() bring extra overhead compare to Options?

@overvenus No, I've added a bool to mark whether it's created as default, so MessageReader::default() is different from a zero-sized result of recv_message

ice1000 · 2018-08-26T06:17:24Z

src/call/client.rs

@@ -422,8 +428,8 @@ impl<H: ShareCallHolder, T> ResponseStreamImpl<H, T> {
            self.msg_f.take();
            let msg_f = self.call.call(|c| c.call.start_recv_message())?;
            self.msg_f = Some(msg_f);
-            if let Some(ref data) = bytes {
-                let msg = (self.resp_de)(data)?;
+            if !bytes.empty {


src/call/mod.rs

ice1000 · 2018-08-26T06:25:17Z

Only one test under nightly is not passed, please tell me what have I done wrong. All tests pass locally.

src/call/mod.rs

ice1000 · 2018-08-28T18:48:03Z

Fixed, PTAL @BusyJay @overvenus

ice1000

@BusyJay @overvenus I still have some questions

src/call/client.rs

src/call/server.rs

siddontang · 2018-08-28T23:20:59Z

em, any different with origin PR #134 now?

ice1000 · 2018-08-29T02:06:54Z

@siddontang no. I thought there can be some improvements but now not. And PTAL my questions above.

ice1000

I have another question to @BusyJay . This PR is currently just a migrated version of #134 created by you, and I'm doubting that whether #134 is actually reduce copying.

src/call/mod.rs

ice1000 · 2018-08-29T04:45:39Z

The ideal approach is to use the C++ memory directly, which is not present in #134 . Am I expected to achieve that, or keep the current implementation? (Cus it can be lazily read now and it's better than in-place copy)

ice1000 · 2018-08-29T05:04:51Z

And since the destruction of MessageReader is done in Drop::drop, does that mean we can actually read the data without copying if we only call fill_buf_directly without read_directly or read_to_end_directly?

BusyJay · 2018-08-29T05:20:44Z

The ideal approach is to use the C++ memory directly, which is not present in #134 .

That's not true. #134 supports this via BufRead trait.

does that mean we can actually read the data without copying if we only call fill_buf_directly without read_directly or read_to_end_directly?

That's the expected behavior when someone want to achieve zero copy.

When people want a continuous slice, then zero copy is nearly impossible as the underlying buffer is hardly continuous. For such case, Read is the trait they want to use. If they are OK with several byte chunks, then they can use BufRead to get what they want.

ice1000 · 2018-08-29T13:15:10Z

Information get. That looks good

ice1000 · 2018-09-01T22:20:07Z

I've found a lot of C# codes in the submodule, are they used in this project?

src/call/mod.rs

ice1000

@BusyJay @overvenus PTAL

src/call/mod.rs

grpc-sys/src/lib.rs

grpc-sys/grpc_wrap.c

src/call/mod.rs

grpc-sys/grpc_wrap.c

(resolved)

ice1000 · 2018-09-03T16:05:02Z

@kennytm https://travis-ci.org/pingcap/grpc-rs/jobs/423982678#L586-L626

ice1000 · 2018-10-09T16:56:24Z

@kennytm @hicqu @overvenus PTAL

overvenus · 2018-10-10T02:59:54Z

grpc-sys/grpc_wrap.cc

@@ -858,3 +836,18 @@ grpcwrap_ssl_server_credentials_create(
 }

 #endif
+
+/* Sanity check for complicated types */
+//#define alignof(type)((size_t) & ((struct {char c; type d; } *) 0)->d)


Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

siddontang · 2018-10-10T05:53:35Z

seem zero has no any big difference in unary_qps_unconstrained? @overvenus

kennytm

Rest LGTM I guess 🙃

kennytm · 2018-10-10T08:10:19Z

src/call/mod.rs

+    // Hack: apparently its lifetime depends on `self.slice`. However
+    // it's not going to be accessed by others directly, hence it's safe
+    // to mark it static here.
+    bytes: &'static [u8],


Will MessageReader ever be moved? If bytes refer to an inlined GrpcSlice this would point to an invalid location?

Reasonable. I'll take a look at it soon but friendly ping @BusyJay here

In fill_buf (zero copy read), the self.bytes is returned a borrowed value. Once the MessageReader gets moved, you will no longer ba able to access this returned value, so it becomes invalid and inaccessible. By the way it's expected to call consume each time before fill_buf, it's rather safe in actual usage. Otherwise I expect a segfault (how can we check for that circumstance?).

@kennytm Ping

@ice1000 At the minimum please add the explanation in the code.

Also, this should be possible without the unsafe hack, by eliminating the self-reference:

you could separate MessageReader into two types:

struct MessageBuffer { buf: *mut GrpcByteBuffer, slice: Option<GrpcSlice>, } struct MessageReader<'b> { // <-- note lifetime buf: &'b mut MessageBuffer, bytes: &'b [u8], length: usize, }

however this probably involves a lot of plumbing to push through this extra lifetime

alternatively, you could record the offset instead

struct MessageReader { buf: *mut GrpcByteBuffer, slice: Option<GrpcSlice>, offset: usize, capacity: usize, length: usize, }

and change all references to self.bytes into slice::from_raw_parts(GRPC_SLICE_START_PTR(slice) + offset, capacity - offset). This might cause a little overhead.

The point is that, by removing these lifetime-related unsafe code, we don't need to manually verify when the MessageReader becomes inaccessible or needs a human to check the consume → fill_buf order (which is error prone), the compiler itself can assure us these wrong usages will not cause big troubles (panic instead of segfault in the worst case).

What I meant was entirely remove the bytes field 🙂

@kennytm No, you can't. consume.

@ice1000 That's why I said you record the offset in #222 (comment). consume will bump the offset.

How reasonable

Applied a patch provided by @overvenus , slightly modified to improve readability. This should be fixed by the coming commit.

Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

… readable) Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

kennytm · 2018-10-18T04:25:17Z

LGTM. The CI is failing though (missing an unsafe block and some formatting issue).

Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

ice1000 · 2018-10-18T04:32:42Z

Fixed. BTW cargo fmt is not displaying anything locally.

hicqu · 2018-10-18T11:35:14Z

LGTM.

Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

ice1000 · 2018-10-19T06:13:34Z

I've finally fixed all the formatting issues from https://travis-ci.org/pingcap/grpc-rs/jobs/443011498

ice1000 · 2018-10-19T06:13:59Z

Oh no!

😭

overvenus · 2018-10-19T08:24:11Z

Thank you! It finally lands on grpc-rs.

ice1000 commented Aug 25, 2018

View reviewed changes

grpc-sys/src/lib.rs Show resolved Hide resolved

ice1000 commented Aug 26, 2018

View reviewed changes

BusyJay reviewed Aug 27, 2018

View reviewed changes

src/call/mod.rs Outdated Show resolved Hide resolved

ice1000 commented Aug 28, 2018

View reviewed changes

src/call/client.rs Show resolved Hide resolved

src/call/client.rs Outdated Show resolved Hide resolved

src/call/server.rs Outdated Show resolved Hide resolved

ice1000 commented Aug 29, 2018

View reviewed changes

src/call/mod.rs Show resolved Hide resolved

src/call/mod.rs Show resolved Hide resolved

siddontang reviewed Sep 2, 2018

View reviewed changes

src/call/mod.rs Outdated Show resolved Hide resolved

ice1000 commented Sep 3, 2018

View reviewed changes

src/call/mod.rs Outdated Show resolved Hide resolved

kennytm previously requested changes Sep 3, 2018

View reviewed changes

grpc-sys/src/lib.rs Outdated Show resolved Hide resolved

overvenus reviewed Sep 3, 2018

View reviewed changes

grpc-sys/grpc_wrap.c Outdated Show resolved Hide resolved

src/call/mod.rs Outdated Show resolved Hide resolved

src/call/mod.rs Outdated Show resolved Hide resolved

grpc-sys/grpc_wrap.c Outdated Show resolved Hide resolved

ice1000 closed this Sep 3, 2018

Merge remote-tracking branch 'pingcap/master'

9ab6d70

overvenus reviewed Oct 10, 2018

View reviewed changes

Address comment

e012efa

Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

overvenus previously approved these changes Oct 10, 2018

View reviewed changes

ice1000 self-assigned this Oct 10, 2018

ice1000 added the Enhancement label Oct 10, 2018

kennytm reviewed Oct 10, 2018

View reviewed changes

ice1000 added 2 commits October 10, 2018 09:51

Merge remote-tracking branch 'pingcap/master'

093e99e

Fix CI (formatting

769e06b

Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

ice1000 dismissed overvenus’s stale review via 769e06b October 12, 2018 04:12

overvenus mentioned this pull request Oct 13, 2018

Zero copy for send #238

Closed

7 tasks

ice1000 added 4 commits October 13, 2018 14:13

Merge remote-tracking branch 'pingcap/master'

1f993d0

Address comment

c0654e4

Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

Run cargo fmt (it's finally working on my computer)

d5570e6

Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

Address comment (Applied a patch by @overvenus, refactored to be more…

729470e

… readable) Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

Fix compilation

cd1d66b

Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

hicqu previously approved these changes Oct 18, 2018

View reviewed changes

Fix formatting issues

dd1afec

Signed-off-by: ice1000 <ice1000kotlin@foxmail.com>

ice1000 dismissed hicqu’s stale review via dd1afec October 19, 2018 06:13

overvenus approved these changes Oct 19, 2018

View reviewed changes

overvenus merged commit c93d7d4 into tikv:master Oct 19, 2018

ice1000 mentioned this pull request Oct 29, 2018

Created a wrapper for GrpcSlice and GrpcByteBuffer #252

Merged

Zero copy for receive #222

Zero copy for receive #222

Conversation

ice1000 commented Aug 25, 2018

ice1000 commented Aug 25, 2018

BusyJay commented Aug 26, 2018

ice1000 commented Aug 26, 2018

ice1000 commented Aug 26, 2018

BusyJay commented Aug 26, 2018

ice1000 commented Aug 26, 2018 • edited

ice1000 commented Aug 26, 2018

BusyJay commented Aug 26, 2018

ice1000 commented Aug 26, 2018

ice1000 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ice1000 commented Aug 26, 2018

ice1000 commented Aug 28, 2018

ice1000 left a comment

Choose a reason for hiding this comment

siddontang commented Aug 28, 2018

ice1000 commented Aug 29, 2018

ice1000 left a comment

Choose a reason for hiding this comment

ice1000 commented Aug 29, 2018

ice1000 commented Aug 29, 2018

BusyJay commented Aug 29, 2018

ice1000 commented Aug 29, 2018

ice1000 commented Sep 1, 2018

ice1000 left a comment

Choose a reason for hiding this comment

ice1000 commented Sep 3, 2018

ice1000 commented Oct 9, 2018

Choose a reason for hiding this comment

siddontang commented Oct 10, 2018

kennytm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kennytm commented Oct 18, 2018

ice1000 commented Oct 18, 2018

hicqu commented Oct 18, 2018

ice1000 commented Oct 19, 2018

ice1000 commented Oct 19, 2018

overvenus commented Oct 19, 2018

ice1000 commented Aug 26, 2018 •

edited