From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com [209.85.128.180]) by dpdk.org (Postfix) with ESMTP id 2A0D42BAA for ; Tue, 28 Feb 2017 11:50:47 +0100 (CET) Received: by mail-wr0-f180.google.com with SMTP id u108so6032232wrb.3 for ; Tue, 28 Feb 2017 02:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=W77kpD2faeMDK4BYpwH3Wo0N2gaDpdGMF8Q8aHGo3os=; b=yxQbENvq3JFyikwEK55T6mNFqiZryQ6Rgt41iIpm2OnHJkUUw97JwUsU5kEdwyQyFf 9Ffwa/6URYMkFcB4vcDr2szcpQVKjYEJr0w40Dq3ZVlpRNVZmIdXl9OoSo6VhvK0Co7x wZ+DVgBMNw0GLw1a9xsNLsBKJrRdH1lz9NZsyXXqxSmtyNWrjQkbYYisiSh1OwCbcoJR YSCNcIJaQ3Cc6kUu0o6XqQOC8sxm0TUP9wI9Wdm66DsqlvAE8gbFlSvrrtSit0dX/p2A uN77dWqcliD1wR5bMCQHybvpvvbvfoDVVPnH/SLfCuz2iNA0mFeB8O0Yrvsg2BEw81+r pRDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=W77kpD2faeMDK4BYpwH3Wo0N2gaDpdGMF8Q8aHGo3os=; b=l+/trwoTYJoHHPZZcHxDy4CLZW+vCj0rcHJgcSOE7FxQjeL79rdx5PlRAhqMWzmn+B rLc+0SY99RJ/yARgVJiP9GUv8n7OP2/xE+CyDuvlf1OvXjyBH6zJbTvyiD9gZZci11pY hfw/bqIamhu3AsNyV6CCDchLATkPKViTe0Mr3SEQqQpjOSBytsQ+p6QuYUxRopWc/ydL RDG5S+qB1GaKKG9UUTTjKx/X68Ux6Qx53pFbWFZ7iA1WDHjHa+aQ/em4vXQ5fepzVwhe DM72Mu+ALOcpRIvJp6oYSNYmNgTd4cdJmHuvdll/MnwQymVjM49dlmC9sW+q4dzNUrzj jX9Q== X-Gm-Message-State: AMke39kyKSODb94a3Lee8Yoau6yJlPcjREew6sZyy4c4yEIekvHRYl7rfkCYCcFc3gS1ztsm X-Received: by 10.223.180.68 with SMTP id v4mr1579656wrd.37.1488279046086; Tue, 28 Feb 2017 02:50:46 -0800 (PST) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id k128sm1955127wmf.16.2017.02.28.02.50.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 28 Feb 2017 02:50:45 -0800 (PST) Date: Tue, 28 Feb 2017 11:50:43 +0100 From: Olivier Matz To: "Ananyev, Konstantin" Cc: Jan Blunck , "Richardson, Bruce" , "dev@dpdk.org" Message-ID: <20170228115043.3f78ce52@platinum> In-Reply-To: <2601191342CEEE43887BDE71AB9772583F11EA11@irsmsx105.ger.corp.intel.com> References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <20170217151708.20bf4a49@platinum> <20170221105400.2eba4747@glumotte.dev.6wind.com> <20170221163808.GA213576@bricha3-MOBL3.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F11B4CC@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F11B633@irsmsx105.ger.corp.intel.com> <20170224150053.279e718d@platinum> <2601191342CEEE43887BDE71AB9772583F11E992@irsmsx105.ger.corp.intel.com> <20170228102359.5d601797@platinum> <2601191342CEEE43887BDE71AB9772583F11EA11@irsmsx105.ger.corp.intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 28 Feb 2017 10:50:47 -0000 On Tue, 28 Feb 2017 10:29:41 +0000, "Ananyev, Konstantin" wrote: > > > > Hi, > > > > On Tue, 28 Feb 2017 09:05:07 +0000, "Ananyev, Konstantin" > > wrote: > > > Hi everyone, > > > > > > > > > > > > > In my opinion, if we have the room in the first cache line, we > > > > > should put it there. The only argument I see against is "we > > > > > may find something more important in the future, and we won't > > > > > have room for it in the first cache line". I don't feel we > > > > > should penalize today's use cases for hypothetic future use > > > > > cases. > > > > > > > > > > > > > > > > > > > >> 2. timestamp normalization point > > > > >> inside PMD RX vs somewhere later as user needs it (extra > > > > >> function in dev_ops?). > > > > > > > > > > This point could be changed. My initial proposition tries to > > > > > provide a generic API for timestamp. Let me remind it here: > > > > > > > > > > a- the timestamp is in nanosecond > > > > > b- the reference is always the same for a given path: if the > > > > > timestamp is set in a PMD, all the packets for this PMD will > > > > > have the same reference, but for 2 different PMDs (or a sw > > > > > lib), the reference would not be the same. > > > > > > > > > > We may remove a-, and just have: > > > > > - the reference and the unit are always the same for a given > > > > > path: if the timestamp is set in a PMD, all the packets for > > > > > this PMD will have the same reference and unit, but for 2 > > > > > different PMDs (or a sw lib), they would not be the same. > > > > > > > > > > In both cases, we would need a conversion code (maybe in a > > > > > library) if the application wants to work with timestamps from > > > > > several sources. The second solution removes the normalization > > > > > code in the PMD when not needed, it is probably better. > > > > > > > > I agree. > > > > > > One question - does that mean that application would need to > > > keep a track from what PMD each particular packet came to do the > > > normalization? Konstantin > > > > I'd say yes. It does not look very difficult to do, since the mbuf > > contains the input port id. > > > > I understand that we can use mbuf->port here, but it means that we'll > introduce new implicit dependency between timestamp and port values. > From my point that introduces new implications: > 1. all PMDs that do set a timestamp would also have to set port value too. > Probably not a big deal as most of PMDs do set port value anyway right now, > but it means it would be hard to get rid/change mbuf->port in future. Currently, all PMDs must set m->port. If in the future we remove m->port, the applications that use it will need to store the value in a mbuf metadata, or pass it as arguments through function calls. > 2. Applications would not allowed to change mbuf->port value before normalization is done > (from what I heard some apps do update mbuf->port to store routing decisions). > BTW, how the app would keep track which mbufs were already normalized, and which were not? I don't think it should be allowed to change m->port value. Applications that are doing this are responsible of what they change. > 3. In theory with eth_dev_detach() - mbuf->port value might be not valid at the point when application > would decide to do normalization. > > So to me all that approach with delayed normalization seems unnecessary overcomplicated. > Original one suggested by Olivier, when normalization is done in PMD at RX look > much cleaner and more manageable. Detaching a device requires a synchronization between control and data plane, and not only for this use case. In the first solution, the normalization is partial: unit is nanosecond, but the time reference is different. So, after the discussion, I'm more convinced by the second solution. Regards, Olivier