DPDK patches and discussions
 help / color / mirror / Atom feed
From: Michael Baum <michaelba@nvidia.com>
To: Dariusz Sosnowski <dsosnowski@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Ori Kam <orika@nvidia.com>,
	Aman Singh <aman.deep.singh@intel.com>,
	Yuying Zhang <yuying.zhang@intel.com>,
	Ferruh Yigit <ferruh.yigit@amd.com>,
	"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>
Subject: RE: [PATCH v3 1/2] ethdev: add random item support
Date: Thu, 14 Dec 2023 10:32:42 +0000	[thread overview]
Message-ID: <DM5PR12MB46616022FFFF1C5E3B937616CC8CA@DM5PR12MB4661.namprd12.prod.outlook.com> (raw)
In-Reply-To: <IA1PR12MB83117B4DE1C6E0485E1544F2A48AA@IA1PR12MB8311.namprd12.prod.outlook.com>


On 12/8/2023 8:54 PM, 0 Dariusz Sosnowski wrote:
> 
> Hi Michael,
> 
> > +Item: ``RANDOM``
> > +^^^^^^^^^^^^^^^^
> > +
> > +Matches a random value.
> > +
> > +The rundom number is generated by PMD,
> s/rundom/random
Ack, thank you.

> 
> I'm not sure that mentioning PMD here is fully correct, because in my opinion it
> implies that SW generates it.
> HW, SW and system clock were mentioned as examples of sources of randomness
> in previous discussions on this API.
> 
> Also, I think it's worth adding that "number == unsigned integer with at most 32
> bits."
> It gives some leeway for any driver implementing this API - value is uint32_t but
> not all bits must be used.
> For example, some HW may support only 16-bit random number generation.
> Such HW might implement validation on mask, where mask with more than 16
> bits would be rejected.
> 
> What do you think about the following proposal based on those comments?
> 
> "A random unsigned integer (at most 32-bit) is generated for each packet during
> flow rule processing, by either HW, SW or some external source.
> Application can match on either exact value or range of values."
I think your suggestion is good, but the words "for each packet" imply that the generated random value is oriented to the packet.
So I'm taking it and keeping the next lines: 
" This value is not based on the packet data/headers.
Application shouldn't assume that this value is kept during the lifetime of the packet."
> 
> > +Application shouldn't assume that this value is kept during the life
> > +time of the packet.
> s/life time/lifetime
Ack, thank you.

> 
> Best regards,
> Dariusz Sosnowski


  reply	other threads:[~2023-12-14 10:32 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-22  9:05 [PATCH v1 0/2] " Michael Baum
2023-08-22  9:05 ` [PATCH v1 1/2] " Michael Baum
2023-08-22  9:05 ` [PATCH v1 2/2] app/testpmd: " Michael Baum
2023-08-22 12:41 ` [PATCH v1 0/2] ethdev: " Ivan Malov
2023-08-22 14:09   ` Michael Baum
2023-08-22 14:09   ` Stephen Hemminger
2023-09-11  7:41 ` [PATCH v2 " Michael Baum
2023-09-11  7:41   ` [PATCH v2 1/2] " Michael Baum
2023-09-11 15:59     ` Thomas Monjalon
2023-10-12 10:14       ` Michael Baum
2023-09-11  7:41   ` [PATCH v2 2/2] app/testpmd: " Michael Baum
2023-09-18 11:44     ` Ori Kam
2023-09-11 16:55   ` [PATCH v2 0/2] ethdev: " Morten Brørup
2023-09-11 17:53     ` Stephen Hemminger
2023-10-12  9:48       ` Michael Baum
2023-09-12  8:40     ` Michael Baum
2023-11-30 16:32   ` [PATCH v3 " Michael Baum
2023-11-30 16:32     ` [PATCH v3 1/2] " Michael Baum
2023-12-08 18:54       ` Dariusz Sosnowski
2023-12-14 10:32         ` Michael Baum [this message]
2023-12-14 10:54           ` Dariusz Sosnowski
2023-12-08 19:03       ` Dariusz Sosnowski
2023-11-30 16:32     ` [PATCH v3 2/2] app/testpmd: " Michael Baum
2023-12-08 18:52       ` Dariusz Sosnowski
2023-12-14 10:58     ` [PATCH v4 0/2] ethdev: " Michael Baum
2023-12-14 10:58       ` [PATCH v4 1/2] " Michael Baum
2023-12-14 11:12         ` Dariusz Sosnowski
2023-12-14 11:32         ` Ori Kam
2023-12-14 12:18         ` Ferruh Yigit
2023-12-14 13:43           ` Michael Baum
2023-12-14 15:55             ` Ferruh Yigit
2023-12-15  7:47               ` Michael Baum
2023-12-14 10:58       ` [PATCH v4 2/2] app/testpmd: " Michael Baum
2023-12-15 12:07       ` [PATCH v4 0/2] ethdev: " 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=DM5PR12MB46616022FFFF1C5E3B937616CC8CA@DM5PR12MB4661.namprd12.prod.outlook.com \
    --to=michaelba@nvidia.com \
    --cc=aman.deep.singh@intel.com \
    --cc=dev@dpdk.org \
    --cc=dsosnowski@nvidia.com \
    --cc=ferruh.yigit@amd.com \
    --cc=orika@nvidia.com \
    --cc=thomas@monjalon.net \
    --cc=yuying.zhang@intel.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).