Re: Improving the data supplied by BPF

[christos%astron.com@localhost (Christos Zoulas)]

In article 
<1a69a9d80812251258s425cd795g40bf787f74e82566%mail.gmail.com@localhost>,
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) ?

Highly unlinkely.

>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.


christos