DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Rastislav Cernay <cernay@netcope.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] drivers/net/nfb: add timestamp support
Date: Wed, 3 Jul 2019 12:55:48 +0100	[thread overview]
Message-ID: <2f067b8f-3725-c4e3-9bc3-57b15acb5237@intel.com> (raw)
In-Reply-To: <1562063577-231019-1-git-send-email-cernay@netcope.com>

On 7/2/2019 11:32 AM, Rastislav Cernay wrote:
> From: Rastislav Cernay <cernay@netcope.com>
> 
> This patch adds timestamping support to nfb driver.
> 
> Signed-off-by: Rastislav Cernay <cernay@netcope.com>

<...>

> @@ -142,3 +142,22 @@ Example output:
>       TX threshold registers: pthresh=0 hthresh=0 wthresh=0
>       TX RS bit threshold=0 - TXQ flags=0x0
>     testpmd>
> +
> +Timestamp
> +----------------
> +
> +The PMD supports hardware timestamps of frame receipt on physical network interface. In order to use
> +the timestamps, the hardware timestamping unit must be enabled (follow the documentation of the NFB
> +products) and the device argument `timestamp=1` must be used.
> +
> +.. code-block:: console
> +
> +    $RTE_TARGET/app/testpmd -w b3:00.0,timestamp=1 <other EAL params> -- <testpmd params>
> +
> +When the timestamps are enabled with the *devarg*, a timestamp validity flag is set in the MBUFs
> +containing received frames and timestamp is inserted into the `rte_mbuf` struct.
> +
> +The timestamp is an `uint64_t` field. Its lower 32 bits represent *seconds* portion of the timestamp
> +(number of seconds elapsed since 1.1.1970 00:00:00 UTC) and its higher 32 bits represent
> +*nanosecond* portion of the timestamp (number of nanoseconds elapsed since the beginning of the
> +second in the *seconds* portion.

Can you please move this block of document under "Configuration" (because this
is runtime configuration) instead of end of the document. It is good to make two
different sections for config, please check i40e.rst for sample.

> diff --git a/drivers/net/nfb/nfb_rx.c b/drivers/net/nfb/nfb_rx.c
> index 9147b00..805d893 100644
> --- a/drivers/net/nfb/nfb_rx.c
> +++ b/drivers/net/nfb/nfb_rx.c
> @@ -4,9 +4,53 @@
>   * All rights reserved.
>   */
>  
> +#include <rte_kvargs.h>
> +

Shared build fails, can you please add "-lrte_kvargs" to "LDLIBS"

<...>

> +static int
> +nfb_check_timestamp(struct rte_devargs *devargs)
> +{
> +	struct rte_kvargs *kvlist;
> +	const char *timestamp_key = "timestamp";

This is device level argument, I think it is better to make it more visible more
than a string in a function. Common approach is define macros for devargs at the
begging of the file.

> +
> +	if (devargs == NULL)
> +		return 0;
> +
> +	kvlist = rte_kvargs_parse(devargs->args, NULL);
> +	if (kvlist == NULL)
> +		return 0;

It is common approach to provide valid_keys to parse, for your case there is
single command which is checked below, but in case user provide more (invalid)
arguments and expect them work, it is good to catch it and return error.

And if there will be a valid_keys check it is better to be out of timestamp
checks, in device init phase makes more sense.

> +
> +	if (!rte_kvargs_count(kvlist, timestamp_key)) {
> +		rte_kvargs_free(kvlist);
> +		return 0;
> +	}
> +	/* Timestamps are enabled when there is
> +	 * key-value pair: enable_timestamp=1
> +	 */
> +	if (rte_kvargs_process(kvlist, timestamp_key,
> +		timestamp_check_handler, NULL) < 0) {
> +		rte_kvargs_free(kvlist);
> +		return 0;
> +	}
> +	rte_kvargs_free(kvlist);
> +
> +	return 1;
> +}

Can you please add "RTE_PMD_REGISTER_PARAM_STRING" macro to list the device
arguments?

<...>

  reply	other threads:[~2019-07-03 11:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-13 12:05 [dpdk-dev] [PATCH] " Rastislav Cernay
2019-06-27 15:45 ` Ferruh Yigit
2019-06-28 14:12   ` Jan Remeš
2019-07-02 10:32 ` [dpdk-dev] [PATCH v2] " Rastislav Cernay
2019-07-03 11:55   ` Ferruh Yigit [this message]
2019-07-15 12:03 ` [dpdk-dev] [PATCH v3] " Rastislav Cernay
2019-07-15 13:08   ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f067b8f-3725-c4e3-9bc3-57b15acb5237@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=cernay@netcope.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).