[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libguestfs
Subject:    Re: [Libguestfs] nbdcpy: from scratch nbdcopy using io_uring
From:       Abhay Raj Singh <rathod.sahaab () gmail ! com>
Date:       2021-08-25 18:43:48
Message-ID: CAAXt=1DZADG9WBezmDSTS6Miht4_OeGiSjX6eo_R3cjvkfFnPQ () mail ! gmail ! com
[Download RAW message or body]

Thanks, sir, the suggestions were very insightful.

> For that matter is there a benefit to having cache-line-optimized
> sizing, where all headers are exactly 32 bytes (both requests and
> responses, and both simple and structured replies)?  I'm thinking
> maybe NBD_OPT_FIXED_SIZE_HEADER might be a sane name for such an
> option.
>
32-bytes sound good also you mentioned about upgrading length field
from the current 32 bits to 64 bits, which will increase the size of
RequestHeaderfrom 28 to 32 bytes, also we currently need to add
__attribute__((__packed__)) to request header(for x64 at least) which
is not best thing for speed.

So, if I understand it correctly I need to implement this in nbdkit
too to make it work.

I gave the idea a bit more thought and I think there will be a sweet
spot for how large our NBD packets should be as
1. The small payloads (<1MB) might help us process more packets hence
should be better for a large buffer
2. But more packets might stress our NBD state machine causing it to
be more CPU intensive, however, that might not be very significant but
just putting it out there.

Anyways this is a bit different from my previous approach so I need to
redesign nbdcpy, to make it wait some time to collect packets before
reading. I will update on further developments.

Thanks & Regards,
Abhay

_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs

[prev in list] [next in list] [prev in thread] [next in thread]