From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 0A1EF1DB1 for ; Tue, 10 Nov 2015 15:13:54 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 10 Nov 2015 06:12:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,270,1444719600"; d="scan'208";a="846989635" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by orsmga002.jf.intel.com with ESMTP; 10 Nov 2015 06:12:05 -0800 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.13]) by IRSMSX109.ger.corp.intel.com ([169.254.13.96]) with mapi id 14.03.0248.002; Tue, 10 Nov 2015 14:12:04 +0000 From: "Mcnamara, John" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v5 1/7] ethdev: add additional ieee1588 support functions Thread-Index: AQHRG69QRIMqJ+xGU0mwoo+ppBaCyp6VSSjg Date: Tue, 10 Nov 2015 14:12:03 +0000 Message-ID: References: <1443799208-9408-1-git-send-email-danielx.t.mrzyglod@intel.com> <2257223.vnG0RKMETz@xps13> <3893351.MZRdjpoyuB@xps13> In-Reply-To: <3893351.MZRdjpoyuB@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v5 1/7] ethdev: add additional ieee1588 support functions 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, 10 Nov 2015 14:13:55 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Tuesday, November 10, 2015 11:58 AM > To: Mcnamara, John > Cc: Mrzyglod, DanielX T; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v5 1/7] ethdev: add additional ieee1588 > support functions >=20 > 2015-11-10 11:36, Mcnamara, John: > > From: Thomas Monjalon > > > I'll try to fix it now to be sure it will be one of the first series > > > ready for the 2.3 cycle. > > > > These comments are minor and could be fixed now. >=20 > After having a closer look in the drivers change, it seems to be > restricted to the PTP functions of the Intel drivers. > So you can ask to the Intel validation team if they are OK to add it in > RC2. > I think it would be a wrong idea because we need to stop moving the ethde= v > and drivers code, and focus on other DPDK areas for the RC2. Hi Thomas, Ok. I'll ask the validation team to evaluate the effect of the patches. >=20 > > > > +extern int rte_eth_timesync_time_get(uint8_t port_id, > > > > + struct timespec *time); > > > > > > How is it different from rte_eth_timesync_read_rx_timestamp() and > > > rte_eth_timesync_read_tx_timestamp()? > > > > > > Why repeating the word time? Why not rte_eth_timesync_get()? > > > > In the context of PTP there is a difference between the time (os or NIC= ) > and the timestamp (either in the mbuf, a register or as part of the > payload). >=20 > Do you think we can make it clear in the definition of these functions? Yes. I think that could be made clearer. I'll fix that and the others. >=20 > More wording comments: > - rte_eth_timesync_time_get > - rte_eth_timesync_read_rx_timestamp > Why is it "get" in a case and "read" in another? > Why the verb is at the end in the first and before the complement in the > latter? My preference would be for verb_noun but I think noun_verb was used for con= sistency with the rest of the Ethdev API (although that isn't quite consist= ent either). And yes, read() would be more consistent with the timesync API= while get() is more consistent with the rest of the Ethdev API. I think it= would be best, in this case, to try maintain self-consistency and use rte_= eth_timesync_read_time(). John. --=20