From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Green Subject: Re: Saving packet timestamp when reading from pcap Date: Tue, 21 Apr 2015 15:02:40 +0300 Message-ID: References: <55362B8C.3030604@emutex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: dev-VfR2kkLFssw@public.gmane.org To: Nicolas Pernas Maradei Return-path: In-Reply-To: <55362B8C.3030604-M3NBUjLqch7QT0dZR+AlfA@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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 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. >