Fix some issues for transparent cube when packet forwarded to slow path #218
Conversation
- core dump when transparent cube sends packet to the slow path - stack topology (0xffff) not recognized by controller bpf program - calling send_packet_out() in transprent cube slow path may cause dead loop Signed-off-by: Jianwen Pi <jianwpi@gmail.com>
|
According to my understanding this PR is mainly focused in the case a transparent cube is attached to a NIC, and the support when the transparent cube is attached to another cube's port is not changed with this PR, right? Overall looks good to me, maybe clarifying the previous point will help to understand it better. |
@mauriciovasquezbernal Yes this PR is only focusing on the transparent cube, it shouldn't change any behavior for regular cube. |
|
It could be a good idea to extend the description of the PR making it clear that it adds support for the case a transparent cube is attached to a NIC. For the rest, it LGMT. |
goldenrye
changed the title
|
Is XDP support missing from this PR?, will be done in the future or it's not needed? |
You are right, this PR doesn't cover XDP case. Will evaluate whether XDP is impacted or not in the future. |
forwarded to slow path from ingress context (BPF program executed in ingress TC hook), the original packet's dest mac needs to be adjusted to the controller interface's mac - otherwise packet will be dropped by linux stack, since linux doesn't recoginize the packet destined to a mac other than the ingress interface even the mac belongs to one of its interface. Unlike the packet forwarded from egress context, the packet has to be re-injected and walk throught the full kernel stack before it was sent out eventually. On the other hand, for packet forwarded to slow path from egress context, we don't have to adjust the mac since the packet has been processed by linux stack before the slow path, so just send it out as is. Signed-off-by: Jianwen Pi<jianwpi@gmail.com>
The modification fixed the following issues:
Issue #217