Typo fixes, h/t Claude

content/articles/2026-02-14-vpp-policers.md

@@ -34,7 +34,7 @@ vpp# policer input name client-a GigabitEthernet10/0/1
 vpp# policer output name client-a GigabitEthernet10/0/1
 ```
 
-The idea is to give a _committed information rate_ of 150Mps with a _committed burst_ rate of 15MB. 
+The idea is to give a _committed information rate_ of 150Mbps with a _committed burst_ rate of 15MB. 
 The _CIR_ represents the average bandwidth allowed for the interface, while the _CB_ represents the
 maximum amount of data (in bytes) that can be sent at line speed in a single burst before the _CIR_
 kicks in to throttle the traffic.
@@ -71,7 +71,7 @@ also contains the feature bitmap: a statically configured set of features for th
 
 1.  It will store the effective feature bitmap for each individual packet in the packet buffer. For
 bridge mode, depending on the packet being unicast or multicast, some features are disabled. For
-example,flooding for unicast packets is not performed, so those bits are cleared. The result is
+example, flooding for unicast packets is not performed, so those bits are cleared. The result is
 stored in a per-packet working copy that downstream nodes can be triggered on, in turn.
 
 1.  For each of the bits set in the packet buffer's `l2.feature_bitmap`, starting from highest bit
@@ -79,7 +79,7 @@ set, `l2-input` will set the next node, for example `l2-input-vtr` to do VLAN Ta
 that node is finished, it'll clear its own bit, and search for the next one set, in order to set a
 new node.
 
-I note that processing order is HIGH to LOW bits. By reading `l2_input.h`, I can see that The full
+I note that processing order is HIGH to LOW bits. By reading `l2_input.h`, I can see that the full
 `l2-input` chain looks like this:
 
 ```
@@ -260,7 +260,7 @@ Next, I can generate a few packets and send them out from `pg0`, and wait to rec
 
 Similar to the L3 sub-interface input policer, I also write a test for L3 sub-interface output
 policer. The only difference between the two is that in the output case, the policer is applied to
-`pg1` in the `Dir.TX` direction, while in the input case, it's applied to `pg0` in the `Dir.Rx`
+`pg1` in the `Dir.TX` direction, while in the input case, it's applied to `pg0` in the `Dir.RX`
 direction.
  
 I can predict the outcome. Every packet is exactly 146 bytes: 
@@ -303,8 +303,8 @@ the ethernet frame and encapsulation, so no adjustment is needed there.
 Ben also points out that when applying the policer to the interface, I can detect at creation time if
 it's a PHY, a single-tagged or a double-tagged interface, and store some information to help correct
 the accounting. We discuss a little bit on the mailinglist, and agree that it's best for all four
-cases (L2 input/output and L3 intput/output) to use the full L2 frame bytes in the accounting, which
-as an added benefit also that is remains backwards compatible with the `device-input` accounting.
+cases (L2 input/output and L3 input/output) to use the full L2 frame bytes in the accounting, which
+as an added benefit also that it remains backwards compatible with the `device-input` accounting.
 Chapeau, Ben you're so clever!
 
 I add a little helper function:
@@ -383,7 +383,7 @@ pim@summer:~/src/vpp$ make test-debug TEST=test_policer_subif V=2 | grep 'L2.*po
 
 ## Results
 
-The policer works in all sorts of cool scenario's now. Let me give a concrete example, where I
+The policer works in all sorts of cool scenarios now. Let me give a concrete example, where I
 create an L2XC with VTR and then apply a policer. I've written about VTR, which stands for _VLAN Tag
 Rewriting_ before, in an old article lovingly called [[VPP VLAN Gymnastics]({{< ref
 "2022-02-14-vpp-vlan-gym" >}})]. It all looks like this:
@@ -420,7 +420,7 @@ gerrit on [[44654](https://gerrit.fd.io/r/c/vpp/+/44654)]. I don't think the pol
 after adding the l2 path, and one might argue it doesn't matter because policing didn't work on
 sub-interfaces and L2 output at all, before this change. However, for the L3 input/output case, and
 for the PHY input case, there are a few CPU cycles added now to address the L2 and sub-int use
-cases. Perhaps I should do a side by side comparision of packets/sec throughput on the bench some
+cases. Perhaps I should do a side by side comparison of packets/sec throughput on the bench some
 time.
 
 It would be great if VPP would support FQ-CoDel (Flow Queue-Controlled Delay), which is an algorithm