From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by dpdk.org (Postfix) with ESMTP id 57389C320 for ; Tue, 21 Apr 2015 14:02:41 +0200 (CEST) Received: by labbd9 with SMTP id bd9so149380689lab.2 for ; Tue, 21 Apr 2015 05:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oym4LbO7Zh7EKRNah6SCgA/stLlUdJQmclSYwQuXFJI=; b=FG6DCFBzt6A+HwOL6hIofkaB8Twq0mFfJb4EzO3dHkAMiUMW+XijnfdWWtPFyz/fCd qUTK6wVVh6+hW/dWCPhSh3fHpnKNphYpBu0zucoQGB6EBaQeQj2+MUG3WJl7DEX5GtH+ W1QTpI3G38p9GpmGtccnHGrlbW9kLC3qmXjlsrxIpyQZmcKTg9WhpqRsaj5p1eE1hKP7 AvFmrl/8DzOoR7o1oGrToNk8LFbQqsTI46Zxbj3vF1WLI7HqFXrsGalYiFeIsi+dlloE D4TT2qQuYbEqzQTOjf32a55p7cLspbPWX+fydbtah76xTIk1Cf/AlbUTo1NPc4EXyamx cqtg== MIME-Version: 1.0 X-Received: by 10.112.220.34 with SMTP id pt2mr19876649lbc.81.1429617760730; Tue, 21 Apr 2015 05:02:40 -0700 (PDT) Received: by 10.25.41.201 with HTTP; Tue, 21 Apr 2015 05:02:40 -0700 (PDT) In-Reply-To: <55362B8C.3030604@emutex.com> References: <55362B8C.3030604@emutex.com> Date: Tue, 21 Apr 2015 15:02:40 +0300 Message-ID: From: Dor Green To: Nicolas Pernas Maradei Content-Type: text/plain; charset=UTF-8 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Saving packet timestamp when reading from pcap X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 12:02:41 -0000 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. >