From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f196.google.com (mail-wr0-f196.google.com [209.85.128.196]) by dpdk.org (Postfix) with ESMTP id A73BF98 for ; Tue, 21 Feb 2017 17:12:13 +0100 (CET) Received: by mail-wr0-f196.google.com with SMTP id s27so6615429wrb.0 for ; Tue, 21 Feb 2017 08:12:13 -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=69kJq/ReNWl0Gq2t7RaRIstsL5GQBn8eD8zb451ex/c=; b=LoK2epQ47VBNg9Aq6y+8DflhDClU4yK8r2we379JYo5h96KKLd2QxNDQgANELqFCbD e1KK0inhhUhxAXkIHZ5Z9f76eGReQeCkyZNoHNaPnqb8YzUxaIltQhrTK/S29fXrDybE wDjW8Z2yuSxUKxkPPVe9Nbs4G4Rl1KjKGzgVRtpM2bz7GA9Bz4TMGqH4BdYmdefIDLTf Um4DC63qnbp0m2R/zsj3Ii+ddbrB5ueL9AoZlIJ9M55+BqVFgMNGSqOg5yFiMX21NinW fOO82b/3VJe9qMeTq2ayOU5BqeFaHJm8tw53YbqRW1zja6Xv+m/dkvMQl23feAbMSlZG N+dA== 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=69kJq/ReNWl0Gq2t7RaRIstsL5GQBn8eD8zb451ex/c=; b=ub6HlBAjUkS8yqd0B+fk7ANaFbOuzXNe7r0BtGkDSAbL9EsKcJTYHafkUY0Xsoz11o skWhO5WW+LTaIHJrDjtBObRsDFhp+UhpkBP5IWr0k9BKrAcZTBoypw7XKBO5uAdIm70M Qnc7QtCSXmDoosDnX4JGLGNEfwiP4UFs5/QWWHa1T0bNZVWa84b6PTKaXbAJg+qTN4RL Xo9rxZ6t09gx4+NwvudoPvDSReylyygaSW3hZ3H8o9yFV/U/hTSFLEIIBKJqOPmHsA73 p+fWn6GDaUzjCKYKJ9ZE0tkkkWUgCsjg0JRkjIW11oWjni325MfXh64VEebbDrGrCCGY 3PBQ== X-Gm-Message-State: AMke39nuF+Da1mZdDVhcvOosXh2tWTxvuNYPVnhW2se6Ch5bygFtkKpaJmxwRkeEywIZDfb7O1FJJBXOpLPOcg== X-Received: by 10.223.170.221 with SMTP id i29mr23910266wrc.131.1487693533322; Tue, 21 Feb 2017 08:12:13 -0800 (PST) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.211.20 with HTTP; Tue, 21 Feb 2017 08:12:12 -0800 (PST) In-Reply-To: <20170221105400.2eba4747@glumotte.dev.6wind.com> References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB9772583F111A29@irsmsx105.ger.corp.intel.com> <20170216144807.7add2c71@platinum> <20170217115153.0afeb061@platinum> <20170217151708.20bf4a49@platinum> <20170221105400.2eba4747@glumotte.dev.6wind.com> From: Jan Blunck Date: Tue, 21 Feb 2017 17:12:12 +0100 X-Google-Sender-Auth: EaADCPA--Onb2xzrnt6bmN0XXo0 Message-ID: To: Olivier MATZ Cc: "Ananyev, Konstantin" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 16:12:13 -0000 On Tue, Feb 21, 2017 at 10:54 AM, Olivier MATZ wrote: > Hi Jan, > > On Mon, 20 Feb 2017 10:27:40 +0100, Jan Blunck > wrote: >> On Fri, Feb 17, 2017 at 3:17 PM, Olivier Matz >> 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. > > I don't really see why timestamp is non-functional, compared to rss > hash, flow director id, packet type, seqn, ... > One doesn't drop, forward, reorder or decrypt packets based on the timestamp value. Common use cases for timestamps are analytics applications or circuit breakers where you want to ensure that your algos don't act upon stale data. This is more application layer / slow path work. > I think the goal of DPDK is to provide a generic/normalized API for > such features (like for offload), so it can be used by an application > whatever the underlying driver. > I believe there is a difference between dataplane relevant functionally and non-functional features. If you structurally normalize the later you will end up making everyone pay for a feature that is only relevant to a particular group of users. In that case I would at least expect that the support for timestamps can get selected at compile time. >> >> 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. > > I agree that we could start to think about "extensible" mbufs. In few > words, I think we could have: > - only general fields are static > - the application registers room in mbuf structure for all features it > will use > It would rationalize the room used in mbuf, at the cost of a more > complex/slow access to the data in PMDs and application, since the > offset won't be static. > Access through PMD specific function pointers should be relatively fast on access. Modern architecture optimize that use case well enough. > But to me, this is another work, and a much harder one since it will > impact a lot of PMD code (some are using vector instructions and are > quite hard to change). Moreover, we first have to prove that it would > perform better than we we have now, especially knowing that size of the > cache line will probably change to 128B for many architectures. > > Now back on the patch, yes, it's true we are consuming 64bits in the > first cache line. But what are the other options? Having it in the > second cache line would allow free this space for future use. But don't > you think we could optimize current use, and rework the structure if > new needs -- that are more important than timestamp for the majority-- > appear? What is you plan for devices that already put the timestamp relative to the packet data? Do you still want to duplicate and normalize it into the rte_mbuf field? What is recommended to do for PMDs that don't support HW timestamps? Do they still fill this field?