Re: [ovs-dev] [PATCH net-next v2 6/9] net: openvswitch: store sampling probability in cb.
On Mon, Jun 17, 2024 at 01:26:39PM GMT, Ilya Maximets wrote:
> On 6/17/24 09:08, Adrián Moreno wrote:
> > On Fri, Jun 14, 2024 at 12:55:59PM GMT, Aaron Conole wrote:
> >> Adrian Moreno writes:
> >>
> >>> The behavior of actions might not be the exact same if they are being
> >>> executed inside a nested sample action. Store the probability of the
> >>> parent sample action in the skb's cb area.
> >>
> >> What does that mean?
> >>
> >
> > Emit action, for instance, needs the probability so that psample
> > consumers know what was the sampling rate applied. Also, the way we
> > should inform about packet drops (via kfree_skb_reason) changes (see
> > patch 7/9).
> >
> >>> Use the probability in emit_sample to pass it down to psample.
> >>>
> >>> Signed-off-by: Adrian Moreno
> >>> ---
> >>> include/uapi/linux/openvswitch.h | 3 ++-
> >>> net/openvswitch/actions.c| 25 ++---
> >>> net/openvswitch/datapath.h | 3 +++
> >>> net/openvswitch/vport.c | 1 +
> >>> 4 files changed, 28 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/include/uapi/linux/openvswitch.h
> >>> b/include/uapi/linux/openvswitch.h
> >>> index a0e9dde0584a..9d675725fa2b 100644
> >>> --- a/include/uapi/linux/openvswitch.h
> >>> +++ b/include/uapi/linux/openvswitch.h
> >>> @@ -649,7 +649,8 @@ enum ovs_flow_attr {
> >>> * Actions are passed as nested attributes.
> >>> *
> >>> * Executes the specified actions with the given probability on a
> >>> per-packet
> >>> - * basis.
> >>> + * basis. Nested actions will be able to access the probability value of
> >>> the
> >>> + * parent @OVS_ACTION_ATTR_SAMPLE.
> >>> */
> >>> enum ovs_sample_attr {
> >>> OVS_SAMPLE_ATTR_UNSPEC,
> >>> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> >>> index 3b4dba0ded59..33f6d93ba5e4 100644
> >>> --- a/net/openvswitch/actions.c
> >>> +++ b/net/openvswitch/actions.c
> >>> @@ -1048,12 +1048,15 @@ static int sample(struct datapath *dp, struct
> >>> sk_buff *skb,
> >>> struct nlattr *sample_arg;
> >>> int rem = nla_len(attr);
> >>> const struct sample_arg *arg;
> >>> + u32 init_probability;
> >>> bool clone_flow_key;
> >>> + int err;
> >>>
> >>> /* The first action is always 'OVS_SAMPLE_ATTR_ARG'. */
> >>> sample_arg = nla_data(attr);
> >>> arg = nla_data(sample_arg);
> >>> actions = nla_next(sample_arg, );
> >>> + init_probability = OVS_CB(skb)->probability;
> >>>
> >>> if ((arg->probability != U32_MAX) &&
> >>> (!arg->probability || get_random_u32() > arg->probability)) {
> >>> @@ -1062,9 +1065,21 @@ static int sample(struct datapath *dp, struct
> >>> sk_buff *skb,
> >>> return 0;
> >>> }
> >>>
> >>> + if (init_probability) {
> >>> + OVS_CB(skb)->probability = ((u64)OVS_CB(skb)->probability *
> >>> + arg->probability / U32_MAX);
> >>> + } else {
> >>> + OVS_CB(skb)->probability = arg->probability;
> >>> + }
> >>> +
> >>
> >> I'm confused by this. Eventually, integer arithmetic will practically
> >> guarantee that nested sample() calls will go to 0. So eventually, the
> >> test above will be impossible to meet mathematically.
> >>
> >> OTOH, you could argue that a 1% of 50% is low anyway, but it still would
> >> have a positive probability count, and still be possible for
> >> get_random_u32() call to match.
> >>
> >
> > Using OVS's probability semantics, we can express probabilities as low
> > as (100/U32_MAX)% which is pretty low indeed. However, just because the
> > probability of executing the action is low I don't think we should not
> > report it.
> >
> > Rethinking the integer arithmetics, it's true that we should avoid
> > hitting zero on the division, eg: nesting 6x 1% sampling rates will make
> > the result be zero which will make probability restoration fail on the
> > way back. Threrefore, the new probability should be at least 1.
> >
> >
> >> I'm not sure about this particular change. Why do we need it?
> >>
> >
> > Why do we need to propagate the probability down to nested "sample"
> > actions? or why do we need to store the probability in the cb area in
> > the first place?
> >
> > The former: Just for correctness as only storing the last one would be
> > incorrect. Although I don't know of any use for nested "sample" actions.
>
> I think, we can drop this for now. All the user interfaces specify
> the probability per action. So, it should be fine to report the
> probability of the action that emitted the sample without taking into
> account the whole timeline of that packet. Besides, packet can leave
> OVS and go back loosing the metadata, so it will not actually be a
> full solution anyway. Single-action metadata is easier to define.
>
Sure, I guess we can drop it, I don't think there is a use case for nested
samples anyway.
> > The latter: To pass it down to psample so that sample receivers know how
> > the sampling rate applied (and, e.g: do throughput estimations like
Re: [ovs-dev] [PATCH net-next v2 6/9] net: openvswitch: store sampling probability in cb.
On 6/17/24 09:08, Adrián Moreno wrote:
> On Fri, Jun 14, 2024 at 12:55:59PM GMT, Aaron Conole wrote:
>> Adrian Moreno writes:
>>
>>> The behavior of actions might not be the exact same if they are being
>>> executed inside a nested sample action. Store the probability of the
>>> parent sample action in the skb's cb area.
>>
>> What does that mean?
>>
>
> Emit action, for instance, needs the probability so that psample
> consumers know what was the sampling rate applied. Also, the way we
> should inform about packet drops (via kfree_skb_reason) changes (see
> patch 7/9).
>
>>> Use the probability in emit_sample to pass it down to psample.
>>>
>>> Signed-off-by: Adrian Moreno
>>> ---
>>> include/uapi/linux/openvswitch.h | 3 ++-
>>> net/openvswitch/actions.c| 25 ++---
>>> net/openvswitch/datapath.h | 3 +++
>>> net/openvswitch/vport.c | 1 +
>>> 4 files changed, 28 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/uapi/linux/openvswitch.h
>>> b/include/uapi/linux/openvswitch.h
>>> index a0e9dde0584a..9d675725fa2b 100644
>>> --- a/include/uapi/linux/openvswitch.h
>>> +++ b/include/uapi/linux/openvswitch.h
>>> @@ -649,7 +649,8 @@ enum ovs_flow_attr {
>>> * Actions are passed as nested attributes.
>>> *
>>> * Executes the specified actions with the given probability on a
>>> per-packet
>>> - * basis.
>>> + * basis. Nested actions will be able to access the probability value of
>>> the
>>> + * parent @OVS_ACTION_ATTR_SAMPLE.
>>> */
>>> enum ovs_sample_attr {
>>> OVS_SAMPLE_ATTR_UNSPEC,
>>> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
>>> index 3b4dba0ded59..33f6d93ba5e4 100644
>>> --- a/net/openvswitch/actions.c
>>> +++ b/net/openvswitch/actions.c
>>> @@ -1048,12 +1048,15 @@ static int sample(struct datapath *dp, struct
>>> sk_buff *skb,
>>> struct nlattr *sample_arg;
>>> int rem = nla_len(attr);
>>> const struct sample_arg *arg;
>>> + u32 init_probability;
>>> bool clone_flow_key;
>>> + int err;
>>>
>>> /* The first action is always 'OVS_SAMPLE_ATTR_ARG'. */
>>> sample_arg = nla_data(attr);
>>> arg = nla_data(sample_arg);
>>> actions = nla_next(sample_arg, );
>>> + init_probability = OVS_CB(skb)->probability;
>>>
>>> if ((arg->probability != U32_MAX) &&
>>> (!arg->probability || get_random_u32() > arg->probability)) {
>>> @@ -1062,9 +1065,21 @@ static int sample(struct datapath *dp, struct
>>> sk_buff *skb,
>>> return 0;
>>> }
>>>
>>> + if (init_probability) {
>>> + OVS_CB(skb)->probability = ((u64)OVS_CB(skb)->probability *
>>> + arg->probability / U32_MAX);
>>> + } else {
>>> + OVS_CB(skb)->probability = arg->probability;
>>> + }
>>> +
>>
>> I'm confused by this. Eventually, integer arithmetic will practically
>> guarantee that nested sample() calls will go to 0. So eventually, the
>> test above will be impossible to meet mathematically.
>>
>> OTOH, you could argue that a 1% of 50% is low anyway, but it still would
>> have a positive probability count, and still be possible for
>> get_random_u32() call to match.
>>
>
> Using OVS's probability semantics, we can express probabilities as low
> as (100/U32_MAX)% which is pretty low indeed. However, just because the
> probability of executing the action is low I don't think we should not
> report it.
>
> Rethinking the integer arithmetics, it's true that we should avoid
> hitting zero on the division, eg: nesting 6x 1% sampling rates will make
> the result be zero which will make probability restoration fail on the
> way back. Threrefore, the new probability should be at least 1.
>
>
>> I'm not sure about this particular change. Why do we need it?
>>
>
> Why do we need to propagate the probability down to nested "sample"
> actions? or why do we need to store the probability in the cb area in
> the first place?
>
> The former: Just for correctness as only storing the last one would be
> incorrect. Although I don't know of any use for nested "sample" actions.
I think, we can drop this for now. All the user interfaces specify
the probability per action. So, it should be fine to report the
probability of the action that emitted the sample without taking into
account the whole timeline of that packet. Besides, packet can leave
OVS and go back loosing the metadata, so it will not actually be a
full solution anyway. Single-action metadata is easier to define.
> The latter: To pass it down to psample so that sample receivers know how
> the sampling rate applied (and, e.g: do throughput estimations like OVS
> does with IPFIX).
>
>
>>> clone_flow_key = !arg->exec;
>>> - return clone_execute(dp, skb, key, 0, actions, rem, last,
>>> -clone_flow_key);
>>> + err = clone_execute(dp, skb, key, 0, actions, rem, last,
>>> + clone_flow_key);
>>> +
>>> + if (!last)
>>
>> Is this
Re: [ovs-dev] [PATCH net-next v2 6/9] net: openvswitch: store sampling probability in cb.
On Fri, Jun 14, 2024 at 12:55:59PM GMT, Aaron Conole wrote:
> Adrian Moreno writes:
>
> > The behavior of actions might not be the exact same if they are being
> > executed inside a nested sample action. Store the probability of the
> > parent sample action in the skb's cb area.
>
> What does that mean?
>
Emit action, for instance, needs the probability so that psample
consumers know what was the sampling rate applied. Also, the way we
should inform about packet drops (via kfree_skb_reason) changes (see
patch 7/9).
> > Use the probability in emit_sample to pass it down to psample.
> >
> > Signed-off-by: Adrian Moreno
> > ---
> > include/uapi/linux/openvswitch.h | 3 ++-
> > net/openvswitch/actions.c| 25 ++---
> > net/openvswitch/datapath.h | 3 +++
> > net/openvswitch/vport.c | 1 +
> > 4 files changed, 28 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/uapi/linux/openvswitch.h
> > b/include/uapi/linux/openvswitch.h
> > index a0e9dde0584a..9d675725fa2b 100644
> > --- a/include/uapi/linux/openvswitch.h
> > +++ b/include/uapi/linux/openvswitch.h
> > @@ -649,7 +649,8 @@ enum ovs_flow_attr {
> > * Actions are passed as nested attributes.
> > *
> > * Executes the specified actions with the given probability on a
> > per-packet
> > - * basis.
> > + * basis. Nested actions will be able to access the probability value of
> > the
> > + * parent @OVS_ACTION_ATTR_SAMPLE.
> > */
> > enum ovs_sample_attr {
> > OVS_SAMPLE_ATTR_UNSPEC,
> > diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> > index 3b4dba0ded59..33f6d93ba5e4 100644
> > --- a/net/openvswitch/actions.c
> > +++ b/net/openvswitch/actions.c
> > @@ -1048,12 +1048,15 @@ static int sample(struct datapath *dp, struct
> > sk_buff *skb,
> > struct nlattr *sample_arg;
> > int rem = nla_len(attr);
> > const struct sample_arg *arg;
> > + u32 init_probability;
> > bool clone_flow_key;
> > + int err;
> >
> > /* The first action is always 'OVS_SAMPLE_ATTR_ARG'. */
> > sample_arg = nla_data(attr);
> > arg = nla_data(sample_arg);
> > actions = nla_next(sample_arg, );
> > + init_probability = OVS_CB(skb)->probability;
> >
> > if ((arg->probability != U32_MAX) &&
> > (!arg->probability || get_random_u32() > arg->probability)) {
> > @@ -1062,9 +1065,21 @@ static int sample(struct datapath *dp, struct
> > sk_buff *skb,
> > return 0;
> > }
> >
> > + if (init_probability) {
> > + OVS_CB(skb)->probability = ((u64)OVS_CB(skb)->probability *
> > + arg->probability / U32_MAX);
> > + } else {
> > + OVS_CB(skb)->probability = arg->probability;
> > + }
> > +
>
> I'm confused by this. Eventually, integer arithmetic will practically
> guarantee that nested sample() calls will go to 0. So eventually, the
> test above will be impossible to meet mathematically.
>
> OTOH, you could argue that a 1% of 50% is low anyway, but it still would
> have a positive probability count, and still be possible for
> get_random_u32() call to match.
>
Using OVS's probability semantics, we can express probabilities as low
as (100/U32_MAX)% which is pretty low indeed. However, just because the
probability of executing the action is low I don't think we should not
report it.
Rethinking the integer arithmetics, it's true that we should avoid
hitting zero on the division, eg: nesting 6x 1% sampling rates will make
the result be zero which will make probability restoration fail on the
way back. Threrefore, the new probability should be at least 1.
> I'm not sure about this particular change. Why do we need it?
>
Why do we need to propagate the probability down to nested "sample"
actions? or why do we need to store the probability in the cb area in
the first place?
The former: Just for correctness as only storing the last one would be
incorrect. Although I don't know of any use for nested "sample" actions.
The latter: To pass it down to psample so that sample receivers know how
the sampling rate applied (and, e.g: do throughput estimations like OVS
does with IPFIX).
> > clone_flow_key = !arg->exec;
> > - return clone_execute(dp, skb, key, 0, actions, rem, last,
> > -clone_flow_key);
> > + err = clone_execute(dp, skb, key, 0, actions, rem, last,
> > + clone_flow_key);
> > +
> > + if (!last)
>
> Is this right? Don't we only want to set the probability on the last
> action? Should the test be 'if (last)'?
>
This is restoring the parent's probability after the actions in the
current sample action have been executed.
If it was the last action there is no need to restore the probability
back to the parent's (or zero if it's there's only one level) since no
further action will require it. And more importantly, if it's the last
action, the packet gets free'ed inside that "branch" so we must not
access its memory.
> > +
Re: [ovs-dev] [PATCH net-next v2 6/9] net: openvswitch: store sampling probability in cb.
Adrian Moreno writes:
> The behavior of actions might not be the exact same if they are being
> executed inside a nested sample action. Store the probability of the
> parent sample action in the skb's cb area.
What does that mean?
> Use the probability in emit_sample to pass it down to psample.
>
> Signed-off-by: Adrian Moreno
> ---
> include/uapi/linux/openvswitch.h | 3 ++-
> net/openvswitch/actions.c| 25 ++---
> net/openvswitch/datapath.h | 3 +++
> net/openvswitch/vport.c | 1 +
> 4 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/openvswitch.h
> b/include/uapi/linux/openvswitch.h
> index a0e9dde0584a..9d675725fa2b 100644
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -649,7 +649,8 @@ enum ovs_flow_attr {
> * Actions are passed as nested attributes.
> *
> * Executes the specified actions with the given probability on a per-packet
> - * basis.
> + * basis. Nested actions will be able to access the probability value of the
> + * parent @OVS_ACTION_ATTR_SAMPLE.
> */
> enum ovs_sample_attr {
> OVS_SAMPLE_ATTR_UNSPEC,
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index 3b4dba0ded59..33f6d93ba5e4 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c
> @@ -1048,12 +1048,15 @@ static int sample(struct datapath *dp, struct sk_buff
> *skb,
> struct nlattr *sample_arg;
> int rem = nla_len(attr);
> const struct sample_arg *arg;
> + u32 init_probability;
> bool clone_flow_key;
> + int err;
>
> /* The first action is always 'OVS_SAMPLE_ATTR_ARG'. */
> sample_arg = nla_data(attr);
> arg = nla_data(sample_arg);
> actions = nla_next(sample_arg, );
> + init_probability = OVS_CB(skb)->probability;
>
> if ((arg->probability != U32_MAX) &&
> (!arg->probability || get_random_u32() > arg->probability)) {
> @@ -1062,9 +1065,21 @@ static int sample(struct datapath *dp, struct sk_buff
> *skb,
> return 0;
> }
>
> + if (init_probability) {
> + OVS_CB(skb)->probability = ((u64)OVS_CB(skb)->probability *
> + arg->probability / U32_MAX);
> + } else {
> + OVS_CB(skb)->probability = arg->probability;
> + }
> +
I'm confused by this. Eventually, integer arithmetic will practically
guarantee that nested sample() calls will go to 0. So eventually, the
test above will be impossible to meet mathematically.
OTOH, you could argue that a 1% of 50% is low anyway, but it still would
have a positive probability count, and still be possible for
get_random_u32() call to match.
I'm not sure about this particular change. Why do we need it?
> clone_flow_key = !arg->exec;
> - return clone_execute(dp, skb, key, 0, actions, rem, last,
> - clone_flow_key);
> + err = clone_execute(dp, skb, key, 0, actions, rem, last,
> + clone_flow_key);
> +
> + if (!last)
Is this right? Don't we only want to set the probability on the last
action? Should the test be 'if (last)'?
> + OVS_CB(skb)->probability = init_probability;
> +
> + return err;
> }
>
> /* When 'last' is true, clone() should always consume the 'skb'.
> @@ -1313,6 +1328,7 @@ static int execute_emit_sample(struct datapath *dp,
> struct sk_buff *skb,
> struct psample_metadata md = {};
> struct vport *input_vport;
> const struct nlattr *a;
> + u32 rate;
> int rem;
>
> for (a = nla_data(attr), rem = nla_len(attr); rem > 0;
> @@ -1337,8 +1353,11 @@ static int execute_emit_sample(struct datapath *dp,
> struct sk_buff *skb,
>
> md.in_ifindex = input_vport->dev->ifindex;
> md.trunc_size = skb->len - OVS_CB(skb)->cutlen;
> + md.rate_as_probability = 1;
> +
> + rate = OVS_CB(skb)->probability ? OVS_CB(skb)->probability : U32_MAX;
>
> - psample_sample_packet(_group, skb, 0, );
> + psample_sample_packet(_group, skb, rate, );
> #endif
>
> return 0;
> diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
> index 0cd29971a907..9ca6231ea647 100644
> --- a/net/openvswitch/datapath.h
> +++ b/net/openvswitch/datapath.h
> @@ -115,12 +115,15 @@ struct datapath {
> * fragmented.
> * @acts_origlen: The netlink size of the flow actions applied to this skb.
> * @cutlen: The number of bytes from the packet end to be removed.
> + * @probability: The sampling probability that was applied to this skb; 0
> means
> + * no sampling has occurred; U32_MAX means 100% probability.
> */
> struct ovs_skb_cb {
> struct vport*input_vport;
> u16 mru;
> u16 acts_origlen;
> u32 cutlen;
> + u32 probability;
> };
> #define OVS_CB(skb) ((struct ovs_skb_cb *)(skb)->cb)
Re: [ovs-dev] [PATCH net-next v2 6/9] net: openvswitch: store sampling probability in cb.
On Tue, Jun 04, 2024 at 04:49:39PM GMT, kernel test robot wrote: > Hi Adrian, > > kernel test robot noticed the following build errors: > > [auto build test ERROR on net-next/main] > > url: > https://github.com/intel-lab-lkp/linux/commits/Adrian-Moreno/net-psample-add-user-cookie/20240604-030055 > base: net-next/main > patch link: > https://lore.kernel.org/r/20240603185647.2310748-7-amorenoz%40redhat.com > patch subject: [PATCH net-next v2 6/9] net: openvswitch: store sampling > probability in cb. > config: m68k-allyesconfig > (https://download.01.org/0day-ci/archive/20240604/202406041623.ycwsup85-...@intel.com/config) > compiler: m68k-linux-gcc (GCC) 13.2.0 > reproduce (this is a W=1 build): > (https://download.01.org/0day-ci/archive/20240604/202406041623.ycwsup85-...@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version > of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot > | Closes: > https://lore.kernel.org/oe-kbuild-all/202406041623.ycwsup85-...@intel.com/ > > All errors (new ones prefixed by >>): > >m68k-linux-ld: net/openvswitch/actions.o: in function `do_execute_actions': > >> actions.c:(.text+0x214e): undefined reference to `__udivdi3' > I forgot about architectures that don't have native u64 division. I will use "do_div" in the next version of the series. > -- > 0-DAY CI Kernel Test Service > https://github.com/intel/lkp-tests/wiki > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net-next v2 6/9] net: openvswitch: store sampling probability in cb.
Hi Adrian, kernel test robot noticed the following build errors: [auto build test ERROR on net-next/main] url: https://github.com/intel-lab-lkp/linux/commits/Adrian-Moreno/net-psample-add-user-cookie/20240604-030055 base: net-next/main patch link: https://lore.kernel.org/r/20240603185647.2310748-7-amorenoz%40redhat.com patch subject: [PATCH net-next v2 6/9] net: openvswitch: store sampling probability in cb. config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20240604/202406041623.ycwsup85-...@intel.com/config) compiler: m68k-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240604/202406041623.ycwsup85-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202406041623.ycwsup85-...@intel.com/ All errors (new ones prefixed by >>): m68k-linux-ld: net/openvswitch/actions.o: in function `do_execute_actions': >> actions.c:(.text+0x214e): undefined reference to `__udivdi3' -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net-next v2 6/9] net: openvswitch: store sampling probability in cb.
Hi Adrian, kernel test robot noticed the following build errors: [auto build test ERROR on net-next/main] url: https://github.com/intel-lab-lkp/linux/commits/Adrian-Moreno/net-psample-add-user-cookie/20240604-030055 base: net-next/main patch link: https://lore.kernel.org/r/20240603185647.2310748-7-amorenoz%40redhat.com patch subject: [PATCH net-next v2 6/9] net: openvswitch: store sampling probability in cb. config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20240604/202406041339.ytdrh41v-...@intel.com/config) compiler: m68k-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240604/202406041339.ytdrh41v-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202406041339.ytdrh41v-...@intel.com/ All errors (new ones prefixed by >>, old ones prefixed by <<): WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-zydacron.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-viewsonic.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-waltop.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-winwing.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/of/of_test.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/fbtft/fbtft.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-bootrom.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-spilib.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-hid.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-light.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-log.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-loopback.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-power-supply.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-raw.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-vibrator.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-audio-manager.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-gbphy.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-gpio.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-i2c.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-pwm.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-sdio.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-spi.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-uart.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/staging/greybus/gb-usb.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/platform/goldfish/goldfish_pipe.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/platform/chrome/cros_kunit_proto_test.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/mailbox/mtk-cmdq-mailbox.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_simpleondemand.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_performance.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_powersave.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/devfreq/governor_userspace.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hwtracing/intel_th/intel_th_msu_sink.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/nvmem/nvmem-apple-efuses.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/nvmem/nvmem_brcm_nvram.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/nvmem/nvmem_u-boot-env.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/interconnect/imx/imx-interconnect.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/interconnect/imx/imx8mm-interconnect.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/interconnect/imx/imx8mq-interconnect.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/interconnect/imx/imx8mn-interconnect.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/interconnect/imx/imx8mp-interconnect.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hte/hte-tegra194-test.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/vdpa/vdpa.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/parport/parport.o WARNING: modpost: drivers/parport/parport_amiga: section mismatch in reference: amiga_parallel_driver+0x8 (section: .data) -> amiga_parallel_remove (section: .exit.text) WARNING: modpost: missing MODULE_DESCRIPTION() in
[ovs-dev] [PATCH net-next v2 6/9] net: openvswitch: store sampling probability in cb.
The behavior of actions might not be the exact same if they are being
executed inside a nested sample action. Store the probability of the
parent sample action in the skb's cb area.
Use the probability in emit_sample to pass it down to psample.
Signed-off-by: Adrian Moreno
---
include/uapi/linux/openvswitch.h | 3 ++-
net/openvswitch/actions.c| 25 ++---
net/openvswitch/datapath.h | 3 +++
net/openvswitch/vport.c | 1 +
4 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index a0e9dde0584a..9d675725fa2b 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -649,7 +649,8 @@ enum ovs_flow_attr {
* Actions are passed as nested attributes.
*
* Executes the specified actions with the given probability on a per-packet
- * basis.
+ * basis. Nested actions will be able to access the probability value of the
+ * parent @OVS_ACTION_ATTR_SAMPLE.
*/
enum ovs_sample_attr {
OVS_SAMPLE_ATTR_UNSPEC,
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 3b4dba0ded59..33f6d93ba5e4 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -1048,12 +1048,15 @@ static int sample(struct datapath *dp, struct sk_buff
*skb,
struct nlattr *sample_arg;
int rem = nla_len(attr);
const struct sample_arg *arg;
+ u32 init_probability;
bool clone_flow_key;
+ int err;
/* The first action is always 'OVS_SAMPLE_ATTR_ARG'. */
sample_arg = nla_data(attr);
arg = nla_data(sample_arg);
actions = nla_next(sample_arg, );
+ init_probability = OVS_CB(skb)->probability;
if ((arg->probability != U32_MAX) &&
(!arg->probability || get_random_u32() > arg->probability)) {
@@ -1062,9 +1065,21 @@ static int sample(struct datapath *dp, struct sk_buff
*skb,
return 0;
}
+ if (init_probability) {
+ OVS_CB(skb)->probability = ((u64)OVS_CB(skb)->probability *
+ arg->probability / U32_MAX);
+ } else {
+ OVS_CB(skb)->probability = arg->probability;
+ }
+
clone_flow_key = !arg->exec;
- return clone_execute(dp, skb, key, 0, actions, rem, last,
-clone_flow_key);
+ err = clone_execute(dp, skb, key, 0, actions, rem, last,
+ clone_flow_key);
+
+ if (!last)
+ OVS_CB(skb)->probability = init_probability;
+
+ return err;
}
/* When 'last' is true, clone() should always consume the 'skb'.
@@ -1313,6 +1328,7 @@ static int execute_emit_sample(struct datapath *dp,
struct sk_buff *skb,
struct psample_metadata md = {};
struct vport *input_vport;
const struct nlattr *a;
+ u32 rate;
int rem;
for (a = nla_data(attr), rem = nla_len(attr); rem > 0;
@@ -1337,8 +1353,11 @@ static int execute_emit_sample(struct datapath *dp,
struct sk_buff *skb,
md.in_ifindex = input_vport->dev->ifindex;
md.trunc_size = skb->len - OVS_CB(skb)->cutlen;
+ md.rate_as_probability = 1;
+
+ rate = OVS_CB(skb)->probability ? OVS_CB(skb)->probability : U32_MAX;
- psample_sample_packet(_group, skb, 0, );
+ psample_sample_packet(_group, skb, rate, );
#endif
return 0;
diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
index 0cd29971a907..9ca6231ea647 100644
--- a/net/openvswitch/datapath.h
+++ b/net/openvswitch/datapath.h
@@ -115,12 +115,15 @@ struct datapath {
* fragmented.
* @acts_origlen: The netlink size of the flow actions applied to this skb.
* @cutlen: The number of bytes from the packet end to be removed.
+ * @probability: The sampling probability that was applied to this skb; 0 means
+ * no sampling has occurred; U32_MAX means 100% probability.
*/
struct ovs_skb_cb {
struct vport*input_vport;
u16 mru;
u16 acts_origlen;
u32 cutlen;
+ u32 probability;
};
#define OVS_CB(skb) ((struct ovs_skb_cb *)(skb)->cb)
diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 972ae01a70f7..8732f6e51ae5 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -500,6 +500,7 @@ int ovs_vport_receive(struct vport *vport, struct sk_buff
*skb,
OVS_CB(skb)->input_vport = vport;
OVS_CB(skb)->mru = 0;
OVS_CB(skb)->cutlen = 0;
+ OVS_CB(skb)->probability = 0;
if (unlikely(dev_net(skb->dev) != ovs_dp_get_net(vport->dp))) {
u32 mark;
--
2.45.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
