Date: Thu, 27 Jun 2024 00:52:47 -0700
From: Adrián Moreno <amorenoz@...hat.com>
To: Eelco Chaudron <echaudro@...hat.com>
Cc: netdev@...r.kernel.org, aconole@...hat.com, horms@...nel.org, 
	i.maximets@....org, dev@...nvswitch.org, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Donald Hunter <donald.hunter@...il.com>, Pravin B Shelar <pshelar@....org>
Subject: Re: [PATCH net-next v5 05/10] net: openvswitch: add emit_sample action

On Thu, Jun 27, 2024 at 09:06:46AM GMT, Eelco Chaudron wrote:
>
>
> On 26 Jun 2024, at 22:34, Adrián Moreno wrote:
>
> > On Wed, Jun 26, 2024 at 04:28:17PM GMT, Eelco Chaudron wrote:
> >>
> >>
> >> On 25 Jun 2024, at 22:51, Adrian Moreno wrote:
> >>
> >>> Add support for a new action: emit_sample.
> >>>
> >>> This action accepts a u32 group id and a variable-length cookie and uses
> >>> the psample multicast group to make the packet available for
> >>> observability.
> >>>
> >>> The maximum length of the user-defined cookie is set to 16, same as
> >>> tc_cookie, to discourage using cookies that will not be offloadable.
> >>
> >> I’ll add the same comment as I had in the user space part, and that
> >> is that I feel from an OVS perspective this action should be called
> >> emit_local() instead of emit_sample() to make it Datapath independent.
> >> Or quoting the earlier comment:
> >>
> >>
> >> “I’ll start the discussion again on the naming. The name "emit_sample()"
> >> does not seem appropriate. This function's primary role is to copy the
> >> packet and send it to a local collector, which varies depending on the
> >> datapath. For the kernel datapath, this collector is psample, while for
> >> userspace, it will likely be some kind of probe. This action is distinct
> >> from the sample() action by design; it is a standalone action that can
> >> be combined with others.
> >>
> >> Furthermore, the action itself does not involve taking a sample; it
> >> consistently pushes the packet to the local collector. Therefore, I
> >> suggest renaming "emit_sample()" to "emit_local()". This same goes for
> >> all the derivative ATTR naming.”
> >>
> >
> > This is a blurry semantic area.
> > IMO, "sample" is the act of extracting (potentially a piece of)
> > someting, in this case, a packet. It is common to only take some packets
> > as samples, so this action usually comes with some kind of "rate", but
> > even if the rate is 1, it's still sampling in this context.
> >
> > OTOH, OVS kernel design tries to be super-modular and define small
> > combinable actions, so the rate or probability generation is done with
> > another action which is (IMHO unfortunately) named "sample".
> >
> > With that interpretation of the term it would actually make more sense
> > to rename "sample" to something like "random" (of course I'm not
> > suggestion we do it). "sample" without any nested action that actually
> > sends the packet somewhere is not sampling, it's just doing something or
> > not based on a probability. Where as "emit_sample" is sampling even if
> > it's not nested inside a "sample".
>
> You're assuming we are extracting a packet for sampling, but this function
> can be used for various other purposes. For instance, it could handle the
> packet outside of the OVS pipeline through an eBPF program (so we are not
> taking a sample, but continue packet processing outside of the OVS
> pipeline). Calling it emit_sampling() in such cases could be very
> confusing.
>

Well, I guess that would be clearly abusing the action. You could say
that of anything really. You could hook into skb_consume and continue
processing the skb but that doesn't change the intended behavior of the
drop action.

The intended behavior of the action is sampling, as is the intended
behavior of "psample".

> > Having said that, I don't have a super strong favor for "emit_sample". I'm
> > OK with "emit_local" or "emit_packet" or even just "emit".
> > I don't think any term will fully satisfy everyone so I hope we can find
> > a reasonable compromise.
>
> My preference would be emit_local() as we hand it off to some local
> datapath entity.
>

I'm OK removing the controversial term. Let's see what others think.

