-
Notifications
You must be signed in to change notification settings - Fork 10
Description
To process a packet, we currently read each layer and then advance the r/wptr fields of the mblk_t containing the packet and its headers. This leaves the original headers in place. We then determine how many bytes the complete header stack would require (Option<encap{L2,L3,L4}> + Ulp {L2, L3, L4}), before using the existing space or allocating a new mblk to be placed at the front of the chain and copying the entire (post-transform) header set back into place.
However, many of our transforms when packets are Modified do not alter the entire header stack, or even alter the structure of ULP packet headers. While needing to add or remove the Geneve header group is universal, VPC-internal traffic would actually require no changes to the ULP, and would in effect only modify L2 addrs of transformed traffic. VPC-external packets typically only require that we change L3 src/dest addrs or L4 ports (due to NAT/SNAT) in addition to this (and, accordingly, the checksum).
It would likely be more clever to:
- Determine whether any parts of the output headers have structurally changed. I.e., the addition of new layers, or extension fields. If the structure of a header group has not changed, then we can update the modified fields – and only the modified fields – in place.
- Allow the encap packet headers and ULP packet headers to exist within different segments. This will allow us to only allocate and write the Geneve header stack from scratch, and apply the above optimisation to ULPs on all encap'd traffic.
This might in theory be extended to Hairpin packets under limited circumstances, but I believe that through-traffic is the most important occurrance to capture.