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 [email protected] https://listman.redhat.com/mailman/listinfo/libguestfs
