DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Xing, Beilei" <beilei.xing@intel.com>
To: Michael Lilja <ml@napatech.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] drivers/net/i40e/i40e_fdir.c: Improved i40e	FDIR programming times
Date: Mon, 15 May 2017 09:55:38 +0000	[thread overview]
Message-ID: <94479800C636CB44BD422CB454846E0131FAD9AC@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <20170511102115.26466-1-ml@napatech.com>

Hi Lijia,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Michael Lilja
> Sent: Thursday, May 11, 2017 6:21 PM
> To: dev@dpdk.org
> Cc: Michael Lilja <ml@napatech.com>
> Subject: [dpdk-dev] [PATCH v2] drivers/net/i40e/i40e_fdir.c: Improved i40e
> FDIR programming times
> 
> During my work (https://www.napatech.com/hw-acceleration-via-rte_flow/)
> on a flowtable application example that use rte_flow I discovered that the
> rte_flow programming times on a i40e was +11ms. The patch below result in
> an average programming time of 22usec with a max of 60usec instead of
> +11ms.
> 
> Could the following patch be useful? There might be a good reason for the
> original code, I'm unable to tell, so I will let it up to the maintainer to decide.

Thanks for the patch, it's useful, and this can be removed from the commit log.

> 
> Signed-off-by: Michael Lilja <ml@napatech.com>
> 
> ---
> v2:
> * Code style fix
> ---
>  drivers/net/i40e/i40e_fdir.c | 21 +++++++++++++--------
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c index
> 28cc554f5..2162443f5 100644
> --- a/drivers/net/i40e/i40e_fdir.c
> +++ b/drivers/net/i40e/i40e_fdir.c
> @@ -1296,23 +1296,28 @@ i40e_fdir_filter_programming(struct i40e_pf *pf,
>         rte_wmb();
>         I40E_PCI_REG_WRITE(txq->qtx_tail, txq->tx_tail);
> 
> -       for (i = 0; i < I40E_FDIR_WAIT_COUNT; i++) {
> -               rte_delay_us(I40E_FDIR_WAIT_INTERVAL_US);
> +       for (i = 0; i < (I40E_FDIR_WAIT_COUNT *
> + I40E_FDIR_WAIT_INTERVAL_US); i++) {
>                 if ((txdp->cmd_type_offset_bsz &
> -                               rte_cpu_to_le_64(I40E_TXD_QW1_DTYPE_MASK)) ==
> -                               rte_cpu_to_le_64(I40E_TX_DESC_DTYPE_DESC_DONE))
> +                       rte_cpu_to_le_64(I40E_TXD_QW1_DTYPE_MASK)) ==
> +                       rte_cpu_to_le_64(I40E_TX_DESC_DTYPE_DESC_DONE))
>                         break;
> +               rte_delay_us(1);
>         }
> -       if (i >= I40E_FDIR_WAIT_COUNT) {
> +       if (i >= (I40E_FDIR_WAIT_COUNT * I40E_FDIR_WAIT_INTERVAL_US)) {
>                 PMD_DRV_LOG(ERR, "Failed to program FDIR filter:"
> -                           " time out to get DD on tx queue.");
> +                       " time out to get DD on tx queue.");
>                 return -ETIMEDOUT;
>         }
>         /* totally delay 10 ms to check programming status*/
> -       rte_delay_us((I40E_FDIR_WAIT_COUNT - i) *
> I40E_FDIR_WAIT_INTERVAL_US);
> +       for (i = 0; i < (I40E_FDIR_WAIT_COUNT *
> I40E_FDIR_WAIT_INTERVAL_US); i++) {
> +               i
f (i40e_check_fdir_programming_status(rxq) >= 0) {

Braces {} can be removed here according to the coding style.

> +                       break;
 
How about "return 0;" here?

> +               }
> +               rte_delay_us(1);
> +       }
>         if (i40e_check_fdir_programming_status(rxq) < 0) {

How about removing the if statement? as i40e_check_fdir_programming_status(rxq) has been executed in the above for loop.

>                 PMD_DRV_LOG(ERR, "Failed to program FDIR filter:"
> -                           " programming status reported.");
> +                               " programming status reported.");
>                 return -ENOSYS;
>         }
> 
> --
> 2.12.2
> 
> Disclaimer: This email and any files transmitted with it may contain
> confidential information intended for the addressee(s) only. The information
> is not to be surrendered or copied to unauthorized persons. If you have
> received this communication in error, please notify the sender immediately
> and delete this e-mail from your system.

      reply	other threads:[~2017-05-15  9:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-11 10:21 Michael Lilja
2017-05-15  9:55 ` Xing, Beilei [this message]

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=94479800C636CB44BD422CB454846E0131FAD9AC@SHSMSX101.ccr.corp.intel.com \
    --to=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=ml@napatech.com \
    /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).