Add support for tc redirect based VM to Container connection

[mcastelino]

Add support for tc redirect based VM to Container connection

Implement a new interconnection capability to support tc based traffic redirection. This can be based on the existing bridge connection logic, using tc instead of the linux bridge

Connecting a veth device to tap

• veth device from CNI/CNM plugin: eth0
• tap device that connects to the VM: tap0

Redirecting traffic between the two devices

To quickly prototype, select the virtcontainers bridge networking implementation. Then for each container

nsenter --net=<container_ns>
ip link del br0
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol all u32 match u8 0 0 action mirred egress redirect dev tap0
tc qdisc add dev tap0 ingress
tc filter add dev tap0 parent ffff: protocol all u32 match u8 0 0 action mirred egress redirect dev eth0

https://github.com/vishvananda/netlink/blob/0e3b74dbe28f37fd911f9bca3565fdca33c03f29/qdisc_linux.go#L130

[egernst]

@bergwolf - who on hyper side implemented the TC in runv? Is this something you can help with?

[laijs]

@gao-feng did the job. thanks to him. But he had shifted to other work and may not be available for this job.

@mcastelino @egernst Why do you need this since cc-runtime has macvtap based implementation? I can't tell the pros/cons between tc&macvtap based implements. Each has its own merits.

[amshinde]

@laijs See this issue in clear-containers that is valid for kata-containers: https://github.com/clearcontainers/runtime/issues/1042

[egernst]

@laijs - there are a couple scenarios, like what @amshinde pointed out, which shows the advantages of TC. I think they are at parity from a perf perspective. I envision this is something where we can offer two implementations and allow the user to configure.

[egernst]

This issue was moved to kata-containers/runtime#144