Hoi, On 2026-01-20 12:34, Muhammad Naseer Bhatti via lists.fd.io wrote:
Does your implementation also take into account L2 interfaces? For those, some features need to be created on the L2 path, as there is no 'ip[46]-unicast' in ingress and no 'ip[46]-output' on egress.From src/vnet/policer/node_funcs.c (feature registrations): VNET_FEATURE_INIT (policer_input_ip4_node, static) = { .arc_name = "ip4-unicast”, .node_name = "policer-input”, .runs_before = VNET_FEATURES ("ip4-not-enabled”), };From src/vnet/policer/policer.c (interface logic): if (si->type == VNET_SW_INTERFACE_TYPE_HARDWARE) { vnet_feature_enable_disable ("device-input", "policer-input", sw_if_index, apply, 0, 0); } else { // Enable on IP arcs for logical interfaces if (ip4_enabled) vnet_feature_enable_disable ("ip4-unicast", "policer-input", sw_if_index, 1, 0, 0); // Similar for ip6 } This enables policing on L3 sub-interfaces via IP arcs, changing length accounting to IP size (excluding L2 headers).
Regarding using device-input *and* ip[46]-unicast, I think this might add to operational confusion because then if you apply to the PHY you'll get accounting w/ ethernet, and if you add to the SUB you'll get accounting w/ ip[46], which was the original question from Ben. How did you rationalize L2, L3, PHY/SUB accounting in your approach, Muhammad ?
groet, Pim -- Pim van Pelt <[email protected]> PBVP1-RIPE https://ipng.ch/
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26723): https://lists.fd.io/g/vpp-dev/message/26723 Mute This Topic: https://lists.fd.io/mt/117359534/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