> >>> Signed-off-by: Adrian Moreno <amorenoz@...hat.com>
> >>> ---
> >>>  Documentation/netlink/specs/ovs_flow.yaml | 17 +++++++++
> >>>  include/uapi/linux/openvswitch.h          | 28 ++++++++++++++
> >>>  net/openvswitch/Kconfig                   |  1 +
> >>>  net/openvswitch/actions.c                 | 45 +++++++++++++++++++++++
> >>>  net/openvswitch/flow_netlink.c            | 33 ++++++++++++++++-
> >>>  5 files changed, 123 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/Documentation/netlink/specs/ovs_flow.yaml b/Documentation/netlink/specs/ovs_flow.yaml
> >>> index 4fdfc6b5cae9..a7ab5593a24f 100644
> >>> --- a/Documentation/netlink/specs/ovs_flow.yaml
> >>> +++ b/Documentation/netlink/specs/ovs_flow.yaml
> >>> @@ -727,6 +727,12 @@ attribute-sets:
> >>>          name: dec-ttl
> >>>          type: nest
> >>>          nested-attributes: dec-ttl-attrs
> >>> +      -
> >>> +        name: emit-sample
> >>> +        type: nest
> >>> +        nested-attributes: emit-sample-attrs
> >>> +        doc: |
> >>> +          Sends a packet sample to psample for external observation.
> >>>    -
> >>>      name: tunnel-key-attrs
> >>>      enum-name: ovs-tunnel-key-attr
> >>> @@ -938,6 +944,17 @@ attribute-sets:
> >>>        -
> >>>          name: gbp
> >>>          type: u32
> >>> +  -
> >>> +    name: emit-sample-attrs
> >>> +    enum-name: ovs-emit-sample-attr
> >>> +    name-prefix: ovs-emit-sample-attr-
> >>> +    attributes:
> >>> +      -
> >>> +        name: group
> >>> +        type: u32
> >>> +      -
> >>> +        name: cookie
> >>> +        type: binary
> >>>
> >>>  operations:
> >>>    name-prefix: ovs-flow-cmd-
> >>> diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
> >>> index efc82c318fa2..8cfa1b3f6b06 100644
> >>> --- a/include/uapi/linux/openvswitch.h
> >>> +++ b/include/uapi/linux/openvswitch.h
> >>> @@ -914,6 +914,31 @@ struct check_pkt_len_arg {
> >>>  };
> >>>  #endif
> >>>
> >>> +#define OVS_EMIT_SAMPLE_COOKIE_MAX_SIZE 16
> >>> +/**
> >>> + * enum ovs_emit_sample_attr - Attributes for %OVS_ACTION_ATTR_EMIT_SAMPLE
> >>> + * action.
> >>> + *
> >>> + * @OVS_EMIT_SAMPLE_ATTR_GROUP: 32-bit number to identify the source of the
> >>> + * sample.
> >>> + * @OVS_EMIT_SAMPLE_ATTR_COOKIE: A variable-length binary cookie that contains
> >>> + * user-defined metadata. The maximum length is OVS_EMIT_SAMPLE_COOKIE_MAX_SIZE
> >>> + * bytes.
> >>> + *
> >>> + * Sends the packet to the psample multicast group with the specified group and
> >>> + * cookie. It is possible to combine this action with the
> >>> + * %OVS_ACTION_ATTR_TRUNC action to limit the size of the packet being emitted.
> >>
> >> Although this include file is kernel-related, it will probably be re-used for
> >> other datapaths, so should we be more general here?
> >>
> >
> > The uAPI header documentation will be used for other datapaths? How so?
> > At some point we should document what the action does from the kernel
> > pov, right? Where should we do that if not here?
>
> Well you know how OVS works, all the data paths use the same netlink messages. Not sure how to solve this, but we could change the text a bit to be more general?
>
>  * For the Linux kernel it sends the packet to the psample multicast group
>  * with the specified group and cookie. It is possible to combine this
>  * action with the %OVS_ACTION_ATTR_TRUNC action to limit the size of the
>  * packet being emitted.
>

I know we reuse the kernel attributes I don't think the uAPI
documentation should be less expressive just because some userspace
application decides to reuse parts of it.

There are many kernel-specific terms all over the uAPI ("netdev",
"netlink pid", "skb", even the action "userspace") that do not make
sense in a non-kernel datapath.

Maybe we can add such a comment in the copy of the header we store in
the ovs tree?


> >>> + */
> >>> +enum ovs_emit_sample_attr {
> >>> +	OVS_EMIT_SAMPLE_ATTR_GROUP = 1,	/* u32 number. */
> >>> +	OVS_EMIT_SAMPLE_ATTR_COOKIE,	/* Optional, user specified cookie. */
> >>
> >> As we start a new set of attributes maybe it would be good starting it off in
> >> alphabetical order?
> >>
> >
> > Having an optional attribute before a mandatory one seems strange to me,
> > wouldn't you agree?
>
> I don't mind, but I don't have a strong opinion on it. If others don't mind,
> I would leave it as is.
>

I think I prefer to put mandatory attributes first.

> >>> +
> >>> +	/* private: */
> >>> +	__OVS_EMIT_SAMPLE_ATTR_MAX
> >>> +};
> >>> +
> >>> +#define OVS_EMIT_SAMPLE_ATTR_MAX (__OVS_EMIT_SAMPLE_ATTR_MAX - 1)
> >>> +
> >>>  /**
> >>>   * enum ovs_action_attr - Action types.
> >>>   *
> >>> @@ -966,6 +991,8 @@ struct check_pkt_len_arg {
> >>>   * of l3 tunnel flag in the tun_flags field of OVS_ACTION_ATTR_ADD_MPLS
> >>>   * argument.
> >>>   * @OVS_ACTION_ATTR_DROP: Explicit drop action.
> >>> + * @OVS_ACTION_ATTR_EMIT_SAMPLE: Send a sample of the packet to external
> >>> + * observers via psample.
>
> * @OVS_ACTION_ATTR_EMIT_SAMPLE: Send a sample of the packet to a data path
> * local observer.
>
> >>>   *
> >>>   * Only a single header can be set with a single %OVS_ACTION_ATTR_SET.  Not all
> >>>   * fields within a header are modifiable, e.g. the IPv4 protocol and fragment
> >>> @@ -1004,6 +1031,7 @@ enum ovs_action_attr {
> >>>  	OVS_ACTION_ATTR_ADD_MPLS,     /* struct ovs_action_add_mpls. */
> >>>  	OVS_ACTION_ATTR_DEC_TTL,      /* Nested OVS_DEC_TTL_ATTR_*. */
> >>>  	OVS_ACTION_ATTR_DROP,         /* u32 error code. */
> >>> +	OVS_ACTION_ATTR_EMIT_SAMPLE,  /* Nested OVS_EMIT_SAMPLE_ATTR_*. */
> >>>
> >>>  	__OVS_ACTION_ATTR_MAX,	      /* Nothing past this will be accepted
> >>>  				       * from userspace. */
> >>> diff --git a/net/openvswitch/Kconfig b/net/openvswitch/Kconfig
> >>> index 29a7081858cd..2535f3f9f462 100644
> >>> --- a/net/openvswitch/Kconfig
> >>> +++ b/net/openvswitch/Kconfig
> >>> @@ -10,6 +10,7 @@ config OPENVSWITCH
> >>>  		   (NF_CONNTRACK && ((!NF_DEFRAG_IPV6 || NF_DEFRAG_IPV6) && \
> >>>  				     (!NF_NAT || NF_NAT) && \
> >>>  				     (!NETFILTER_CONNCOUNT || NETFILTER_CONNCOUNT)))
> >>> +	depends on PSAMPLE || !PSAMPLE
> >>>  	select LIBCRC32C
> >>>  	select MPLS
> >>>  	select NET_MPLS_GSO
> >>> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> >>> index 964225580824..1f555cbba312 100644
> >>> --- a/net/openvswitch/actions.c
> >>> +++ b/net/openvswitch/actions.c
> >>> @@ -24,6 +24,11 @@
> >>>  #include <net/checksum.h>
> >>>  #include <net/dsfield.h>
> >>>  #include <net/mpls.h>
> >>> +
> >>> +#if IS_ENABLED(CONFIG_PSAMPLE)
> >>> +#include <net/psample.h>
> >>> +#endif
> >>> +
> >>>  #include <net/sctp/checksum.h>
> >>>
> >>>  #include "datapath.h"
> >>> @@ -1299,6 +1304,37 @@ static int execute_dec_ttl(struct sk_buff *skb, struct sw_flow_key *key)
> >>>  	return 0;
> >>>  }
> >>>
> >>> +static void execute_emit_sample(struct datapath *dp, struct sk_buff *skb,
> >>> +				const struct sw_flow_key *key,
> >>> +				const struct nlattr *attr)
> >>> +{
> >>> +#if IS_ENABLED(CONFIG_PSAMPLE)
> >>
> >> Same comment as Ilya on key and IS_ENABLED() over function.
> >>
> >>> +	struct psample_group psample_group = {};
> >>> +	struct psample_metadata md = {};
> >>> +	const struct nlattr *a;
> >>> +	int rem;
> >>> +
> >>> +	nla_for_each_attr(a, nla_data(attr), nla_len(attr), rem) {
> >>> +		switch (nla_type(a)) {
> >>> +		case OVS_EMIT_SAMPLE_ATTR_GROUP:
> >>> +			psample_group.group_num = nla_get_u32(a);
> >>> +			break;
> >>> +
> >>> +		case OVS_EMIT_SAMPLE_ATTR_COOKIE:
> >>> +			md.user_cookie = nla_data(a);
> >>> +			md.user_cookie_len = nla_len(a);
> >>
> >> Do we need to check for any max cookie length?
> >>
> >
> > I don't think so. validate_emit_sample() makes sure the attribute's
> > length within bounds and checking it in the fast path just in case
> > some other memory-corrupting bug has changed it seems an overkill.
>
> ACK
>
> >>> +			break;
> >>> +		}
> >>> +	}
> >>> +
> >>> +	psample_group.net = ovs_dp_get_net(dp);
> >>> +	md.in_ifindex = OVS_CB(skb)->input_vport->dev->ifindex;
> >>> +	md.trunc_size = skb->len - OVS_CB(skb)->cutlen;
> >>> +
> >>> +	psample_sample_packet(&psample_group, skb, 0, &md);
> >>> +#endif
> >>> +}
> >>> +
> >>>  /* Execute a list of actions against 'skb'. */
> >>>  static int do_execute_actions(struct datapath *dp, struct sk_buff *skb,
> >>>  			      struct sw_flow_key *key,
> >>> @@ -1502,6 +1538,15 @@ static int do_execute_actions(struct datapath *dp, struct sk_buff *skb,
> >>>  			ovs_kfree_skb_reason(skb, reason);
> >>>  			return 0;
> >>>  		}
> >>> +
> >>> +		case OVS_ACTION_ATTR_EMIT_SAMPLE:
> >>> +			execute_emit_sample(dp, skb, key, a);
> >>> +			OVS_CB(skb)->cutlen = 0;
> >>> +			if (nla_is_last(a, rem)) {
> >>> +				consume_skb(skb);
> >>> +				return 0;
> >>> +			}
> >>> +			break;
> >>>  		}
> >>>
> >>>  		if (unlikely(err)) {
> >>> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> >>> index f224d9bcea5e..29c8cdc44433 100644
> >>> --- a/net/openvswitch/flow_netlink.c
> >>> +++ b/net/openvswitch/flow_netlink.c
> >>> @@ -64,6 +64,7 @@ static bool actions_may_change_flow(const struct nlattr *actions)
> >>>  		case OVS_ACTION_ATTR_TRUNC:
> >>>  		case OVS_ACTION_ATTR_USERSPACE:
> >>>  		case OVS_ACTION_ATTR_DROP:
> >>> +		case OVS_ACTION_ATTR_EMIT_SAMPLE:
> >>>  			break;
> >>>
> >>>  		case OVS_ACTION_ATTR_CT:
> >>> @@ -2409,7 +2410,7 @@ static void ovs_nla_free_nested_actions(const struct nlattr *actions, int len)
> >>>  	/* Whenever new actions are added, the need to update this
> >>>  	 * function should be considered.
> >>>  	 */
> >>> -	BUILD_BUG_ON(OVS_ACTION_ATTR_MAX != 24);
> >>> +	BUILD_BUG_ON(OVS_ACTION_ATTR_MAX != 25);
> >>>
> >>>  	if (!actions)
> >>>  		return;
> >>> @@ -3157,6 +3158,29 @@ static int validate_and_copy_check_pkt_len(struct net *net,
> >>>  	return 0;
> >>>  }
> >>>
> >>> +static int validate_emit_sample(const struct nlattr *attr)
> >>> +{
> >>> +	static const struct nla_policy policy[OVS_EMIT_SAMPLE_ATTR_MAX + 1] = {
> >>> +		[OVS_EMIT_SAMPLE_ATTR_GROUP] = { .type = NLA_U32 },
> >>> +		[OVS_EMIT_SAMPLE_ATTR_COOKIE] = {
> >>> +			.type = NLA_BINARY,
> >>> +			.len = OVS_EMIT_SAMPLE_COOKIE_MAX_SIZE,
> >>> +		},
> >>> +	};
> >>> +	struct nlattr *a[OVS_EMIT_SAMPLE_ATTR_MAX + 1];
> >>> +	int err;
> >>> +
> >>> +	if (!IS_ENABLED(CONFIG_PSAMPLE))
> >>> +		return -EOPNOTSUPP;
> >>> +
> >>> +	err = nla_parse_nested(a, OVS_EMIT_SAMPLE_ATTR_MAX, attr, policy,
> >>> +			       NULL);
> >>> +	if (err)
> >>> +		return err;
> >>> +
> >>> +	return a[OVS_EMIT_SAMPLE_ATTR_GROUP] ? 0 : -EINVAL;
> >>
> >> So we are ok with not having a cookie? Did you inform Cookie Monster ;)
> >> Also, update the include help text to reflect this.
> >>
> >
> > You mean the uapi header? The enum is defined as:
> >
> > enum ovs_emit_sample_attr {
> > 	OVS_EMIT_SAMPLE_ATTR_GROUP = 1,	/* u32 number. */
> > 	OVS_EMIT_SAMPLE_ATTR_COOKIE,	/* Optional, user specified cookie. */
> >
> > Isn't that clear enough?
>
> Missed it as I was looking for it here:
>
> * @OVS_EMIT_SAMPLE_ATTR_COOKIE: A variable-length binary cookie that contains
> * user-defined metadata. The maximum length is OVS_EMIT_SAMPLE_COOKIE_MAX_SIZE
> * bytes.
>
> Maybe change it here too by adding option, “An optional variable-length binary cookie”?
>

Sure.

> >>> +}
> >>> +
> >>>  static int copy_action(const struct nlattr *from,
> >>>  		       struct sw_flow_actions **sfa, bool log)
> >>>  {
> >>> @@ -3212,6 +3236,7 @@ static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,
> >>>  			[OVS_ACTION_ATTR_ADD_MPLS] = sizeof(struct ovs_action_add_mpls),
> >>>  			[OVS_ACTION_ATTR_DEC_TTL] = (u32)-1,
> >>>  			[OVS_ACTION_ATTR_DROP] = sizeof(u32),
> >>> +			[OVS_ACTION_ATTR_EMIT_SAMPLE] = (u32)-1,
> >>>  		};
> >>>  		const struct ovs_action_push_vlan *vlan;
> >>>  		int type = nla_type(a);
> >>> @@ -3490,6 +3515,12 @@ static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,
> >>>  				return -EINVAL;
> >>>  			break;
> >>>
> >>> +		case OVS_ACTION_ATTR_EMIT_SAMPLE:
> >>> +			err = validate_emit_sample(a);
> >>> +			if (err)
> >>> +				return err;
> >>> +			break;
> >>> +
> >>>  		default:
> >>>  			OVS_NLERR(log, "Unknown Action type %d", type);
> >>>  			return -EINVAL;
> >>> --
> >>> 2.45.1
> >>
>

Powered by blists - more mailing lists