From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by dpdk.org (Postfix) with ESMTP id CC3425A9D for ; Mon, 20 Apr 2015 18:06:13 +0200 (CEST) Received: by lbbzk7 with SMTP id zk7so134468325lbb.0 for ; Mon, 20 Apr 2015 09:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=w4wFPkB/Cyw0SaJWopkfAFSY5vI1kl1VrIIVZLoX2BU=; b=B9qc44pdAj/3RulIC7Dy4F93NLfTlHZXKA7o6Uu5BZH7k1pIkKfgBgt1EQsfBvX5sC PZR0HLT1eaB9gesvKBEMQkgToNYR5AcUiNzU8NoVl/jdKoIafrmyBmckP0eNZGmi2Qgm 2KkYsDkEjkn4zuEmQQx/cLG5qhd8UH10xKn48LC18zP4gQAdsKTXam7nLndnwGpCSeT6 wXUiGgxi6rYPLPdeLiciizKFgSFi5epfk1piGk9ksYuK/1coKQxwpDdq6WoVP6ufXkyR ASI+xWLCoI4GPLehLt8uQ6FMS0E25uZNW+/VmPxVLWZRPexgkYhkKU44CQDN3+X4rD7q SCYw== MIME-Version: 1.0 X-Received: by 10.112.199.133 with SMTP id jk5mr16722622lbc.32.1429545973538; Mon, 20 Apr 2015 09:06:13 -0700 (PDT) Received: by 10.25.41.201 with HTTP; Mon, 20 Apr 2015 09:06:13 -0700 (PDT) Date: Mon, 20 Apr 2015 19:06:13 +0300 Message-ID: From: Dor Green To: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 Subject: [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: Mon, 20 Apr 2015 16:06:14 -0000 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.