DPDK patches and discussions
 help / color / mirror / Atom feed
From: Michael Baum <michaelba@nvidia.com>
To: "Stephen Hemminger" <stephen@networkplumber.org>,
	"Morten Brørup" <mb@smartsharesystems.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, 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 v2 0/2] ethdev: add random item support
Date: Thu, 12 Oct 2023 09:48:21 +0000	[thread overview]
Message-ID: <DM5PR12MB46615D5E5B78FDCBC653D856CCD3A@DM5PR12MB4661.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20230911105321.6e17708d@fedora>

On  Monday, 11 September 2023 20:53 Stephen Hemminger wrote: 
> 
> On Mon, 11 Sep 2023 18:55:45 +0200
> Morten Brørup <mb@smartsharesystems.com> wrote:
> 
> > > From: Michael Baum [mailto:michaelba@nvidia.com]
> > > Sent: Monday, 11 September 2023 08.42
> > >
> > > Add support for matching random value using new
> > > "rte_flow_item_random" structure.
> >
> > I get it. It can be used for things like stochastic sampling.
> >
> > However, it doesn't provide support for e.g. 1/100 or 1/500.
> >
> > So here's a suggestion:
> >
> > Instead of "value" (which is irrelevant) & "mask" (which is what
> > really controls the probability), wouldn't it be better if "value"
> > was an inverse probability (and "mask" was irrelevant)? E.g.
> > value=500 means that there is a 1 of 500 probability of a match.
> >
> > Would this kind of random item better serve the purpose?
> >
> > Or is the random item, in its current form, also required for other
> > purposes?
> >
> 
> For netem (Linux kernel) needed to support expressing a percent in fixed point
> number. The solution was to express it as:
>     Percent = X / UINT32_MAX

I concur with the notion that numbers can be utilized for probability calculations. However, it's important to acknowledge that when employing numbers, we are essentially working with a superset of possibilities due to their inherent versatility.

To illustrate this, consider the scenario where we transmit a numerical value to an application and use that same value across different stages of the pipeline. Take, for instance, the following use case:

In the initial stage, there is a 20% probability of selecting a packet for sampling before proceeding with the pipeline.

Towards the end of the pipeline, if the packet was initially sampled, we sample it once more.

The challenge arises when attempting to replicate this process solely using a numerical value, as there is no guarantee that the same packet will be chosen both in the initial and final stages. Conversely, by duplicating the random number and using it as a reference for matching, we can effectively implement the aforementioned usage scenario.

I hope this clarifies the distinction and benefits of utilizing random numbers in our probability calculations.


  reply	other threads:[~2023-10-12  9:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-22  9:05 [PATCH v1 " 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 [this message]
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
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=DM5PR12MB46615D5E5B78FDCBC653D856CCD3A@DM5PR12MB4661.namprd12.prod.outlook.com \
    --to=michaelba@nvidia.com \
    --cc=aman.deep.singh@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=mb@smartsharesystems.com \
    --cc=orika@nvidia.com \
    --cc=stephen@networkplumber.org \
    --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).