2021-01-18 13:13:51 +01:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2021-01-26 18:34:23 +01:00
|
|
|
#ifndef PPING_H
|
|
|
|
#define PPING_H
|
|
|
|
|
2020-12-11 19:25:35 +01:00
|
|
|
#include <linux/types.h>
|
2021-02-08 20:28:46 +01:00
|
|
|
#include <linux/in6.h>
|
2021-06-22 15:22:11 +02:00
|
|
|
#include <stdbool.h>
|
2020-12-11 19:25:35 +01:00
|
|
|
|
2022-03-09 19:28:05 +01:00
|
|
|
#define NS_PER_SECOND 1000000000UL
|
|
|
|
#define NS_PER_MS 1000000UL
|
|
|
|
#define MS_PER_S 1000UL
|
2022-03-22 09:11:53 +01:00
|
|
|
#define S_PER_DAY (24 * 3600UL)
|
2022-03-09 19:28:05 +01:00
|
|
|
|
2022-02-10 16:11:21 +01:00
|
|
|
typedef __u64 fixpoint64;
|
|
|
|
#define FIXPOINT_SHIFT 16
|
|
|
|
#define DOUBLE_TO_FIXPOINT(X) ((fixpoint64)((X) * (1UL << FIXPOINT_SHIFT)))
|
|
|
|
#define FIXPOINT_TO_UINT(X) ((X) >> FIXPOINT_SHIFT)
|
|
|
|
|
2021-06-22 15:22:11 +02:00
|
|
|
/* For the event_type members of rtt_event and flow_event */
|
|
|
|
#define EVENT_TYPE_FLOW 1
|
|
|
|
#define EVENT_TYPE_RTT 2
|
2022-02-03 15:51:22 +01:00
|
|
|
#define EVENT_TYPE_MAP_FULL 3
|
2022-02-17 14:01:08 +01:00
|
|
|
#define EVENT_TYPE_MAP_CLEAN 4
|
2021-06-22 15:22:11 +02:00
|
|
|
|
|
|
|
enum __attribute__((__packed__)) flow_event_type {
|
2021-06-22 15:36:35 +02:00
|
|
|
FLOW_EVENT_NONE,
|
2021-06-22 15:22:11 +02:00
|
|
|
FLOW_EVENT_OPENING,
|
pping: Do both timestamping and matching on ingress and egress
Perform both timestamping and matching on both ingress and egress
hooks. This makes it more similar to Kathie's pping, allowing the tool
to capture RTTs in both directions when deployed on just a single
interface.
Like Kathie's pping, by default filter out RTTs for packets going to
the local machine (will only include local processing delays). This
behavior can be disabled by passing the -l/--include-local option.
As packets that are timestamped on ingress and matched on egress will
include the local machines processing delay, add the "match_on_egress"
member to the JSON output that can be used to differentiate between
RTTs that include the local processing delay, and those which don't.
Finally, report the source and destination addresses from the perspective
of the reply packet, rather than the timestamped packet, to be
consistent with Kathie's pping.
Overall, refactor large parts of pping_kern to allow both timestamping
and matching, as well as updating both the flow and reverse flow and
handle flow-events related to them, in one go. Also update README to
reflect changes.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2022-02-10 16:16:24 +01:00
|
|
|
FLOW_EVENT_CLOSING,
|
|
|
|
FLOW_EVENT_CLOSING_BOTH
|
2021-06-22 15:22:11 +02:00
|
|
|
};
|
|
|
|
|
2021-06-22 15:36:35 +02:00
|
|
|
enum __attribute__((__packed__)) flow_event_reason {
|
2022-03-22 13:24:09 +01:00
|
|
|
EVENT_REASON_NONE,
|
2021-06-22 15:22:11 +02:00
|
|
|
EVENT_REASON_SYN,
|
|
|
|
EVENT_REASON_SYN_ACK,
|
|
|
|
EVENT_REASON_FIRST_OBS_PCKT,
|
|
|
|
EVENT_REASON_FIN,
|
|
|
|
EVENT_REASON_RST,
|
|
|
|
EVENT_REASON_FLOW_TIMEOUT
|
|
|
|
};
|
|
|
|
|
2021-06-22 15:36:35 +02:00
|
|
|
enum __attribute__((__packed__)) flow_event_source {
|
pping: Do both timestamping and matching on ingress and egress
Perform both timestamping and matching on both ingress and egress
hooks. This makes it more similar to Kathie's pping, allowing the tool
to capture RTTs in both directions when deployed on just a single
interface.
Like Kathie's pping, by default filter out RTTs for packets going to
the local machine (will only include local processing delays). This
behavior can be disabled by passing the -l/--include-local option.
As packets that are timestamped on ingress and matched on egress will
include the local machines processing delay, add the "match_on_egress"
member to the JSON output that can be used to differentiate between
RTTs that include the local processing delay, and those which don't.
Finally, report the source and destination addresses from the perspective
of the reply packet, rather than the timestamped packet, to be
consistent with Kathie's pping.
Overall, refactor large parts of pping_kern to allow both timestamping
and matching, as well as updating both the flow and reverse flow and
handle flow-events related to them, in one go. Also update README to
reflect changes.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2022-02-10 16:16:24 +01:00
|
|
|
EVENT_SOURCE_PKT_SRC,
|
|
|
|
EVENT_SOURCE_PKT_DEST,
|
2022-03-09 19:28:05 +01:00
|
|
|
EVENT_SOURCE_GC
|
2021-06-22 15:36:35 +02:00
|
|
|
};
|
|
|
|
|
2022-02-03 15:51:22 +01:00
|
|
|
enum __attribute__((__packed__)) pping_map {
|
|
|
|
PPING_MAP_FLOWSTATE = 0,
|
|
|
|
PPING_MAP_PACKETTS
|
|
|
|
};
|
|
|
|
|
2022-03-30 17:40:54 +02:00
|
|
|
enum __attribute__((__packed__)) connection_state {
|
|
|
|
CONNECTION_STATE_EMPTY,
|
|
|
|
CONNECTION_STATE_WAITOPEN,
|
|
|
|
CONNECTION_STATE_OPEN,
|
|
|
|
CONNECTION_STATE_CLOSED
|
|
|
|
};
|
|
|
|
|
2021-04-15 14:13:54 +02:00
|
|
|
struct bpf_config {
|
2021-03-22 12:23:27 +01:00
|
|
|
__u64 rate_limit;
|
2022-02-10 16:11:21 +01:00
|
|
|
fixpoint64 rtt_rate;
|
|
|
|
bool use_srtt;
|
2022-02-02 11:38:53 +01:00
|
|
|
bool track_tcp;
|
|
|
|
bool track_icmp;
|
pping: Do both timestamping and matching on ingress and egress
Perform both timestamping and matching on both ingress and egress
hooks. This makes it more similar to Kathie's pping, allowing the tool
to capture RTTs in both directions when deployed on just a single
interface.
Like Kathie's pping, by default filter out RTTs for packets going to
the local machine (will only include local processing delays). This
behavior can be disabled by passing the -l/--include-local option.
As packets that are timestamped on ingress and matched on egress will
include the local machines processing delay, add the "match_on_egress"
member to the JSON output that can be used to differentiate between
RTTs that include the local processing delay, and those which don't.
Finally, report the source and destination addresses from the perspective
of the reply packet, rather than the timestamped packet, to be
consistent with Kathie's pping.
Overall, refactor large parts of pping_kern to allow both timestamping
and matching, as well as updating both the flow and reverse flow and
handle flow-events related to them, in one go. Also update README to
reflect changes.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2022-02-10 16:16:24 +01:00
|
|
|
bool localfilt;
|
|
|
|
__u32 reserved;
|
2021-03-22 12:23:27 +01:00
|
|
|
};
|
|
|
|
|
2021-02-08 20:28:46 +01:00
|
|
|
/*
|
2021-02-09 18:09:30 +01:00
|
|
|
* Struct that can hold the source or destination address for a flow (l3+l4).
|
2021-02-08 20:28:46 +01:00
|
|
|
* Works for both IPv4 and IPv6, as IPv4 addresses can be mapped to IPv6 ones
|
2021-02-09 18:09:30 +01:00
|
|
|
* based on RFC 4291 Section 2.5.5.2.
|
|
|
|
*/
|
|
|
|
struct flow_address {
|
|
|
|
struct in6_addr ip;
|
|
|
|
__u16 port;
|
|
|
|
__u16 reserved;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Struct to hold a full network tuple
|
|
|
|
* The ipv member is technically not necessary, but makes it easier to
|
|
|
|
* determine if saddr/daddr are IPv4 or IPv6 address (don't need to look at the
|
|
|
|
* first 12 bytes of address). The proto memeber is not currently used, but
|
|
|
|
* could be useful once pping is extended to work for other protocols than TCP.
|
2021-02-08 20:28:46 +01:00
|
|
|
*/
|
|
|
|
struct network_tuple {
|
2021-02-09 18:09:30 +01:00
|
|
|
struct flow_address saddr;
|
|
|
|
struct flow_address daddr;
|
2021-02-08 20:28:46 +01:00
|
|
|
__u16 proto; //IPPROTO_TCP, IPPROTO_ICMP, QUIC etc
|
2021-02-09 18:09:30 +01:00
|
|
|
__u8 ipv; //AF_INET or AF_INET6
|
|
|
|
__u8 reserved;
|
2020-12-11 19:25:35 +01:00
|
|
|
};
|
|
|
|
|
2021-03-01 18:16:48 +01:00
|
|
|
struct flow_state {
|
pping: Add timestamp and min-RTT to output
To add timestamp to output, push the timestamp when packet was
processed from kernel as part of the rtt-event. Also keep track of
minimum encountered RTT for each flow in kernel, and also push that as
part of the RTT-event.
Additionally, avoid pushing RTT messages at all if no flow-state
information can be found (due to ex. being deleted from egress side),
as no valid min-RTT can then be given. Furthermore, no longer delete
flow-information once seeing the FIN-flag on egress in order to keep
useful flow-state around for RTT-messages longer. Due to the
FIN-handshake process, it is sufficient if the ingress program deletes
the flow-state upon seeing FIN. However, still delete flow-state from
either ingress or egress upon seeing RST flag, as RST does not have a
handshake process allowing for delayed deletion.
While minimum RTT could also be tracked from the userspace process,
userspace is not aware of when the flow is closed so would have to add
additional logic to keep track of minimum RTT for each flow and
periodically clean them up. Furthermore, keeping RTT statistics in the
flow-state map is useful for implementing future features, such as an
RTT-based sampling interval. It would also be useful in case pping is
changed to no longer have a long-running userspace process printing
out all the calculated RTTs, but instead simply occasionally looks up
the RTT from the flow-state map.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2021-04-29 18:55:06 +02:00
|
|
|
__u64 min_rtt;
|
2022-02-10 16:11:21 +01:00
|
|
|
__u64 srtt;
|
2021-03-01 18:16:48 +01:00
|
|
|
__u64 last_timestamp;
|
2021-05-07 14:54:12 +02:00
|
|
|
__u64 sent_pkts;
|
|
|
|
__u64 sent_bytes;
|
|
|
|
__u64 rec_pkts;
|
|
|
|
__u64 rec_bytes;
|
2021-03-01 18:16:48 +01:00
|
|
|
__u32 last_id;
|
2022-03-09 22:19:59 +01:00
|
|
|
__u32 outstanding_timestamps;
|
2022-03-30 17:40:54 +02:00
|
|
|
enum connection_state conn_state;
|
2022-02-03 12:03:22 +01:00
|
|
|
enum flow_event_reason opening_reason;
|
2022-03-30 17:40:54 +02:00
|
|
|
__u8 reserved[6];
|
2022-03-22 17:59:18 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Stores flowstate for both direction (src -> dst and dst -> src) of a flow
|
|
|
|
*
|
|
|
|
* Uses two named members instead of array of size 2 to avoid hassels with
|
|
|
|
* convincing verifier that member access is not out of bounds
|
|
|
|
*/
|
|
|
|
struct dual_flow_state {
|
|
|
|
struct flow_state dir1;
|
|
|
|
struct flow_state dir2;
|
2021-03-01 18:16:48 +01:00
|
|
|
};
|
|
|
|
|
2021-02-08 20:28:46 +01:00
|
|
|
struct packet_id {
|
|
|
|
struct network_tuple flow;
|
|
|
|
__u32 identifier; //tsval for TCP packets
|
2020-12-11 19:25:35 +01:00
|
|
|
};
|
|
|
|
|
2022-02-17 14:01:08 +01:00
|
|
|
|
2021-06-22 15:22:11 +02:00
|
|
|
/*
|
2022-02-03 16:28:10 +01:00
|
|
|
* Events that can be passed from the BPF-programs to the user space
|
|
|
|
* application.
|
2021-06-22 15:22:11 +02:00
|
|
|
* The initial event_type memeber is used to allow multiplexing between
|
2022-02-17 14:01:08 +01:00
|
|
|
* different event types in a single perf buffer. Memebers event_type and
|
|
|
|
* timestamp are common among all event types, and flow is common for
|
|
|
|
* rtt_event, flow_event and map_full_event.
|
2022-02-03 16:28:10 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* An RTT event message passed when an RTT has been calculated
|
2021-06-22 15:22:11 +02:00
|
|
|
* Uses explicit padding instead of packing based on recommendations in cilium's
|
|
|
|
* BPF reference documentation at https://docs.cilium.io/en/stable/bpf/#llvm.
|
|
|
|
*/
|
2021-01-18 18:08:35 +01:00
|
|
|
struct rtt_event {
|
2021-06-22 15:22:11 +02:00
|
|
|
__u64 event_type;
|
|
|
|
__u64 timestamp;
|
|
|
|
struct network_tuple flow;
|
|
|
|
__u32 padding;
|
2021-01-18 18:08:35 +01:00
|
|
|
__u64 rtt;
|
pping: Add timestamp and min-RTT to output
To add timestamp to output, push the timestamp when packet was
processed from kernel as part of the rtt-event. Also keep track of
minimum encountered RTT for each flow in kernel, and also push that as
part of the RTT-event.
Additionally, avoid pushing RTT messages at all if no flow-state
information can be found (due to ex. being deleted from egress side),
as no valid min-RTT can then be given. Furthermore, no longer delete
flow-information once seeing the FIN-flag on egress in order to keep
useful flow-state around for RTT-messages longer. Due to the
FIN-handshake process, it is sufficient if the ingress program deletes
the flow-state upon seeing FIN. However, still delete flow-state from
either ingress or egress upon seeing RST flag, as RST does not have a
handshake process allowing for delayed deletion.
While minimum RTT could also be tracked from the userspace process,
userspace is not aware of when the flow is closed so would have to add
additional logic to keep track of minimum RTT for each flow and
periodically clean them up. Furthermore, keeping RTT statistics in the
flow-state map is useful for implementing future features, such as an
RTT-based sampling interval. It would also be useful in case pping is
changed to no longer have a long-running userspace process printing
out all the calculated RTTs, but instead simply occasionally looks up
the RTT from the flow-state map.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2021-04-29 18:55:06 +02:00
|
|
|
__u64 min_rtt;
|
2021-05-07 14:54:12 +02:00
|
|
|
__u64 sent_pkts;
|
|
|
|
__u64 sent_bytes;
|
|
|
|
__u64 rec_pkts;
|
|
|
|
__u64 rec_bytes;
|
pping: Do both timestamping and matching on ingress and egress
Perform both timestamping and matching on both ingress and egress
hooks. This makes it more similar to Kathie's pping, allowing the tool
to capture RTTs in both directions when deployed on just a single
interface.
Like Kathie's pping, by default filter out RTTs for packets going to
the local machine (will only include local processing delays). This
behavior can be disabled by passing the -l/--include-local option.
As packets that are timestamped on ingress and matched on egress will
include the local machines processing delay, add the "match_on_egress"
member to the JSON output that can be used to differentiate between
RTTs that include the local processing delay, and those which don't.
Finally, report the source and destination addresses from the perspective
of the reply packet, rather than the timestamped packet, to be
consistent with Kathie's pping.
Overall, refactor large parts of pping_kern to allow both timestamping
and matching, as well as updating both the flow and reverse flow and
handle flow-events related to them, in one go. Also update README to
reflect changes.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2022-02-10 16:16:24 +01:00
|
|
|
bool match_on_egress;
|
|
|
|
__u8 reserved[7];
|
2021-06-22 15:36:35 +02:00
|
|
|
};
|
|
|
|
|
2021-06-22 15:22:11 +02:00
|
|
|
/*
|
2022-02-03 16:28:10 +01:00
|
|
|
* A flow event message passed when a flow has changed state (opened/closed)
|
2021-06-22 15:22:11 +02:00
|
|
|
*/
|
|
|
|
struct flow_event {
|
|
|
|
__u64 event_type;
|
pping: Add timestamp and min-RTT to output
To add timestamp to output, push the timestamp when packet was
processed from kernel as part of the rtt-event. Also keep track of
minimum encountered RTT for each flow in kernel, and also push that as
part of the RTT-event.
Additionally, avoid pushing RTT messages at all if no flow-state
information can be found (due to ex. being deleted from egress side),
as no valid min-RTT can then be given. Furthermore, no longer delete
flow-information once seeing the FIN-flag on egress in order to keep
useful flow-state around for RTT-messages longer. Due to the
FIN-handshake process, it is sufficient if the ingress program deletes
the flow-state upon seeing FIN. However, still delete flow-state from
either ingress or egress upon seeing RST flag, as RST does not have a
handshake process allowing for delayed deletion.
While minimum RTT could also be tracked from the userspace process,
userspace is not aware of when the flow is closed so would have to add
additional logic to keep track of minimum RTT for each flow and
periodically clean them up. Furthermore, keeping RTT statistics in the
flow-state map is useful for implementing future features, such as an
RTT-based sampling interval. It would also be useful in case pping is
changed to no longer have a long-running userspace process printing
out all the calculated RTTs, but instead simply occasionally looks up
the RTT from the flow-state map.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2021-04-29 18:55:06 +02:00
|
|
|
__u64 timestamp;
|
2021-02-09 13:00:28 +01:00
|
|
|
struct network_tuple flow;
|
pping: Do both timestamping and matching on ingress and egress
Perform both timestamping and matching on both ingress and egress
hooks. This makes it more similar to Kathie's pping, allowing the tool
to capture RTTs in both directions when deployed on just a single
interface.
Like Kathie's pping, by default filter out RTTs for packets going to
the local machine (will only include local processing delays). This
behavior can be disabled by passing the -l/--include-local option.
As packets that are timestamped on ingress and matched on egress will
include the local machines processing delay, add the "match_on_egress"
member to the JSON output that can be used to differentiate between
RTTs that include the local processing delay, and those which don't.
Finally, report the source and destination addresses from the perspective
of the reply packet, rather than the timestamped packet, to be
consistent with Kathie's pping.
Overall, refactor large parts of pping_kern to allow both timestamping
and matching, as well as updating both the flow and reverse flow and
handle flow-events related to them, in one go. Also update README to
reflect changes.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2022-02-10 16:16:24 +01:00
|
|
|
enum flow_event_type flow_event_type;
|
|
|
|
enum flow_event_reason reason;
|
2021-06-22 15:36:35 +02:00
|
|
|
enum flow_event_source source;
|
2021-06-22 15:22:11 +02:00
|
|
|
__u8 reserved;
|
2021-01-07 18:14:27 +01:00
|
|
|
};
|
|
|
|
|
2022-02-03 15:51:22 +01:00
|
|
|
/*
|
|
|
|
* An event indicating that a new entry could not be created the map due to the
|
|
|
|
* map being full.
|
|
|
|
*/
|
|
|
|
struct map_full_event {
|
|
|
|
__u64 event_type;
|
|
|
|
__u64 timestamp;
|
|
|
|
struct network_tuple flow;
|
|
|
|
enum pping_map map;
|
|
|
|
__u8 reserved[3];
|
|
|
|
};
|
|
|
|
|
2022-02-17 14:01:08 +01:00
|
|
|
/*
|
|
|
|
* Struct for storing various debug-information about the map cleaning process.
|
|
|
|
* The last_* members contain information from the last clean-cycle, whereas the
|
|
|
|
* tot_* entires contain cumulative stats from all clean cycles.
|
|
|
|
*/
|
|
|
|
struct map_clean_event {
|
|
|
|
__u64 event_type;
|
|
|
|
__u64 timestamp;
|
|
|
|
__u64 tot_runtime;
|
|
|
|
__u64 tot_processed_entries;
|
|
|
|
__u64 tot_timeout_del;
|
|
|
|
__u64 tot_auto_del;
|
|
|
|
__u64 last_runtime;
|
|
|
|
__u32 last_processed_entries;
|
|
|
|
__u32 last_timeout_del;
|
|
|
|
__u32 last_auto_del;
|
|
|
|
__u32 clean_cycles;
|
|
|
|
enum pping_map map;
|
|
|
|
__u8 reserved[7];
|
|
|
|
};
|
|
|
|
|
2021-06-10 18:23:37 +02:00
|
|
|
union pping_event {
|
|
|
|
__u64 event_type;
|
|
|
|
struct rtt_event rtt_event;
|
|
|
|
struct flow_event flow_event;
|
2022-02-03 15:51:22 +01:00
|
|
|
struct map_full_event map_event;
|
2022-02-17 14:01:08 +01:00
|
|
|
struct map_clean_event map_clean_event;
|
2021-06-10 18:23:37 +02:00
|
|
|
};
|
|
|
|
|
2020-12-11 19:25:35 +01:00
|
|
|
#endif
|