sflow: add feature-arc at error-drop, drop-monitoring, egress-sampling

sflow: add feature-arc at error-drop, drop-monitoring, egress-sampling

(First submitted as two separate commits, but is now one).

This turns the "error-drop" --> "drop" arc into a feature-arc
so that any plugin can insert a step and examine condemned packets
before they are freed. The immediate goal is for the sflow
plugin to be able export the headers of dropped packets to the sflow
collector, as per the sflow standard. However it seems clear that the
existing pcap-drop code could also be moved to a plugin, which
would help to simplify the core vnet/interface_output.c.

The sflow agent is rounded out to support egress-sampling and
packet-drop monitoring.  The egress-sampling is achieved by
inserting a node on the interface-output feature arc. Packet
samples taken here are forwarded on the same FIFO to the
main thread, but marked as egress samples so that the samples
are written to a separate netlink PSAMPLE group number, which
indicated to hsflowd that these are egress samples.

Note that when you random-sample both ingress and egress packets at
1:N it is statistically the same as if you were sampling ingress packets
at 1:N and egress packets at 1:N independently. The sflow standard
does not allow a different value of N for ingress and egress on
the same interface, so we are free to take advantage of this.

The new node on the newly introduced "error-drop" feature-arc is
responsible for passing the headers of dropped packets to the main
thread too.  These are not sampled.  Instead we use a deliberately
shallow FIFO to ensure that under chronic conditions of high
packet loss these discard events will have negligible impact if
the main thread is not servicing the FIFO. The sflow standard
sets a rate-limit for the export of discard events which will
almost certainly be much lower (typically around 100 per second)
so even if we can only sustain a peak of, say, 1000 per second being
written to netlink DROPMON that is more than enough. The hsflowd
mod_dropmon will apply the configured sflow rate-limit and throw
away the excess messages before they are actually sent to the sflow
collector. For this reason it is not considered necessary for the
vpp CLI to set an explicit rate-limit.

The netlink PSAMPLE, DROPMON and USERSOCK code has been factored
and corrected for style, but the new implementation behaves the
same way in that there is no heap allocation, and iovectors are
used to assemble the netlink messages from their headers and
attributes.

New tests are added to confirm that (1) a single dropped packet is
delivered to the sflow_drop node, send to the DROPMON
netlink channel, and counted correctly when sflow drop-monitoring
is enabled, and that (2) when bidirectional packet-sampling is
enabled samples are taken both at ingress and at egress.

The terms "rx" for ingress, "tx" for egress and "both" for
bidrectional were settled on for brevity and because they appear
elsewhere in VPP, however the code still uses terms like
"ingress", "egress" and "bidirectional" to be consistent with
sFlow standard documents.

The new CLI options are:

vpp> sflow drop-monitoring enable|disable
vpp> sflow direction rx|tx|both

And the "show sflow" output has been enhanced to reflect this.
The defaults are as follows:

vpp> show sflow
show sflow
sflow sampling-rate 10000
sflow direction rx
sflow polling-interval 20
sflow header-bytes 128
sflow drop-monitoring disable
Status
  interfaces enabled: 0
  packet samples sent: 0
  packet samples dropped: 0
  counter samples sent: 0
  counter samples dropped: 0
  drop samples sent: 0
  drop samples dropped: 0

(rebased on 5/12/2025)

Type: improvement
Change-Id: I831e803fa41874965bc9c32516f655b7ae837719
Signed-off-by: Neil McKee <[email protected]>