As pcapng is used in the dpdk application it writes to a file. You could repurpose it to something else, but even a pipe will not give partial writes unless you configure the pipe as non-blocking.Writing to a non-blocking pipe is going to have a load of other problems. This seems like a purely hypothetical case, can't see why it needs to be addressed.
OK, I'm sending patch v3 which only fixes the IVO_MAX limit issue. I've removed the changes related to the partial write check. On 29/07/2022 20:14, Stephen Hemminger wrote:
On Fri, 29 Jul 2022 19:08:41 +0200 Mário Kuka <k...@cesnet.cz> wrote:Since this is being written to a file, handling partial writes makes little sense. The only case where partial write would happen would be if filesystem was full. Retrying just adds unnecessary complexity. If you really want to track this, then add a dropped counter.But the file descriptor doesn't have to refer to just a regular file, what if it's a socket or a pipe or some device? The pcapng documentation doesn't say anything about any restrictions, so the implementation should be fully generic. What's the point of a function to write packets to a file descriptor where there's a risk that it won't write all the packets or that the file will by corrupted due to a partial write and still not even let me know about it?As pcapng is used in the dpdk application it writes to a file. You could repurpose it to something else, but even a pipe will not give partial writes unless you configure the pipe as non-blocking. Writing to a non-blocking pipe is going to have a load of other problems. This seems like a purely hypothetical case, can't see why it needs to be addressed.
smime.p7s
Description: S/MIME Cryptographic Signature
