[dpdk-dev] Saving packet timestamp when reading from pcap

[dpdk-dev] Saving packet timestamp when reading from pcap

[Dor Green]

To test my program and for some other uses I sometimes use vdev
(libpcap pmd) to read data from a pcap file.

Those tests would be a lot easier if the packet timestamp (which is in
the cap) was supplied by DPDK, but alas it is not.

So I could access it, I placed it in mbuf's userdata for the timebeing.
In rte_eth_pcap.c I added this after line 171:
 mbuf->userdata = (void*) header.ts.tv_sec;
Obviously this isn't the prettiest and it lacks the microseconds the
struct supplies.

Does anyone have any better ideas on how to do it, or is this a
feature planned for any future version (seems easy enough to add some
more fields to the mbuf struct to accommodate this, and maybe in the
future hardware timestamps, etc.?)

Thanks, Dor.

Re: [dpdk-dev] Saving packet timestamp when reading from pcap

[Nicolas Pernas Maradei]

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.

Re: [dpdk-dev] Saving packet timestamp when reading from pcap

[Dor Green]

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@emutex.com> 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.
>