[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Improving the data supplied by BPF
Arnaud Lacombe <lacombar%gmail.com@localhost> wrote:
>> The purpose of the sequence number is to provide the rolling counter
>> of the packets captured for the one in question. Thus if in successive
>> reads the count went from 2 to 5, you know 3 packets have been missed.
>what if the count goes from 3 to... 3, ie. the seq number overflowed
>(for whatever reason) ?
>why unsigned ? currently `tv_sec' is signed. Why not using time_t ?
>There is an obvious ABI breakage when we will switch to 64bits time_t
>but this is be a better type than raw integer. The breakage is a
>different trouble and should be dealt with separately.
You answered your own question. All types in the struct should be fixed size
and time_t will change soon to be 64 bits.
>> uint32_t ebr_nsecs;
>why do you want nano second precision if you getting your information
>from a micro second precision variable. There is no information gain
>there, and your code reflect this (ie. you just "* 1000" to get the
>nano second value from the micro second value).
In the time_t branch it already uses nanoseconds. Plus why you would want to
stick with micros in the new interface?
>This field would have a meaning if you change the call the call to
>microtime() to nanotime() in bpf_tap()/bpd_deliver() and build a
>homegrown `struct timeval' in the non-extended capture format. You
>don't have any precision loss in that case.
>btw, why not just using a `struct timespec' ?
fixed sizes. Most on wire structures use fixed sizes. this allows portability
across different architectures.
>> uint32_t ebr_seqno; /* sequence number in capture */
>how to detect wrap in sequence number ?
It does not happen in real situations.
Main Index |
Thread Index |