From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jblunck@gmail.com>
Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67])
 by dpdk.org (Postfix) with ESMTP id 024F52C66
 for <dev@dpdk.org>; Mon, 20 Feb 2017 10:27:41 +0100 (CET)
Received: by mail-wm0-f67.google.com with SMTP id r18so13215560wmd.3
 for <dev@dpdk.org>; Mon, 20 Feb 2017 01:27:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:sender:in-reply-to:references:from:date:message-id
 :subject:to:cc;
 bh=BrUQI4C3ujntw+76aLNArXuDpolY+Ys4MkXmFF1gGn8=;
 b=oyDLKAiseuiXpYZJ2WtIr2tbsqd6L7rIV5g2iInC9oyStF0Wmipu6CuJBkQnsEe49f
 4LbP5Sx9RojpRmOLe7P9shafa9zVn0c8jq0K7L/P85lwQdg8J/3vihwnLV3rCyUwpqiJ
 lecOkV0sn6SHUKmuHha6+wRZWTC5LmJR9A0QNwB1HENqrJ3HS3tdq3TaTt4k2b4MM35O
 gSSt8t3LkCyaDB8VvrUebw+GHZLWIRLt80B8/KnzRiSRvDDEGQNdl3JruPHgmIv7/IGU
 zYBd2Nh9inK9rjA3NQsTJZ+iAvd6IKlNAeX8J+4+cPdaERKyZLZqLXlAQqxt3A1AKR2l
 fsFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
 :date:message-id:subject:to:cc;
 bh=BrUQI4C3ujntw+76aLNArXuDpolY+Ys4MkXmFF1gGn8=;
 b=jKIv1Xy87281K0El7+aae2sUv5AOm9/ZSDDgRFSECm0OXtMFa2wXLS6CrKyFumzI71
 TmdYItcho5VmgW49SSoDKuQycAzhW4oIZDH7rdsNddb0KAyEHPv8Nb/Lth3AiUTfJ4hs
 FEP5RK0MG0zwJI9pKGB1NGRHVzzi6rou/Pz9/BgY1S1QJzP6pecAr8kIum6JEox4T9V9
 XsGU0j7Ch8cNxmNybkGRNfnZOX6KDHwifxvuuNgRQQQjm2WZQj1NDpcqsCmIWQMhq3H8
 yEAlvwtTHxgGZcnCthvkYykgBl5Vz78onNaHZpxws1oOMb1N54qTWuICt16LAkn2G4tC
 0yZg==
X-Gm-Message-State: AMke39lfCKkbYMQxubF6I57WWpaiL1OYWX1aCtGjX7rR1hTxPVnliXpbCCJH0pjMEnbNouHoyO+34646gL2y4w==
X-Received: by 10.28.212.82 with SMTP id l79mr17569143wmg.101.1487582861507;
 Mon, 20 Feb 2017 01:27:41 -0800 (PST)
MIME-Version: 1.0
Sender: jblunck@gmail.com
Received: by 10.28.211.20 with HTTP; Mon, 20 Feb 2017 01:27:40 -0800 (PST)
In-Reply-To: <20170217151708.20bf4a49@platinum>
References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com>
 <2601191342CEEE43887BDE71AB9772583F111A29@irsmsx105.ger.corp.intel.com>
 <20170216144807.7add2c71@platinum>
 <CALe+Z00Y_=4rsAjTeyaEzKFqtuMb6HMRUEUDL2LveJx6bWL-dA@mail.gmail.com>
 <20170217115153.0afeb061@platinum>
 <CALe+Z03QtPVmZ39bCaqGvmdsSipKftA_sZqc5K2F1WDjkEUrsg@mail.gmail.com>
 <20170217151708.20bf4a49@platinum>
From: Jan Blunck <jblunck@infradead.org>
Date: Mon, 20 Feb 2017 10:27:40 +0100
X-Google-Sender-Auth: U9YHHNI5zztubQAKABVuMTGhVeI
Message-ID: <CALe+Z01vzfLsCuy8vvVMyoOPU72NwKK0fPmMcxAbRYXx+g6kPg@mail.gmail.com>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2017 09:27:42 -0000

On Fri, Feb 17, 2017 at 3:17 PM, Olivier Matz <olivier.matz@6wind.com> wrote:
>
> Sorry, I don't really get your point. My comprehension of the timestamp
> usage in a PMD is as following:
>
> rx_burst(struct rxq *rxq, ...)
> {
>         unsigned long factor = rxq->timestamp_factor;
>         unsigned port = rxq->port;
>
>         for each hw_desc {
>                 m = rte_pktmbuf_alloc(rxq->pool);
>                 m->len = hw_desc->len;
>                 m->port = port;
>                 m->ol_flags =
>                 ...
>                 m->timestamp = hw_desc->timestamp * factor;
>         }
>         ...
> }
>
> In that case, I think it deserves to be in the 1st cache line.
>

Timestamps are non-functional data. I believe they don't deserve to be
data normalized.

It would be beneficial to normalize the access of non-functional data.
That would require some kind of extension or feature flags, e.g. like
some uverb structures support extensions. This would allow the NICs
that support timestamps to do the minimal amount of work during burst
and defer data normalization to the time of access. That would also
safe everyone from wasting 64bit in the first cacheline in case
timestamps are not supported or unused.