DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Phil Yang <Phil.Yang@arm.com>,
	Viacheslav Ovsiienko <viacheslavo@mellanox.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "matan@mellanox.com" <matan@mellanox.com>,
	"rasland@mellanox.com" <rasland@mellanox.com>,
	"thomas@monjalon.net" <thomas@monjalon.net>, nd <nd@arm.com>
Subject: Re: [dpdk-dev] [PATCH v2] app/testpmd: fix txonly mode timestamp intitialization
Date: Wed, 29 Jul 2020 16:29:18 +0100	[thread overview]
Message-ID: <d5dead60-4168-d853-42c2-48da1cbc5290@intel.com> (raw)
In-Reply-To: <VE1PR08MB4640C2C676D89DED99FC4BC4E9700@VE1PR08MB4640.eurprd08.prod.outlook.com>

On 7/29/2020 3:07 PM, Phil Yang wrote:
>> -----Original Message-----
>> From: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
>> Sent: Wednesday, July 29, 2020 8:30 PM
>> To: dev@dpdk.org
>> Cc: matan@mellanox.com; rasland@mellanox.com; thomas@monjalon.net;
>> ferruh.yigit@intel.com; Phil Yang <Phil.Yang@arm.com>
>> Subject: [PATCH v2] app/testpmd: fix txonly mode timestamp intitialization
>> The testpmd application forwards data in multiple threads.
>> In the txonly mode the Tx timestamps must be initialized
>> on per thread basis to provide phase shift for the packet
>> burst being sent. This per thread initialization was performed
>> on zero value of the variable in thread local storage and
>> happened only once after testpmd forwarding start. Executing
>> "start" and "stop" commands did not cause thread local variables
>> zeroing and wrong timestamp values were used.
>> Fixes: 4940344dab1d ("app/testpmd: add Tx scheduling command")
>> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> It looks good to me. 
> Reviewed-by: Phil Yang <phil.yang@arm.com>

Applied to dpdk-next-net/master, thanks.

Overall concern with Tx scheduling code is testing. For the issues like this.

It can be enabled only for 'octeontx2' & 'mlx5', which implements '.read_clock',
and it really can be only used by 'mlx5' because of the mbuf dynamic field.

So only 'mlx5' can use and test it.

What happens when mellanox stops testing it?
Is there any DTS implementation to help others to test or at least to document
how to test it and to document the intention of the feature?

      reply	other threads:[~2020-07-29 15:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 15:26 [dpdk-dev] [PATCH] " Viacheslav Ovsiienko
2020-07-28 16:23 ` Phil Yang
2020-07-29  8:08   ` Slava Ovsiienko
2020-07-29  9:37     ` Phil Yang
2020-07-29 12:29 ` [dpdk-dev] [PATCH v2] " Viacheslav Ovsiienko
2020-07-29 14:07   ` Phil Yang
2020-07-29 15:29     ` Ferruh Yigit [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:

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

  git send-email \
    --in-reply-to=d5dead60-4168-d853-42c2-48da1cbc5290@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=Phil.Yang@arm.com \
    --cc=dev@dpdk.org \
    --cc=matan@mellanox.com \
    --cc=nd@arm.com \
    --cc=rasland@mellanox.com \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@mellanox.com \


* 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).