[PATCH v2 2/2] pcapng: check if writev() returns a partial write
Mário Kuka
kuka at cesnet.cz
Fri Jul 29 19:08:41 CEST 2022
> 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?
On 29/07/2022 18:00, Stephen Hemminger wrote:
> On Fri, 29 Jul 2022 09:18:41 +0200
> Mário Kuka <kuka at cesnet.cz> wrote:
>
>> +pcapng_writev(int fd, struct iovec *iov, const int count)
>> +{
>> + size_t total = 0;
>> + int at = 0;
>> +
>> + while (at < count) {
>> + /*
>> + * Note: writev() can return the following on a write request:
>> + * Complete:
>> + * written = [sum of all iov.iov_len]
>> + * Partial:
>> + * written < [sum of all iov.iov_len]
>> + * Deferred:
>> + * written = -1, errno = [EAGAIN]
>> + *
>> + * Partial and deferred writes are only possible with O_NONBLOCK set.
>> + *
>> + * If we get a partial result, we have to call the writev() again on any ivo buffers
>> + * that have not been fully written.
>> + */
>> + ssize_t written = writev(fd, &iov[at], count - at);
>> + if (unlikely(written < 0))
>> + return written;
>> +
>> + total += written;
>> + at += pcapng_update_iov(&iov[at], count - at, written);
>> + }
>> +
>> + return total;
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4299 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mails.dpdk.org/archives/dev/attachments/20220729/1f1b85cb/attachment.bin>
More information about the dev
mailing list