ipng/ipng.ch
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

A few typo fixes - h/t jeroen@
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse Source
This commit is contained in:
Pim van Pelt
2024-09-12 15:40:37 +02:00
parent ceb16714b6
commit 2e1bb69772
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
content/articles/2024-09-08-sflow-1.md
View File

@ -126,7 +126,7 @@ samples are sent from many threads, there will be lock contention and performanc
### sFlow Plugin: Functional ### sFlow Plugin: Functional
I boot up the [[IPng Lab]({{< ref 2022-10-14-lab-1 >}})] and install a bunch of sFLow tools on it, I boot up the [[IPng Lab]({{< ref 2022-10-14-lab-1 >}})] and install a bunch of sFlow tools on it,
make sure the `psample` kernel module is loaded. In this first test I'll take a look at make sure the `psample` kernel module is loaded. In this first test I'll take a look at
tablestakes. I compile VPP with the sFlow plugin, and enable that plugin in `startup.conf` on each tablestakes. I compile VPP with the sFlow plugin, and enable that plugin in `startup.conf` on each
of the four VPP routers. For reference, the Lab looks like this: of the four VPP routers. For reference, the Lab looks like this:
@ -205,7 +205,7 @@ I am amazed! The `psampletest` output shows a few packets, considering I'm askin
100Mbit using 9000 byte jumboframes (which would be something like 1400 packets/second), I can 100Mbit using 9000 byte jumboframes (which would be something like 1400 packets/second), I can
expect two or three samples per second. I immediately notice a few things: expect two or three samples per second. I immediately notice a few things:
***1. Network Namespae***: The Netlink sampling channel belongs to a network _namespace_. The VPP ***1. Network Namespace***: The Netlink sampling channel belongs to a network _namespace_. The VPP
process is running in the _default_ netns, so its PSAMPLE netlink messages will be in that namespace. process is running in the _default_ netns, so its PSAMPLE netlink messages will be in that namespace.
Thus, the `psampletest` and other tools must also run in that namespace. I mention this because in Thus, the `psampletest` and other tools must also run in that namespace. I mention this because in
Linux CP, often times the controlplane interfaces are created in a dedicated `dataplane` network Linux CP, often times the controlplane interfaces are created in a dedicated `dataplane` network
@ -265,7 +265,7 @@ bridging or cross connects in the VPP dataplane, and it does not have a Linux Co
interface, or `linux-cp` is not used at all. interface, or `linux-cp` is not used at all.
1. Even if it does exist and it's the "correct" ifIndex in Linux, for example if the _Linux 1. Even if it does exist and it's the "correct" ifIndex in Linux, for example if the _Linux
Interface Pair_'s tuntap `hosf_vif_index` index is used, even then the statistics counters in the Interface Pair_'s tuntap `host_vif_index` index is used, even then the statistics counters in the
Linux representation will only count packets and octets of _punted_ packets, that is to say, the Linux representation will only count packets and octets of _punted_ packets, that is to say, the
stuff that LinuxCP has decided need to go to the Linux kernel through the TUN/TAP device. Important stuff that LinuxCP has decided need to go to the Linux kernel through the TUN/TAP device. Important
to note that east-west traffic that goes _through_ the dataplane, is never punted to Linux, and as to note that east-west traffic that goes _through_ the dataplane, is never punted to Linux, and as
@ -481,7 +481,7 @@ because of that, it'll end up consuming more packets on each subsequent iteratio
up. The L2 path on the other hand, is quicker and therefore will have less packets waiting on up. The L2 path on the other hand, is quicker and therefore will have less packets waiting on
subsequent iterations of `dpdk-input`. subsequent iterations of `dpdk-input`.
2. The `sfloww` plugin spends between 13.5 and 19.7 CPU cycles shoveling the packets into 2. The `sflow` plugin spends between 13.5 and 19.7 CPU cycles shoveling the packets into
`ethernet-input` without doing anything to them. That's pretty low! And the L3 path is a little bit `ethernet-input` without doing anything to them. That's pretty low! And the L3 path is a little bit
more efficient per packet, which is very likely because it gets to amort its L1/L2 CPU instruction more efficient per packet, which is very likely because it gets to amort its L1/L2 CPU instruction
cache over 45 packets each time it runs, while the L2 path can only amort its instruction cache over cache over 45 packets each time it runs, while the L2 path can only amort its instruction cache over