Closed antoninbas closed 11 months ago
Hi. It is expected behavior. According to OpenFlow spec [1]:
Switches that do not support internal buffering, are configured to not buffer
packets for the packet-in event, or have run out of internal buffering, must
send the full packet to controllers as part of the [Packet-in] event.
<...>
If the packet is buffered, the number of bytes of the original packet to include
in the packet-in can be configured. <...>
OVS reports number of supported buffers as zero in the OFPT_FEATURES_REPLY
, meaning that controller cannot expect buffering. And under these conditions, the switch that doesn't support buffering (OVS) must send the whole packet in the packet-in.
The ovs-actions man page may use some update, true.
[1] Section 6.1.2 : https://opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.5.1.pdf
Thanks for the quick confirmation.
I can volunteer to update the documentation if that helps.
I can volunteer to update the documentation if that helps.
Thanks! Feel free to submit a patch.
@igsilya the patch was acked, would you mind applying it: https://mail.openvswitch.org/pipermail/ovs-dev/2023-August/407313.html ?
Applied. Thanks!
Thanks.
I confirmed that no change is required for the documentation of the output
action, given that the following is not allowed:
$ ovs-ofctl mod-flows br-int 'table=0,priority=100,in_port=veth1,ip actions=output(port=controller,max_len=128)'
ovs-ofctl: output to unsupported truncate port: controller
which is already the documented behavior
It seems that the
max_len
option for thecontroller
action is never honored, at least not with the Linux kernel datapath.Here is my OF flow:
Here is the datapath flow:
Even though
max_len
is set to128
, the controller receives the full packet, which is 428B.I looked at the code. It seems that this was meant to be implemented just before sending the packet to the controller (in connmgr), as the entire packet is always upcalled by the kernel datapath anyway. Originally, the functionality was implemented in
ofputil_encode_packet_in_private
: https://github.com/openvswitch/ovs/blob/7a0f907b2393626dac1387617355990eab69aef7/lib/ofp-util.c#L3857-L3897The implementation was then removed in OVS v2.7 by this patch: https://github.com/openvswitch/ovs/commit/c184807ced554c1dc7b69b3cd4f59cd85575fdf1
And as far as I can tell, this field has been unused ever since: https://github.com/openvswitch/ovs/blob/cf11766cbcf162399aafb84ba5634a22bccf9e8b/ofproto/connmgr.h#L49
Is this the expected behavior? Should the documentation for the
controller
action be updated to indicate that themax_len
option may not be honored (or is never honored)?