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