Grammar improvements, h/t Claude

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

@@ -12,7 +12,7 @@ performance and versatility. For those of us who have used Cisco IOS/XR devices,
 _ASR_ (aggregation service router), VPP will look and feel quite familiar as many of the approaches
 are shared between the two.
 
-There's some really fantastic features in VPP, some of which are lesser well known, and not always
+There are some really fantastic features in VPP, some of which are less well known, and not always
 very well documented. In this article, I will describe a unique use case in which I think VPP will
 excel, notably acting as a gateway for Internet Exchange Points.
 
@@ -49,7 +49,7 @@ Back in October of 2023, I reached the conclusion that the policer works in the
 
 ## VPP Infra: L2 Feature Maps
 
-The benefit in using the `device-input` input arc is it's efficient: every packet that comes from the
+The benefit of using the `device-input` arc is that it's efficient: every packet that comes from the
 device (`Gi10/0/1`) regardless of tagging or not, will be handed off to the policer plugin. It means
 any traffic (L2, L3, sub-interface, tagged, untagged) will all go through the same policer. 
 
@@ -204,7 +204,7 @@ I think writing unit- and integration tests is a great idea. I add a new file
 1.  **L2 Output**: on a bridge-domain sub-interface
 
 The existing `test/test_policer.py` should also cover existing cases, and of course it's important
-that my work does not impact these changes. Lucky me, the existing tests all still pass :)
+that my work does not break existing functionality. Lucky me, the existing tests all still pass :)
 
 ### Test: L3 in/output
 
@@ -288,7 +288,7 @@ pim@summer:~/src/vpp$ make test-debug TEST=test_policer_subif V=2
 {{< image width="5em" float="left" src="/assets/shared/warning.png" alt="Warning" >}}
 
 **Whoops!** So much for predicting the outcome! I see that 7 packets (896 bytes) make it through on input
-while 6 packets (876 bytes) made it through on output. In the input case, the packet size is
+while 6 packets (876 bytes) make it through on output. In the input case, the packet size is
 `896/7 = 128` bytes, which is 18 bytes short. What's going on?
 
 ### Side Quest: Policer Accounting
@@ -304,8 +304,8 @@ Ben also points out that when applying the policer to the interface, I can detec
 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 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!
+as an added benefit, also remains backwards compatible with the `device-input` accounting.
+Chapeau, Ben, you're so clever!
 
 I add a little helper function:
 
@@ -351,7 +351,7 @@ pim@summer:~/src/vpp$ make test-debug TEST=test_policer_subif V=2 | grep 'police
   'exceed_packets': 0, 'exceed_bytes': 0, 'violate_packets': 61, 'violate_bytes': 8906}
 ```
 
-Yaay, great success!
+Yay, great success!
 
 ### Test: L2 in/output
 
@@ -418,7 +418,7 @@ ethernet-input
 I've sent the change, which was only about ~300 LOC, off for review. You can follow along on the
 gerrit on [[44654](https://gerrit.fd.io/r/c/vpp/+/44654)]. I don't think the policer got much slower
 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
+sub-interfaces or 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 comparison of packets/sec throughput on the bench some
 time.
@@ -428,5 +428,5 @@ and packet scheduler designed to eliminate bufferbloat, which is high latency ca
 buffering in network equipment, while ensuring fair bandwidth distribution among competing traffic
 flows. I know that Dave Täht - may he rest in peace - always wanted that. 
 
-For me, I've set my sights on eVPN VxLAN, and I started toying with SRv6 L2 transport also. I hope
+For me, I've set my sights on eVPN VxLAN, and I also started toying with SRv6 L2 transport. I hope
 that in the spring I'll have a bit more time to contribute to VPP and write about it. Stay tuned!