Allow XdrAble to create it's own Xdr instance #64
Conversation
Signed-off-by: Pepijn Van Eeckhoudt <[email protected]>
|
Can one of the admins verify this patch? |
|
ok to test |
|
This is a nice idea. I has as well several attempts to make a composite Xdr to avoid extra copies. However every time failed to make it intuitive and nice. One option would be to have kind-of composite Xdr or converting a under laying into a composite buffer it large byte buffer is encoded. I will play around with your patch. Thanks! |
|
@pepijnve as a continuation of discussion, here is an alternative to your approach: In s simple test of encoding 64K byte buffer it's gives me x10 boost. But some real application test are required. I have updated you nfs server to see the difference. |
|
actually, in the real-life example I don't see any measurable differences. |
|
At what data rate are you testing? We're trying to saturate a 10GbE link in our lab... |
I ran into performance issues when generating large NFSv3 write requests. The data I want to send is already available in a ByteBuffer and I want to avoid having to copy the entire buffer.
This PR allows XdrAble implementations to optionally create an Xdr instance themselves. This enable gather-style writes where the final Xdr wraps a composite Grizzly buffer. For instance, in my prototype version of this PR, the nfs Write3Args is creating an Xdr wrapper around a composite buffer consisting of
<write3args header><data buffer><padding buffer>. This improved write performance quite a bit.Note that this PR is mainly to get a discussion started; there might be better ways to provide this functionality. This is just a first draft.