[RFC,net-next,v2,0/5] net: openvswitch: Add sample multicasting.

Message

Adrián Moreno April 8, 2024, 12:57 p.m. UTC

** Background **
Currently, OVS supports several packet sampling mechanisms (sFlow,
per-bridge IPFIX, per-flow IPFIX). These end up being translated into a
userspace action that needs to be handled by ovs-vswitchd's handler
threads only to be forwarded to some third party application that
will somehow process the sample and provide observability on the
datapath.

A particularly interesting use-case is controller-driven
per-flow IPFIX sampling where the OpenFlow controller can add metadata
to samples (via two 32bit integers) and this metadata is then available
to the sample-collecting system for correlation.

** Problem **
The fact that sampled traffic share netlink sockets and handler thread
time with upcalls, apart from being a performance bottleneck in the
sample extraction itself, can severely compromise the datapath,
yielding this solution unfit for highly loaded production systems.

Users are left with little options other than guessing what sampling
rate will be OK for their traffic pattern and system load and dealing
with the lost accuracy.

Looking at available infrastructure, an obvious candidated would be
to use psample. However, it's current state does not help with the
use-case at stake because sampled packets do not contain user-defined
metadata.

** Proposal **
In this RFC_v2, I'd like to request feedback on an attempt to fix this
situation by:

- Extending the existing psample infrastructure to carry a variable
length user-defined cookie.
- Extending the tc act_sample action to use the actions' cookie as
psample metadata.
- Extending the OVS sample action with an attribute
(OVS_SAMPLE_ATTR_PSAMPLE) that contains a u32 group_id and a variable
length cookie and use the the psample infrastructure to multicast
the sample.
- Extending psample to allow group_id filtering on listening sockets so
that users can only receive samples they are interested in.

--
rfc_v1 -> rfc_v2:
- Use psample instead of a new OVS-only multicast group.
- Extend psample and tc with a user-defined cookie.


Adrian Moreno (5):
  net: netlink: export genl private pointer getters
  net: psample: add multicast filtering on group_id
  net: psample: add user cookie
  net:sched:act_sample: add action cookie to sample
  net:openvswitch: add psample support

 include/net/psample.h            |   2 +
 include/uapi/linux/openvswitch.h |  22 ++++-
 include/uapi/linux/psample.h     |   2 +
 net/netlink/genetlink.c          |   2 +
 net/openvswitch/actions.c        |  52 ++++++++++--
 net/openvswitch/datapath.c       |   2 +-
 net/openvswitch/flow_netlink.c   |  78 +++++++++++++----
 net/psample/psample.c            | 139 +++++++++++++++++++++++++++++--
 net/sched/act_sample.c           |  12 +++
 9 files changed, 277 insertions(+), 34 deletions(-)

Comments

Ilya Maximets April 8, 2024, 1:16 p.m. UTC | #1

On 4/8/24 14:57, Adrian Moreno wrote:
> ** Background **
> Currently, OVS supports several packet sampling mechanisms (sFlow,
> per-bridge IPFIX, per-flow IPFIX). These end up being translated into a
> userspace action that needs to be handled by ovs-vswitchd's handler
> threads only to be forwarded to some third party application that
> will somehow process the sample and provide observability on the
> datapath.
> 
> A particularly interesting use-case is controller-driven
> per-flow IPFIX sampling where the OpenFlow controller can add metadata
> to samples (via two 32bit integers) and this metadata is then available
> to the sample-collecting system for correlation.
> 
> ** Problem **
> The fact that sampled traffic share netlink sockets and handler thread
> time with upcalls, apart from being a performance bottleneck in the
> sample extraction itself, can severely compromise the datapath,
> yielding this solution unfit for highly loaded production systems.
> 
> Users are left with little options other than guessing what sampling
> rate will be OK for their traffic pattern and system load and dealing
> with the lost accuracy.
> 
> Looking at available infrastructure, an obvious candidated would be
> to use psample. However, it's current state does not help with the
> use-case at stake because sampled packets do not contain user-defined
> metadata.
> 
> ** Proposal **
> In this RFC_v2, I'd like to request feedback on an attempt to fix this
> situation by:
> 
> - Extending the existing psample infrastructure to carry a variable
> length user-defined cookie.
> - Extending the tc act_sample action to use the actions' cookie as
> psample metadata.
> - Extending the OVS sample action with an attribute
> (OVS_SAMPLE_ATTR_PSAMPLE) that contains a u32 group_id and a variable
> length cookie and use the the psample infrastructure to multicast
> the sample.
> - Extending psample to allow group_id filtering on listening sockets so
> that users can only receive samples they are interested in.
> 
> --
> rfc_v1 -> rfc_v2:
> - Use psample instead of a new OVS-only multicast group.
> - Extend psample and tc with a user-defined cookie.
> 
> 
> Adrian Moreno (5):
>   net: netlink: export genl private pointer getters
>   net: psample: add multicast filtering on group_id
>   net: psample: add user cookie
>   net:sched:act_sample: add action cookie to sample
>   net:openvswitch: add psample support
> 
>  include/net/psample.h            |   2 +
>  include/uapi/linux/openvswitch.h |  22 ++++-
>  include/uapi/linux/psample.h     |   2 +
>  net/netlink/genetlink.c          |   2 +
>  net/openvswitch/actions.c        |  52 ++++++++++--
>  net/openvswitch/datapath.c       |   2 +-
>  net/openvswitch/flow_netlink.c   |  78 +++++++++++++----
>  net/psample/psample.c            | 139 +++++++++++++++++++++++++++++--
>  net/sched/act_sample.c           |  12 +++
>  9 files changed, 277 insertions(+), 34 deletions(-)
> 

[copying my previous reply since this version actually has netdev@ in Cc]

Thanks, Adrian!

FWIW, I think this is a reasonable approach to the problem.

I won't do a full review since it's an RFC, but I'll leave some
comments for individual patches.

Best regards, Ilya Maximets.