On 7/12/24 19:06, Adrian Moreno wrote:
> (Was: Add psample support to NXAST_SAMPLE action)
>
> This is the userspace counterpart of the work done in the kernel
> which has recently been merged in net-next [1]. There, a new
> datapath action is added, called "psample".
>
> From the PoV of ovs-vswitchd, this new action is used to implement
> "local sampling". Local sampling (or lsample for short) is configured
> in a similar way as current per-flow IPFIX sampling, i.e: using the
> Flow_Sample_Collector_Set table and the NXAST_SAMPLE action.
>
> However, instead of sending the sample to an external IPFIX collector
> though the network, the sample is emitted using the new action and
> made available to locally running sample collector.
>
> The specific way emit_sample sends the sample (and the way the local
> collector shall collect it) is datapath-specific.
> Currently, currently only the Linux kernel datapath implements it using
> the psample netlink multicast group.
>
> ~~ Configuration ~~
> Local sampling is configured via a new column in the
> Flow_Sample_Collector_Set (FSCS) table called "local_group_id".
> Configuring this value is orthogonal to also associating the FSCS
> entry to an entry in the IPFIX table.
>
> Once that entry in the OVSDB is configured, NXAST_SAMPLE actions coming
> from the controller will be translated into the following odp action:
>
> sample(sample={P}%, actions(emit_sample(group={G},cookie={C})))
>
> Where:
> P: Is the sampling probability from NXAST_SAMPLE
> G: Is the group id in the FSCS entry whose "id" matches the one in
> the NXAST_SAMPLE.
> C: Is a 64bit cookie result of concatenating the obs_domain and
> obs_point from the NXAST_SAMPLE in network order, i.e:
> "htonl(obs_domain) << 32 | htonl(obs_point)"
> Notes:
> - The parent sample action might be omitted if the probability is
> 100% and there is no IPFIX sampling that requires the use of a
> meter.
>
> ~~ Dpif-lsample ~~
> Internally, a new object called "dpif-lsample" is introduced to track
> the configured local sampling exporters and track statistics based on
> odp flow stats (using xcache).
> It exposes the list of configured exporters and their statistics on a
> new unixctl command called "lsample/show".
>
> ~~ Drop monitoring ~~
> A common use-case for this action can be to sample drops. However,
> adding sample actions to drops makes the existing drop statistics
> disappear. In order to fix this, patch 11 make use of explicit
> drop actions to ensure statistics still report drops even if sampled.
> /home/amorenoz/devel/patches/ovs/ovs_psample/v2/v2-0000-cover-letter.patch
> ~~ Extended OpenFlow sample action ~~
> Given the series aims at making sampling production ready, conntrack
> integration must be considered. A common use-case for state-full
> pipelines is to calculate the observation metadata at connection
> establishment, store it in ct_label and then use it for packets of
> established connections. However, this forces OVN to create a big number
> of OFP Flows (one per distinct cookie). Patch 13 solves this by allowing
> controllers to specify the obs_domain and point ids from another OFP
> field.
>
> ~~ Testing ~~
> The series includes an test utility program than can be executed by
> running "tests/ovstest test-psample". This utility listens
> to packets multicasted by the psample module and prints them (also
> printing the obs_domain and obs_point ids).
>
> ~~ HW Offload ~~
> tc offload is not being introduced in this series as existing sample
> or userspace actions are not currently offloadable. Also some
> improvements need to be implemented in tc for it to be feasible.
>
> ~~ DPDK datapath ~~
DPDK is not a datapath, it's a port type. :P
> By naming the action "psample" it was intentionally restricted to the
> Linux datapath only. A follow up task would be spawned to think of a
> good way of implementing local-sampling in the userspace datapath.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=aae0b82b46cb5004bdf82a000c004d69a0885c33
>
> ---
> * v2 -> v3
> - Added a knob to configure explicit sampled drops.
> - Addressed Eelco comments.
> - Rebased.
I went thought the set. Most of the comments are simple nits that I
could even fix myself on commit, but I'm not sure what to do with
patches 7 and 8 as I don't think we need to report incorrect stats
and there seem to be no real way to get correct ones.
Let me know what do you think.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
