Add content for eBPF documentation (#12417)

1 files changed, 20 insertions, 5 deletions

diff --git a/collectors/ebpf.plugin/README.md b/collectors/ebpf.plugin/README.md
index e0b74a575a..0f943416c6 100644
--- a/collectors/ebpf.plugin/README.md
+++ b/collectors/ebpf.plugin/README.md
@@ -244,19 +244,29 @@ To collect data related to Linux multi-device (MD) flushing, the following kprob
 
 ### Disk
 
-The eBPF plugin also shows a chart in the Disk section when the `disk` thread is enabled. This will create the
-chart `disk_latency_io` for each disk on the host. The following tracepoints are used:
+The eBPF plugin also shows a chart in the Disk section when the `disk` thread is enabled.
+
+#### Disk Latency
+This will create the chart `disk_latency_io` for each disk on the host. The following tracepoints are used:
 
 - [`block/block_rq_issue`](https://www.kernel.org/doc/html/latest/core-api/tracepoint.html#c.trace_block_rq_issue):
   IO request operation to a device drive.
 - [`block/block_rq_complete`](https://www.kernel.org/doc/html/latest/core-api/tracepoint.html#c.trace_block_rq_complete):
   IO operation completed by device.
 
+Disk Latency is the single most important metric to focus on when it comes to storage performance, under most circumstances.
+For hard drives, an average latency somewhere between 10 to 20 ms can be considered acceptable. For SSD (Solid State Drives),
+in most cases, workloads experience less than 1 ms latency numbers, but workloads should never reach higher than 3 ms.
+The dimensions refer to time intervals.
+
 ### Filesystem
 
-This group has charts demonstrating how applications interact with the Linux
-kernel to open and close file descriptors. It also brings latency charts for
-several different filesystems.
+This group has charts demonstrating how applications interact with the Linux kernel to open and close file descriptors.
+It also brings latency charts for several different filesystems.
+
+#### Latency Algorithm
+We calculate the difference between the calling and return times, spanning disk I/O, file system operations (lock, I/O),
+run queue latency and all events related to the monitored action.
 
 #### ext4
 
@@ -410,6 +420,11 @@ is accessed, but also in possible errors, so we need to attach a `kretprobe`. Fo
 - [`d_lookup`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/dcache.c?id=052b398a43a7de8c68c13e7fa05d6b3d16ce6801#n2223):
   Called when the desired file is not inside the directory cache.
 
+##### Directory Cache Interpretation
+When directory cache is showing 100% that means that every accessed file was present in the directory cache.
+If files are not present in the directory cache, they are either not present in the file system or the files were not
+accessed before.
+
 ### Mount Points
 
 The following `kprobes` are used to collect `mount` & `unmount` call counts: