怎样理解Net Device Ingress与Egress双重角色
发布时间：2024-01-08 17:03:41 所属栏目：云计算 来源：DaWei
导读： 整理 eBPF 相关的内容，尤其是 tc eBPF 的时候，再一次发现如果不能准确地在数据流中识别出网络设备是 Ingress 还是 Egress ，就无法将代码逻辑和实际运行结果对上号，更勿谈能理解tc e
|
整理 eBPF 相关的内容，尤其是 tc eBPF 的时候，再一次发现如果不能准确地在数据流中识别出网络设备是 Ingress 还是 Egress ，就无法将代码逻辑和实际运行结果对上号，更勿谈能理解tc eBPF 了。 这样的双重角色扮演就如同一个调皮的孩子，总是带上面具在错综复杂的网络里面东躲西藏，肆意玩耍。而当你好不容易抓到它时，却让你猜猜此时此刻他是谁。 简单来说：对于网卡而言，无论它是物理的还是虚拟的，对于 Ingress 角色，它是首先触碰到数据的人，而对于 Egress 角色，它是最后一个碰到数据的人。 1、单个物理网卡 这是一个简单的图，图中有一张物理网卡。我们的台式机通常是这样的配置。橘色的线代表着输入流程，而蓝色的线表示输出流程。 （1）输入流程 Ingress 对于这张网卡而言，输入过程伴随着以下几个重要的事情：物理网卡首先接收到物理信号 -> 物理网卡通过 DMA 机制将数据保存至其专属的 RingBuffer 里面 -> 向 CPU 发起中断 -> OS kernel thread ksoftirqd/x 不断地消费 RingBuffer 里面的数据。 这里的 ksoftirqd 是一个内核线程，每个 CPU 一个，x 为 CPU 编号。如 ksoftirqd/0 为 0 号 CPU 上运行的内核线程。 ksoftirqd/x 将数据以 skb 为处理粒度依次穿过链路层、网络层、TCP/UDP 传输层 。不过 skb 在链路层和网络层还可能直接 forward 给其它网卡，那这样的话传输层就不会收到这个 skb 了。 你可以从整体上感受一下。标号 1 及 1.x 为数据输入和生产过程，这是本文的重点。而标号 3 为数据消费过程，它带着 skb 从入口处的 net_rx_action() 沿着协议栈由底向上穿越协议栈，这个过程对本文所述的所有 Ingress 场景都是通用的，故后文不再赘述这部分。 总结：当物理网卡扮演 Ingress 角色时，它从主机外接收数据，将数据递交给了环形队列，然后由 ksoftirqd/x 进行后续的处理，这个处理过程也称为网络栈下半部分。 （2）输出过程 Egress 我们大致可以看出来，对于输出过程，数据来源有两种，分别是通过 ip_forward() 过程和通过 ip_local_out() 过程送过来的数据。我们还会发现，在发送数据的路径上，这两个过程只是起点有些不同，剩下的路程大家都一样。 ip_forward() 过程与 skb 在 IP 层路由结果强相关。如图 3 所示，具体来说经过路由的判定，可能需要把 skb forward 至本机网络设备或者网络中的其它主机处理，不过无论是哪种情况，都需要将 skb 送往本机的一个网络设备。 总结：当物理网卡扮演 Egress 角色时，它从本机 TCP/IP 协议栈接收数据，将数据通过驱动程序送离本机。 2、veth-pair 是不是觉得单个网卡的场景其实很容易分辨出来 Ingress 和 Egress ? 下一个问题：既然 veth_left 扮演了 Egress 角色，流量从离开 network namespace 1 之后去哪里了？既然 veth_right 是 Ingress ，那它从哪里接收到流量的？ 总结：既然 veth 是一对虚拟网卡，那我们把对它俩的总结放在一起。 当 veth 网卡扮演 Egress 角色时，如图 7 中的 veth_left，它从其所在的 network namespace TCP/IP 协议栈接收数据，并将数据递交给了 per CPU input_pkt_queue 队列，并触发软件中断。 当 veth 网卡扮演 Ingress 角色时，如图 7 中的 veth_right，它并没有物理网卡那种环形队列，而是由 ksoftirqd/x 直接从 per CPU input_pkt_queue 队列读取 veth_left 塞进来的数据。 veth_left 和 veth_right 共享了同一个 queue 。典型的生产者 / 消费者设计模式的即视感有没有？ 3、bridge 上一节，二哥把 veth pair 单独拿出来和大家一起观赏。可它们终究不是花瓶，它们被创造出来是要有实际使用价值的。veth 典型使用场景就是把一端插入到 bridge 里面，如图 8 所示。 从 veth 的特性来说，流量从下图 veth1-left 流出后，会进入 veth1-right ，这也就意味着流量进入了网桥。 我想这个时候你可以确定 veth1-left 是 Egress ，而 veth1-right 是 Ingress 。那么对于 bridge 的 Port 1 和 Port 2 呢？再进一步，对于 veth2-left 和 veth2-right 呢 ? 其实对于 bridge 这种虚拟的网桥，它的 port 口也是一个虚拟的概念，说得更直白一点，在内核里它就是一个数据结构：struct net_bridge_port 。这个结构里有 3 个重要的成员：br / port_no / dev 。下面的代码用于插入网络设备到 bridge ，这 3 个成员的作用显而易见。 复制 //file: net/bridge/br_if.c static struct net_bridge_port *new_nbp(struct net_bridge *br, struct net_device *dev) { //申请插口对象 struct net_bridge_port *p; p = kzalloc(sizeof(*p), GFP_KERNEL); //初始化插口 index = find_portno(br); p->br = br; p->dev = dev; p->port_no = index; ... } veth1-right 扮演 Ingress 角色，它并没有物理网卡那种环形队列，而是由 ksoftirqd/x 直接从 per CPU input_pkt_queue 队列读取 veth1-left 塞进来的数据。当 ksoftirqd/x 把流量送至链路层时，从 br_forward() 开始进入 forward 流程。这个流程的效果就是流量从 veth1-right 转至 veth2-right 发送出去了。 那自然 veth2-right 这个时候就扮演了 Egress 角色，veth2-left 扮演了 Ingress 角色。 4、tc eBPF 如果你对 tc 和 eBPF 了解得不多或者不感兴趣，可以跳过这部分。 以 Cilium 为代表的 K8s CNI 提供商一直在尝试使用 eBPF 代替 iptables 以便优化服务网格数据面性能。其中 bpf_redicrect() 函数即为其中一项优化产出。 bpf_redicrect() 函数的特性用一句话就能解释清楚：当 veth Ingress 时，将流量直接通过 bpf_redirect() 重定向到另一个 veth Ingress。如图 11 所示。 不过如果你对 veth pair 哪一端在何时会扮演 Ingress 角色了解得不是很清楚的话，上面这句话其实会把你绕晕。 你看到在它身上附上了一个 eBPF 小蜜蜂图标，表示这个时候 eBPF 程序会介入执行，执行的结果就是流量被直接通过 dev_forward_skb() forward 给了另外一个同样位于 host network ns 端的 veth （如图 11 箭头所指的那个 veth），当然对这个 veth 而言，它会扮演 Egress 角色。 这个过程也可以用下面这样的函数调用层次图来表示。 复制 pkt -> NIC -> TC ingress -> handle_ing() |-verdict = tc_classify() // exec BPF code | |-bpf_redirect() // return verdict | |-switch (verdict) { case TC_ACK_REDIRECT: skb_do_redirect() // to the target net device |-if ingress: | dev_forward_skb() |-else: dev_queue_xmit() （编辑：文章分享网_茂名站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
推荐文章
站长推荐