| Message ID | 20240603185647.2310748-5-amorenoz@redhat.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: openvswitch: Add sample multicasting. | expand |
On Mon, Jun 03, 2024 at 08:56:38PM +0200, Adrian Moreno wrote: > Although not explicitly documented in the psample module itself, the > definition of PSAMPLE_ATTR_SAMPLE_RATE seems inherited from act_sample. > > Quoting tc-sample(8): > "RATE of 100 will lead to an average of one sampled packet out of every > 100 observed." > > With this semantics, the rates that we can express with an unsigned > 32-bits number are very unevenly distributed and concentrated towards > "sampling few packets". > For example, we can express a probability of 2.32E-8% but we > cannot express anything between 100% and 50%. > > For sampling applications that are capable of sampling a decent > amount of packets, this sampling rate semantics is not very useful. > > Add a new flag to the uAPI that indicates that the sampling rate is > expressed in scaled probability, this is: > - 0 is 0% probability, no packets get sampled. > - U32_MAX is 100% probability, all packets get sampled. > > Signed-off-by: Adrian Moreno <amorenoz@redhat.com> Hi Adrian, Would it be possible to add appropriate documentation for rate - both the original ratio variant, and the new probability variant - somewhere? That aside, this looks good to me. ...
On Fri, Jun 14, 2024 at 05:11:30PM GMT, Simon Horman wrote: > On Mon, Jun 03, 2024 at 08:56:38PM +0200, Adrian Moreno wrote: > > Although not explicitly documented in the psample module itself, the > > definition of PSAMPLE_ATTR_SAMPLE_RATE seems inherited from act_sample. > > > > Quoting tc-sample(8): > > "RATE of 100 will lead to an average of one sampled packet out of every > > 100 observed." > > > > With this semantics, the rates that we can express with an unsigned > > 32-bits number are very unevenly distributed and concentrated towards > > "sampling few packets". > > For example, we can express a probability of 2.32E-8% but we > > cannot express anything between 100% and 50%. > > > > For sampling applications that are capable of sampling a decent > > amount of packets, this sampling rate semantics is not very useful. > > > > Add a new flag to the uAPI that indicates that the sampling rate is > > expressed in scaled probability, this is: > > - 0 is 0% probability, no packets get sampled. > > - U32_MAX is 100% probability, all packets get sampled. > > > > Signed-off-by: Adrian Moreno <amorenoz@redhat.com> > > Hi Adrian, > > Would it be possible to add appropriate documentation for > rate - both the original ratio variant, and the new probability > variant - somewhere? > Hi Simon, thanks for the suggestion. Would the uapi header be a good place for such documentation? > That aside, this looks good to me. > > ... >
On Mon, Jun 17, 2024 at 06:32:14AM +0000, Adrián Moreno wrote: > On Fri, Jun 14, 2024 at 05:11:30PM GMT, Simon Horman wrote: > > On Mon, Jun 03, 2024 at 08:56:38PM +0200, Adrian Moreno wrote: > > > Although not explicitly documented in the psample module itself, the > > > definition of PSAMPLE_ATTR_SAMPLE_RATE seems inherited from act_sample. > > > > > > Quoting tc-sample(8): > > > "RATE of 100 will lead to an average of one sampled packet out of every > > > 100 observed." > > > > > > With this semantics, the rates that we can express with an unsigned > > > 32-bits number are very unevenly distributed and concentrated towards > > > "sampling few packets". > > > For example, we can express a probability of 2.32E-8% but we > > > cannot express anything between 100% and 50%. > > > > > > For sampling applications that are capable of sampling a decent > > > amount of packets, this sampling rate semantics is not very useful. > > > > > > Add a new flag to the uAPI that indicates that the sampling rate is > > > expressed in scaled probability, this is: > > > - 0 is 0% probability, no packets get sampled. > > > - U32_MAX is 100% probability, all packets get sampled. > > > > > > Signed-off-by: Adrian Moreno <amorenoz@redhat.com> > > > > Hi Adrian, > > > > Would it be possible to add appropriate documentation for > > rate - both the original ratio variant, and the new probability > > variant - somewhere? > > > > Hi Simon, thanks for the suggestion. Would the uapi header be a good > place for such documentation? Hi Adrian, I didn't look closely, but that does sound like a good place to me.
diff --git a/include/net/psample.h b/include/net/psample.h index 2ac71260a546..c52e9ebd88dd 100644 --- a/include/net/psample.h +++ b/include/net/psample.h @@ -24,7 +24,8 @@ struct psample_metadata { u8 out_tc_valid:1, out_tc_occ_valid:1, latency_valid:1, - unused:5; + rate_as_probability:1, + unused:4; const u8 *user_cookie; u32 user_cookie_len; }; diff --git a/include/uapi/linux/psample.h b/include/uapi/linux/psample.h index e80637e1d97b..8b069e75beab 100644 --- a/include/uapi/linux/psample.h +++ b/include/uapi/linux/psample.h @@ -20,6 +20,10 @@ enum { PSAMPLE_ATTR_TIMESTAMP, /* u64, nanoseconds */ PSAMPLE_ATTR_PROTO, /* u16 */ PSAMPLE_ATTR_USER_COOKIE, /* binary, user provided data */ + PSAMPLE_ATTR_SAMPLE_PROBABILITY,/* no argument, interpret rate in + * PSAMPLE_ATTR_SAMPLE_RATE as a + * probability scaled 0 - U32_MAX. + */ __PSAMPLE_ATTR_MAX }; diff --git a/include/uapi/linux/tc_act/tc_sample.h b/include/uapi/linux/tc_act/tc_sample.h index fee1bcc20793..7ee0735e7b38 100644 --- a/include/uapi/linux/tc_act/tc_sample.h +++ b/include/uapi/linux/tc_act/tc_sample.h @@ -18,6 +18,7 @@ enum { TCA_SAMPLE_TRUNC_SIZE, TCA_SAMPLE_PSAMPLE_GROUP, TCA_SAMPLE_PAD, + TCA_SAMPLE_PROBABILITY, __TCA_SAMPLE_MAX }; #define TCA_SAMPLE_MAX (__TCA_SAMPLE_MAX - 1) diff --git a/net/psample/psample.c b/net/psample/psample.c index 1c76f3e48dcd..f48b5b9cd409 100644 --- a/net/psample/psample.c +++ b/net/psample/psample.c @@ -497,6 +497,9 @@ void psample_sample_packet(struct psample_group *group, struct sk_buff *skb, md->user_cookie)) goto error; + if (md->rate_as_probability) + nla_put_flag(skb, PSAMPLE_ATTR_SAMPLE_PROBABILITY); + genlmsg_end(nl_skb, data); genlmsg_multicast_netns(&psample_nl_family, group->net, nl_skb, 0, PSAMPLE_NL_MCGRP_SAMPLE, GFP_ATOMIC);
Although not explicitly documented in the psample module itself, the definition of PSAMPLE_ATTR_SAMPLE_RATE seems inherited from act_sample. Quoting tc-sample(8): "RATE of 100 will lead to an average of one sampled packet out of every 100 observed." With this semantics, the rates that we can express with an unsigned 32-bits number are very unevenly distributed and concentrated towards "sampling few packets". For example, we can express a probability of 2.32E-8% but we cannot express anything between 100% and 50%. For sampling applications that are capable of sampling a decent amount of packets, this sampling rate semantics is not very useful. Add a new flag to the uAPI that indicates that the sampling rate is expressed in scaled probability, this is: - 0 is 0% probability, no packets get sampled. - U32_MAX is 100% probability, all packets get sampled. Signed-off-by: Adrian Moreno <amorenoz@redhat.com> --- include/net/psample.h | 3 ++- include/uapi/linux/psample.h | 4 ++++ include/uapi/linux/tc_act/tc_sample.h | 1 + net/psample/psample.c | 3 +++ 4 files changed, 10 insertions(+), 1 deletion(-)