mctp-estack: Support vectored payloads in fragmenter

[embediver]

Add a method to fragment vectored payloads directly.

This eliminates the need to copy vectored payloads to a buffer that can hold the largest possible payload and instead copies the data directly to the packet buffer while fragmenting.

[mkj]

Thanks, it was on the todo list, good to avoid that buffer. fragment() can be replaced with a call to fragment_vectored() too.

[mkj]

There seems to be a lot of conversion back and forth between total length/offset and slice indices/offsets.

It might simplify the code to remove total_payload_len and payload_used, and instead store current input slice index and offset in Fragmenter? get_sub_slice() wouldn't be needed.

[embediver]

Was thinking something similar while implementing, but just continued bending the existing code until it worked to get a poc.

A "VectorReader" that holds the state and has all of the clean methods like read(), is_at_end(), ... could be nice.
I'll try to come up with something.

[embediver]

Worked out as I intended.
I'm happy how the Fragmenter looks now.
Maybe there are some nits how to make the reader implementation a bit cleaner, but finding the best way is hard with all the available stuff to access slices.

[mkj]

Thanks, that looks good.

[embediver]

Noticed, that my code was missing the check for eom to return success in that case.

All the tests seem to just check with is_done() instead of waiting for fragment() to return SendOutput::Complete.
Adding test coverage as a metric to CI and creating a tracking issue for improvements might be a reasonable thing to do.

[mkj]

All the tests seem to just check with is_done() instead of waiting for fragment() to return SendOutput::Complete. Adding test coverage as a metric to CI and creating a tracking issue for improvements might be a reasonable thing to do.

Yes, the better code coverage would certainly be worth adding. For checking locally I've been using cargo llvm-cov --html.

In this specific case I think it'd be difficult to notice that no tests match on SendOutput::Complete from looking at coverage - there isn't a particular function that would be missing coverage.