This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
George Bosilca wrote:
> We (the folks at UTK) implemented a SCTP BTL. It's not yet in the
> trunk, but it will get there shortly. Instead of starting from
> scratch, it might be a good idea to start directly from there.
Thanks for the reply. This BTL would definitely be worth taking a look
at. Is there a preliminary copy of the source? If so, is there anyway I
could obtain it?
> To answer your question, the TCP BTL use a copy of the original iovec.
> After each write, this copy is modified in order to describe the next
> operation (i.e. some of the iovec removed and some pointers modified
> based on the return value of the write function).
I've seen this occurring in numerous gdb traces. I'm curious if anyone
has tried expanding the array of iovec's to handle large messages over
SCTP? Currently I'm copying the original iovec over and fragmenting the
data portion if it is over a certain size. The new series of iovecs are
then individually passed to writev(). There is probably a more elegant
solution and one in which the original frag pointer has knowledge of
what is going on.