￭我们看i40e_xmit_pkts()函数，环境衡产这样就可以在每次出现问题时，中负载均无码确认异常包
第二步结论让整个排查前进了一大步，解决将会触发IP分片，生产于是环境衡产两片报文的rte_mbuf结构被链在一起，我们准备将BUG向DPDK社区同步。中负载均这个报文还因为长度太短在经过交换机后被填充了26字节的解决0。大大提高了排查效率。生产
如下图所示，环境衡产分析与解决全过程，中负载均这个报文看上去十分异常，解决
复盘和总结
处理完所有问题后，生产
基于对DPDK的环境衡产深入研究，
根据异常IP的中负载均地域特性，此时我们可以如下图所示去加载编译时候生成的 i40e_rxtx.o 来获取对应符号信息。很快网卡就会tx hang。
因此技术团队理解其工作原理并对其源码进行分析，
一、当时的现象是：
转发面服务监控到网卡接收方向流量正常，报文的总长度是20，丢弃这类报文。经过1天运行再也没有出现异常容灾情况。直接原因已经找到，而且在其前面都会有一个同样长度的报文，但是这一个分片报文就很异常，尤其现网单个ULB集群承载带宽已达10G，无码同时能够结合具体现象一步步定位出DPDK存在的问题，不达目的不罢休，后面不再携带任何信息，
从以上的图中我们可以看到，
问题背景
在12月初一向稳定的ULB4集群中突然出现了容灾，转发能力接近线速;DPDK则是一个高性能的开源数据面开发套件。再结合DPDK源码分析，一旦出现了问题，同时集群其他机器也会不定期出现异常情况。单条指令一步步执行。但是队列包是经过一系列程序处理的，
四、对提高整个DPDK程序的服务可靠性具有重要意义。而是直接调用相应的用户态网卡驱动直接将报文发送出去;
5. 用户态网卡驱动在发送这样的异常报文时触发了网卡tx hang;
6. 触发tx hang后，我们写了一个报文一键导出工具，(该函数中调用的很多函数都使用了inline修饰，随后迅速恢复。正是这种异常报文导致了DPDK工作异常，而驱动程序去查看该字段就可以知道这个报文是否已经被发过。并且分片出了这种异常的形式。报文导出工具、这一片报文本来是设置了不可分片的TCP报文，在传统的Linux系统中，GDB调试报文，在一台不可用的时候，抽丝剥茧，那么有没有可能异常报文还在队列里面呢?如果可以把当前队列里面的报文全部导出来，对每个报文按序号命名。可以在异常时一键导出所有的报文并转成pcap格式。而无法将后续的报文加入发送队列。也是丢弃该异常报文。快速导出网卡驱动发送队列中的所有报文，驱动程序一般处于内核态由内核去管理，如果用户自身程序处理出问题就有可能会导致网卡tx hang这样的异常情况发生。我们使用这样的代码片段构成异常报文，如下：
ip_frag: check fragment length of incoming packet
DPDK 18.11最新发布的版本中，在大流量多元化场景下保证用户业务的持续稳定至关重要，为什么异常报文会触发网卡tx hang
首先我们看下DPDK中跟网卡发送报文相关的代码。我们开始做整体复盘。驱动队列中报文对应的发送描述符不再被网卡正确设置发送完成标记;
7. 后续的报文持续到来，会被拆成多个小的分片报文进行发送。突然陆续在集群的不同机器上出现同样的问题，我们最终找到了这个异常报文，)
四、
本文将从问题现象着手，我们在发包程序逻辑中设置断点，而且驱动程序代码中可能进行了各种异常处理，
二、这两个报文合在一起就是导出队列报文中的那两个连在一起的报文。
2. 关闭GRO功能(ethtool -K net2 gro off)，却发现没有符号信息，而且后面的报文一直加不进去，作为验证，将可能会导致不可预知的后果(具体还是要参考网卡的Datasheet)。我们修改DPDK程序，值得一提的是，但是还需要去实际验证是否为这种异常报文导致。就是网卡因为某种原因不发包或者没能正确回写特定字段，并没有进行检查丢弃，反汇编之后足足有七百多行。根据网卡的Datasheet对相关字段进行正确设置非常重要，但是DPDK通常在关键的网关位置，
果然，
大致流程是i40e_xmit_pkts()在发送的时候，定位到原因出自DPDK本身的BUG并修复解决。于是当晚紧急联系网络运维同事在交换机上配置port-mirroring(端口镜像)，镜像服务器还需要做特殊配置，经过仔细比对，并且机器恢复加入集群后，重启转发面服务后又可以正常收发，将发往ULB4集群的流量镜像到一个空闲服务器上进行镜像抓包。集群中其他机器也可以继续为用户提供可靠服务，是否也会导致网卡异常不发包?
答案是肯定的。所有的分片肯定都是携带有数据的。
参考命令：nohup tcpdump -i net2 -s0 -w %Y%m%d_%H-%M-%S.pcap -G 1800 “proto gre and (((ip[54:4]&0x11223000)==0x11223000) or ((ip[58:4]&0x11223000)==0x11223000))” &
经过多次尝试后，情况如出一辙，
三、
如下图所示，后26字节和全0报文完全吻合。开始在发送队列中积压，我们使用GDB的dump命令将整个队列中所有的报文全部按队列中的顺序导出，这个工具再优化下后，以此来获得该函数对应的参数。功夫不负有心人，生产环境流量镜像等手段，
下面是整个问题的处理过程，
￭当我们打印该队列的消息时，并通过disassemble命令查看该函数的执行逻辑，我们发现一个规律：每次都会有一个长度为26字节但是全0的报文，但为了任何时刻都能保证用户服务的足够稳定，对比最新的commit后，使得可以在用户态直接操作硬件，找到11月6日提交的一个commit，对直接操作硬件的思考
直接操作硬件是一件需要非常谨慎的事情，我们在ULB4的线上环境中，用于收取镜像流量(ifconfig net2 promisc)。
至此，正常情况下，但是，但是奇怪的是IP分片的第二片只有IP头。因此很少会发生用户程序操作导致硬件不工作的情况。但是发送方向流量为0，
ULB4是UCloud自主研发的基于DPDK的高可用四层负载均衡产品，
在多次导出报文后，所以我们可以获取到队列的信息。已对此进行了修复，
三、发现发送队列满了就会去调用i40e_xmit_cleanup()清理队列。且每次源IP地址网段都来自于同一个地区。有效提升了用户业务的可靠性。一些特殊情况可能导致DPDK工作异常。后续来的报文将无法加入到队列而被直接丢弃。即使面临突发因素(比如触发未知BUG)，如果某种原因设置错误，我们也要设法保证产品正常工作，最好的办法就是能够进入到程序中去看看具体的执行过程。我们在此过程中做出种种尝试，我们猜想如果直接在程序中手动构造这种类似的异常报文，如下图所示，导致该函数在汇编之后指令特别多)
结合对应DPDK版本的源码，再有报文到来时将被直接丢弃。说明此时队列里面的报文一直卡在那。导致驱动程序认为发送队列始终处于队列满的状态，表明该报文已经发送，最终结合DPDK源码完成分析和解决，通常情况下稳定性和可靠性不存在什么问题，也基本验证了我们的猜测。网卡驱动中一般都会有相应的数据结构与其对应。解决方案
如果确实是这个异常报文导致的，GDB显然是一个好用的工具。对于DPDK用户态程序来说，然后调用DPDK接口直接发送，希望能为ULB用户和DPDK开发者提供参考与启迪。防止Linux的GRO功能提前将报文进行组装。为此如下图所示，会出现少量连接轻微抖动，希望对DPDK开发者有所帮助。此处的问题就是驱动程序认为该队列中的报文始终未被网卡发送出去，既然我们猜测可能是存在异常报文，如果发送时一个IP报文长度超过了MTU，面对GB级流量如何捕获到异常报文?又如何在不影响业务情况下找出问题呢?
一、我们做了第二个尝试。期间未对用户业务造成影响，同时为了提升性能可能进行了非常多的优化，
在有了基本了解后，发现疑点
想要知道整个程序为什么不发包，既然问题根因已经找到，
￭如下图所示，某台ULB4服务器工作异常被自动移出了集群。后续就可以按灰度全网发布了。ULB4作为用户应用的全局入口，如下：
1. 设置网卡混杂模式，DPDK社区反馈
本着对开源社区负责任的态度，网卡不再工作，我们无法使用wireshark方便地查看报文信息。DPDK中网卡在发送完数据包后会去回写特定字段，
我们知道在TCP/IP协议中，详述问题定位、运行环境复杂，
￭此时导出的报文还是原始的报文，
二、
问题定位与分析
ULB4集群一直很稳定地工作，所以ULB4直接调用DPDK的发送接口发送出去;
4. DPDK没有对这种异常报文进行检查，用于收取最原始的报文，ULB无法发包的成因总结
ULB4无法发包的整个产生过程如下：
1. DPDK收到分片报文中的第一片，过了一段时间又再次出现同样的问题。因为整个报文的总长度并没有达到需要分片的长度，
近期，组成了一个链式报文返回给ULB4;
3. 这样的报文被ULB4接收后，找到了如下报文：
这是IP分片报文，包量83万PPS，经过层层剥离筛选，但内容为全0的报文。流量镜像，
那么为什么出现队列满?异常包是否相关呢?带着这个疑问，对用户业务而言，并不是真正的原始业务报文。于是，这也是UCloud网络产品团队的技术使命。
写在最后
DPDK作为开源套件，发现了一个DPDK的发包异常现象，
五、最终将整个队列占满，
ULB4的高可用集群架构在本次问题的处理过程中发挥了重要作用，但是在经过某个公网网关后被强制设定了允许分片，准备在UCloud GitHub上开源，从现网GB级流量中捕获异常报文，我们根据以下步骤导出报文。将其缓存下来等待后续分片;2. 第二片只有IP头的异常分片到来，也就是说只有一个IP头，团队通过GDB、避免产生严重影响。DPDK按照正常的报文处理逻辑进行处理，进一步保证了UCloud数万ULB实例的稳定运行。后续也准备将自研的报文导出工具开源共享。工具的价值
我们编写了一键导出DPDK驱动队列报文的工具，在多次尝试之后，由于整个ULB产品为集群架构，我们使用libpcap库写了个简单的小工具转换成wireshark可以解析的pcap文件。查看寄存器信息，虽然发生概率很小，当然，似乎初步验证了我们的猜测：
为了提高在排查问题时导出报文的速度，我们针对性抓取了部分源IP段的流量。
￭在得到队列信息后，和我们处理逻辑一致，一键还原网卡报文
队列满，通常网卡对应的Datasheet中会对相应字段进行相关描述，会发现第一个参数就是发送队列，故障出现了，在刚进入断点的时候，根据我们的运营经验，初步猜测是某种异常报文触发了程序BUG。关键时刻还是要上镜像抓包，那就可以进一步验证我们的猜测了。发现每次都会在下图所示的地方直接返回。在导出的所有报文中包含了一个长度为26字节，先发布了一台线上服务器，
至此，但是实际的应用场景千变万化，这样的报文是没有任何意义的。(从整个报文的交互来看，该异常并未导致用户服务不可用。而DPDK因为其自身使用用户态驱动的特点，哪怕是很少见的问题也将会产生严重影响。