Re: Saving packet timestamp when reading from pcap

[Dor Green <dorgreen1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Aside from testing, this also has the benefit of being able to run a
capture file through your application without having to send it
through another NIC (if you have only one, that'd be impossible, for
example). I can see this being needed if you had, for instance, a DPI
app in DPDK and wanted to run older recorded data through it (say
because your server was down for a couple of days).

As for NIC HW timestamps, DPDK does not supply access to those at the
moment (I think). That's why I suggested that if a timestamp field was
added to the mbuf struct, it could be used if/when HW timestamps are
supported it DPDK.

On Tue, Apr 21, 2015 at 1:50 PM, Nicolas Pernas Maradei
<nicolas.pernas.maradei-M3NBUjLqch7QT0dZR+AlfA@public.gmane.org> wrote:
> Hi Dor,
>
> What you are looking for seems straight forward to implement and it should
> not really affect the driver's performance at all. Even adding the full
> timestamp (seconds plus microseconds). However, I don't see too much people
> looking for that feature to make it to mainline. I could be wrong and it's
> not up to me to decide but I believe it wouldn't add too much value to the
> driver itself. It would make your testing easier but that's all. Maybe
> encapsulating the feature within #defines?
>
> If you were to read the packets from a pcap file and send them through a
> real NIC could you use the NIC's HW timestamp if supported? I'm not entirely
> sure about it (maybe someone else could provide more info about it) but it
> could solve your problem in a cleaner way.
>
> Nico.
>