>> Hi all,
>> 
>> I have one question on the behavior of TCP/IPv4 sending using the 
>> MSG_ZEROCOPY flag,
>> the kernel version is 4.19.18.
>> 
>> What happens if I close the sending socket immediately after performing a 
>> socket
>> send() or sendmsg() call (called with the MSG_ZEROCOPY flag)?
>> I.e. in this situation not all messages have been sent yet, however - as the
>> socket is closed - it is no longer possible to retrieve the completion
>> notification via the error channel.
>> 
>> Is it fine for the user space program to free all outstanding messages after 
>> the
>> socket close() has returned?
>> Or is there anything else that has to be considered?
> 
> If closing the socket while user memory is still in transmission, it
> will not be possible to safely reuse the memory, as the process has no
> way of discovering when the kernel has finished transmission.
> 
> Depending on type of memory, there may be workarounds to avoid
> unbound virtual memory growth, such as unmapping the virtual
> address range in the case of mmap()ed data.
> 
> But in general, the right approach is to wait for all completions
> before closing a socket.
> 
> If this takes a long time, say due to the TCP stack hold on to data for
> retransmission in the case a peer does not properly close its side,
> disconnect (connect() AF_UNSPEC) can be used to purge the
> queues and trigger notifications. Again, this is a last resort and
> usually not needed.
Hi Willem!
Thank you for the clarification.
Do you think you could add this to the documentation of MSG_ZEROCOPY?
I think this could be really helpful for all users of the zerocopy feature.

Thanks a lot

Mathias

Reply via email to