Hoi Ben,
On 2026-01-20 00:50, Benoit Ganne (bganne) via lists.fd.io wrote:
I've written https://gerrit.fd.io/r/c/vpp/+/44654 which allows policer
to be attached to L3 sub-interfaces, by applying the policer-input in
front of ip4-unicast/ip6-unicast in the same way that currently
policer-output applies to the ip4-output/ip6-output nodes.
Thanks Pim, I have a couple of comments but maybe this specific one
warrants a bit more discussions: if I am not mistaken, moving from
device-input to ip-unicast changes the policer accounting: the policer
uses vlib_buffer_length_in_chain() to get the packet length which is
dependent upon b->current_length and this gets updated when me move
b->current_data, so the length you get on device-input should take into
account the ethernet header whereas the length you get on ip-unicast
should not.
This is not a big change for big packets, but it can be for smaller
ones.
Now, I do not know if we want to take into account the Ethernet header
or not when policing.
I don't have a strong opinion, but can offer some thoughts -
. Today, we are currently inconsistent in policers:
.. On output, we sit before ip[46]-output (which only works for L3, and
uses the IP size)
.. For L2, we sit before l2-input (ethernet size)
.. For L2 classifier, we sit before l2-input (ethernet size)
.. For IP4/IP6 classifier, we sit before ip[46]-unicast already (IP
size)
.. As an aside: we do not police non-ip (eg MPLS) or ip[46]-multicast in
any L3 policer.
. One thing the gerrit does do, is create consistency: for any(and all)
L3 policers, now the IP size will be used. for any(and all) L2 policers,
the ethernet size will be used. In return, it does change the contract
for 'L3 input' policers, as you saw
I guess we might standardize on 'always use the whole datagram'
approach, and retrofit on output and on L3 input the ethernet header, if
it exists. Something like
u16 l2_overhead = 0;
if (!is_l2) {
vnet_hw_interface_t *hi = vnet_get_sup_hw_interface (vnm,
sw_if_index);
if (hi->hw_class_index == ethernet_hw_interface_class.index)
l2_overhead = 14;
}
.. and update vnet_policer_police() to adjust for the l2_overhead? I
think it would have both consistency, but it would break expectations:
the l3 output path would now add ethernet overhead, changing the
accounting there. If we do nothing, the L3 input path would now drop
ethernet overhead, changing the accounting there. From my read, one way
or another, we will be changing something that users might notice.
groet,
Pim
--
Pim van Pelt <[email protected]>
PBVP1-RIPE https://ipng.ch/
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#26721): https://lists.fd.io/g/vpp-dev/message/26721
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]]
-=-=-=-=-=-=-=-=-=-=-=-
