CN110022267A - 网络数据包处理方法及装置 - Google Patents

网络数据包处理方法及装置 Download PDF

Info

Publication number
CN110022267A
CN110022267A CN201810017450.XA CN201810017450A CN110022267A CN 110022267 A CN110022267 A CN 110022267A CN 201810017450 A CN201810017450 A CN 201810017450A CN 110022267 A CN110022267 A CN 110022267A
Authority
CN
China
Prior art keywords
network
interface card
network interface
packet
queue
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201810017450.XA
Other languages
English (en)
Inventor
石博
朱凌俊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN201810017450.XA priority Critical patent/CN110022267A/zh
Publication of CN110022267A publication Critical patent/CN110022267A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/622—Queue service order
    • H04L47/6225—Fixed service order, e.g. Round Robin
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/726—Reserving resources in multiple paths to be used simultaneously
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5018—Thread allocation

Abstract

本申请公开了一种网络数据包处理方法，所述方法包括：接收网络数据包；根据预设的流量分类算法确定所述网络数据包对应的处理进程；将所述网络数据包转发到所述对应的处理进程中。采用上述方法，解决了现有技术中存在的DPDK进程独占使用网卡的问题。

Description

网络数据包处理方法及装置
技术领域
本申请涉及计算机技术领域，具体涉及一种网络数据包处理方法及装置。
背景技术
随着网络通信设备和现代CPU等硬件性能的高速发展，网卡的带宽已从曾经的千兆、万兆扩展到如今的25G、100G，网卡的收发包性能日益提高，同时现代CPU性能的扩展通过多核的方式进行演进，使得通用处理器可以并行地处理网络负载。在云计算场景中，用户在虚拟机部署的应用要求底层存储系统在数据的读写时延上越低越好，IOPS越高越好。无论是硬件本身的变革，还是市场用户的需求，都要求云计算的分布式技术在低延迟、高吞吐量上前进。
现有技术下，通常采用DPDK数据包处理平台进行网络数据包的处理。DPDK是Intel公司开发的基于多核处理器的高性能数据包处理平台，现已开源，并有网卡公司如Mellanox直接与之合作，为开发者提供技术和需求支持。
但是，现有技术下采用DPDK数据包处理平台进行网络数据包的处理存在以下缺陷：一旦DPDK进程启动，会导致网卡被DPDK驱动独占使用，内核的应用程序无法正常服务。
发明内容
本申请提供一种网络数据包处理方法，以解决现有DPDK进程独占使用网卡的问题。
所述网络数据包处理方法，包括：
接收网络数据包；
根据预设的流量分类算法确定所述网络数据包对应的处理进程；
将所述网络数据包转发到所述对应的处理进程中。
可选的，所述网络数据包对应的处理进程包括：DPDK进程和内核驱动。
可选的，所述预设的流量分类算法，包括：
对DPDK进程和内核驱动分别分配不同的端口范围，DPDK进程使用该端口作为本端端口封装网络数据包；与该网络数据包对称的网络数据包到达网卡时根据目标端口匹配到DPDK进程。
可选的，当所述网络数据包对应的处理进程为DPDK进程时，所述将所述网络数据包转发到所述对应的处理进程中，包括将所述网络数据包转发到对应的网卡队列中。
可选的，所述网卡为两个或两个以上。
可选的，当网卡为两个或两个以上时，网卡之间互为主备关系。
可选的，所述网卡的工作机制包括：并发工作机制和/或容灾工作机制。
可选的，所述预设的流量分类算法，具体为：
在所述网卡上配置规则哈希表，每个所述网卡队列在相应的网卡哈希表里添加一条不同的规则，所述规则包括每个所述网卡队列需要缓存的网络数据包TCP/IP协议里的端口。
可选的，当网卡为两个以上时，为不同网卡上相同序号的网卡队列配置相同的规则。
可选的，当DPDK进程为客户端时，设置网卡队列的客户端规则，所述客户端规则包括每个网卡队列设置不同的端口范围作为目标端口。
可选的，当DPDK进程为服务端时，设置网卡队列的服务端规则，将每个网卡队列的服务端规则设置为目标端口与监听端口范围一致，源端口对服务端工作线程取模为队列序号。
可选的，在将所述网络数据包转发到与之对应的网卡队列中的步骤之后，包括：
与所述网卡队列对应的工作线程读取所述网卡队列中的网络数据包；
在用户态处理逻辑对所述网卡队列中的网络数据包进行协议栈解析和业务层处理生成响应数据；
对所述响应数据进行协议栈封装；
通过选择的网卡队列发送封装后的数据包。
可选的，所述工作线程为物理CPU核上运行的DPDK线程，与物理CPU核一对一绑定，被绑定的物理CPU核只运行绑定的工作线程，且每个工作线程与网卡上的网卡队列一一对应。
可选的，在选择网卡时包括采用以下算法：轮流发送或hash算法。
可选的，所述与网卡队列对应的工作线程读取所述网卡队列中的流量，包括：
所述与网卡队列对应的工作线程采用轮询方式读取不同网卡的网卡队列中的流量。
可选的，在初始化网卡时，开启网卡的isolate模式。
本申请还提供一种网络数据包处理装置，其特征在于，包括：
数据包接收单元，用于接收网络数据包；
进程确定单元，用于根据预设的流量分类算法确定所述网络数据包对应的处理进程；
数据包转发单元，用于将所述网络数据包转发到所述对应的处理进程。
与现有技术相比，本申请具有以下优点：
本申请提供一种网络数据包处理方法，所述方法包括：接收网络数据包；根据预设的流量分类算法确定所述网络数据包对应的处理进程；将所述网络数据包转发到所述对应的处理进程中。
本申请提供的网络数据包处理方法，根据预设的流量分类算法确定所述网络数据包对应的处理进程，实现了在流量包到达网卡时，将接收的网络数据包按照流量分类算法进行分类并转发到对应的处理进程(包括DPDK进程和内核驱动)中，本申请通过在网卡和DPDK程序中配置合适的流量分类算法，实现了DPDK进程只接管属于自己的网络数据包，DPDK进程在运行时对内核应用程序无任何副作用，解决了DPDK进程独占网卡的问题。
附图说明
图1是本申请第一实施例提供的一种网络数据包处理方法的流程图。
图2是本申请第一实施例提供的一种支持双网卡的网络数据包处理模型示意图。
图3是本申请第一实施例提供的一种网络数据包处理方法的进程运行流程图。
图4本申请第二实施例提供的一种网络数据包处理装置的示意图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本发明。但是本发明能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本发明内涵的情况下做类似推广，因此本发明不受下面公开的具体实施的限制。
本申请第一实施例提供了一种网络数据包处理方法。请参考图1和图2，图1示出了根据本申请的实施例提供的一种网络数据包处理方法的流程图，图2示出了本申请第一实施例提供的一种支持双网卡的网络数据包处理结构示意图。以下结合图1和图2进行详细说明。
步骤S101，接收网络数据包。
所述网络数据包，包括：需要DPDK进程处理的网络数据包和其他需要内核处理的数据包，其中需要内核处理的数据包包括：TCP/IP协议栈里的控制包(例如icmp/arp等控制包)、非DPDK规则的网络数据包。
所述接收网络数据包，指网络数据包通过网卡到达物理机，物理机的程序接受网络数据包之后，决定由哪个进程来处理网络数据包。
步骤S102，根据预设的流量分类算法确定所述网络数据包对应的处理进程。
所述处理进程，包括DPDK进程和内核驱动。
所述预设的流量分类算法，包括：对DPDK进程和内核驱动分别分配不同的源端口范围，DPDK进程使用该源端口作为本端端口封装网络数据包；与该网络数据包对称的网络数据包到达网卡时根据目标端口匹配到DPDK进程。
本申请主要关注TCP/IP数据包，流量分类算法采用的是TCP/IP协议里的五元组(包括源IP、源端口、目标IP、目标端口、协议类型)，主要与TCP/IP协议里的源端口和目的端口有关。为了保证DPDK进程运行时，不影响其他使用内核的程序，那么DPDK不能接管任何属于内核的数据包，所以DPDK进程作为客户端时的源端口范围最好与内核分开。源端口的取值范围是0～65535，可以调整内核的端口范围，例如让内核只使用0～61000，而剩下的61001～65535范围内的端口则为DPDK使用。
所述根据预设的流量分类算法确定所述网络数据包对应的处理进程，包括：根据预设的流量分类算法判断所述网络数据包中所包含的目标端口是否匹配DPDK进程使用的源端口范围，若是，确定所述网络数据包对应的处理进程为DPDK进程；若否，确定所述网络数据包对应的处理进程为内核驱动。例如，如果网络数据包的目标端口为61001，则通过匹配确定目标端口61001在DPDK进程使用的源端口范围61001～65535内，则确定所述网络数据包对应的处理进程为DPDK进程；如果网络数据包的目标端口为50000，则通过匹配确定目标端口61001不在DPDK进程使用的源端口范围61001～65535内，确定所述网络数据包对应的处理进程为内核驱动。
通过对DPDK进程和内核驱动分别分配不同的端口范围，实现了DPDK进程和内核应用程序各自流量分离，互不影响。
步骤S103，将所述网络数据包转发到所述对应的处理进程中。
所述将所述网络数据包转发到所述对应的处理进程中，包括：如果根据预设的流量分类算法确定所述网络数据包对应的处理进程为DPDK进程，则将所述网络数据包转发到DPDK进程中，如果根据预设的流量分类算法确定所述网络数据包对应的处理进程为内核驱动，则将所述网络数据包转发到内核驱动中。
仍沿用上述例子，如果网络数据包的目标端口为61001，则将所述网络数据包转发到DPDK进程中，如果网络数据包的目标端口为50000，则将所述网络数据包转发到内核驱动中。
当所述网络数据包对应的处理进程为DPDK进程时，所述将所述网络数据包转发到所述对应的处理进程中，包括将所述网络数据包转发到对应的网卡队列中。
一台物理机设置网卡的数量为一个或多个。优选的，为了提高IOPS(每秒处理的请求数)性能及设置容灾机制，一台物理机设置网卡的数量为两个或两个以上。当网卡为两个或两个以上时，网卡之间互为主备关系。多个网卡既可以并发工作，发挥多网卡收发能力，提高极限IOPS性能，也可以在一块网卡或其后端发生故障时，DPDK进程依然能正常服务，做到容灾。
如图2，其示出了本申请第一实施例提供的一种支持双网卡的网络数据包处理模型示意图。图2中，模块(a)和模块(b)表示物理机上的两块网卡，两块网卡在linux系统里以bonding等多种模式工作，不同模式下，网卡连接的不同交换机配置会有差异，不同交换机上转发的以太网数据包通过对应的网卡到达物理机，进而被内核驱动或DPDK进程处理。这样两块网卡可以形成主备关系，两者既可以并发工作，也可以在其中一块网卡或其后端交换机出现故障时，继续接收到达该物理机的流量，保证机器上的应用程序正常服务。
所述预设的流量分类算法，具体为：在所述网卡上配置规则哈希表，每个所述网卡队列在相应的网卡哈希表里添加一条不同的规则，所述规则包括每个所述网卡队列需要缓存的网络数据包TCP/IP协议里的端口。
需要说明的是，当DPDK进程退出时，配置的流量分类算法会从网卡的规则哈希表里删除，此时所有网络数据包都会转发给内核驱动，实现无缝切换。
当网卡为两个以上时，为不同网卡上相同序号的网卡队列配置相同的规则，以便当一个网卡出现故障时，其余网卡可以完全接管整个物理机网络流量，确保应用程序的可靠稳定运行。
当DPDK进程为客户端时，设置网卡队列的客户端规则，所述客户端流量规则包括每个网卡队列设置不同的端口范围作为目标端口。例如，队列1的规则是目标端口是61001～62000的网络数据包，队列2是目标端口是62001～63000的网络数据包，以此类推，且每个网卡上序号相同的队列使用的规则相同。
当DPDK进程为服务端时，设置网卡队列的服务端规则，将每个网卡队列的服务端规则设置为目标端口与监听端口范围一致，源端口对服务端工作线程取模为队列序号。服务端的流量规则除了监听的端口外，还要考虑服务端工作线程数，例如，服务端一共创建4个工作线程监听端口5000，与工作线程1绑定的网卡队列1，其规则是目标端口5000，源端口对4取模等于0的数据包，与工作线程2绑定的网卡队列2，其规则是目标端口5000，源端口对4取模等于1的数据包，队列3和队列4的规则以此类推。这样服务端监听的5000端口的数据包，通过均衡分布在服务端的4个网卡队列中，进一步均衡分配给与各网卡队列绑定的工作线程处理。
在将所述网络数据包转发到与之对应的网卡队列中的步骤之后，包括：
与所述网卡队列对应的工作线程读取所述网卡队列中的网络数据包；
在用户态处理逻辑对所述网卡队列中的网络数据包进行协议栈解析和业务层处理生成响应数据；
对所述响应数据进行协议栈封装；
通过选择的网卡队列发送封装后的数据包。
所述工作线程为物理CPU核上运行的DPDK线程，与物理CPU核一对一绑定，被绑定的物理CPU核只运行绑定的工作线程，且每个工作线程与网卡上的网卡队列一一对应。为了保证工作线程与网卡上的网卡队列一一对应，将工作线程使用的端口范围必须与其一一对应的网卡队列的规则保持一致。
例如，如果一个物理机上有8个物理CPU核，则在每个物理CPU核上绑定一个工作线程，即存在8个工作线程，每个工作线程与网卡上的队列一一对应，工作线程1对应网卡上的队列1，工作线程2对应网卡上的队列2，如队列1的规则是目标端口是61001～62000的流量，队列2是目标端口是62001～63000的流量，客户端作为请求包的发起者，其每个工作线程内使用的端口范围须与其一一对应的队列的规则保持一致，即工作线程1只能使用61001～62000作为源端口与服务器建立链接，当服务器发回响应数据时，数据报文的目标端口范围就是61001～62000，这样就可以被工作线程1通过队列1来接收到，进而实现了TCP/IP协议栈一个流上的数据在同一个工作线程内处理，不会导致线程切换。
如图2，工作线程模型为图1中的(i)模块，每个工作线程独占一个物理CPU核，工作线程以轮询方式访问两个网卡的某个队列，当队列上有流量时，则被该工作线程读走。在本申请中，工作线程1独占CPU1，轮询两个网卡的队列1，工作线程2独占CPU1，轮询两个网卡的队列2，依次类推，工作线程分别使用多核系统中的一个物理核，且与网卡上的队列一一对应，互不冲突。每个队列上的流量被工作线程接收后，在用户态处理逻辑(如图2的(j)模块)进行协议栈解析和业务层处理，准备好响应数据后，再通过这个工作线程做协议栈封装，选择一个网卡队列发送出去。这样属于TCP/IP层一个流上的网络数据包总是被一个线程接收、处理、发送，中间没有线程切换，没有系统调用，将延迟降低到最小。在选择网卡队列发送封装后的数据包时，选择网卡时可以采用以下算法：轮流发送或hash算法。
图3是本申请第一实施例提供的一种网络数据包处理方法的进程运行流程图。主要分为如下步骤：
1.进程启动时，根据应用需要，创建N个工作线程，并将每个工作线程绑定到固定的CPU核上，保证工作线程之间不会争抢同一个CPU，否则会导致性能下降，不能发挥多核系统的性能特长；
2.初始化DPDK参数，主要是DPDK在运行期间需要用到的巨页(huge page)内存，根据实际需要和物理机配置，设置内存大小；
3.初始化两个网卡，首先开启网卡的isolate模式，只有开启isolate，才能保证DPDK驱动和内核驱动共存，即DPDK只接管匹配网卡规则的流量，而将其他流量转发给内核处理。从巨页内存里创建内存池，为每个网卡的不同队列配置接收内存，网卡的队列数目与应用程序的工作线程数相同，且一一对应，再分别配置每个队列上接收数据包和发送数据包的最大值。最后启动网卡，此时DPDK驱动已生效，但由于没有配置流量规则，所以DPDK不会收到流量。
4.在每个网卡的每个队列上配置客户端的流量规则。本申请关注的只有TCP/IP数据包，流量规则主要与协议里的源端口和目的端口有关。为了保证DPDK进程运行时，不影响其他使用内核的程序，那么DPDK不能接管任何属于内核的数据包，所以DPDK进程作为客户端时的源端口范围最好与内核分开。源端口的取值范围是0～65535，通过调整内核的端口范围，例如让内核只使用0～61000，而剩下的61001～65535范围内的端口则为DPDK使用。
本申请设计的模型中，由于发送包是工作线程通过哈希选择发送网卡，然后由网卡上对应的队列转发出去，因而配置的流量规则只与接收报文有关，用于网卡收到以太网数据时进行过滤区分，分配给不同的接收队列。其中客户端规则，是在每个队列上分别配置不一样的端口范围作为目标端口，如队列1的规则是目标端口是61001～62000的流量，队列2是目标端口是62001～63000的流量，以此类推，且每个网卡上序号相同的队列使用的规则相同。同时，客户端作为请求包的发起者，其每个工作线程内使用的端口范围须与其一一对应的队列的规则保持一致，即工作线程1只能使用61001～62000作为源端口与服务器建立链接，当服务器发回响应数据时，数据报文的目标端口范围就是61001～62000，这样就可以被工作线程1通过队列1来接收到，进而实现了TCP/IP协议栈一个流上的数据在同一个工作线程内处理，不会导致线程切换。
5.若该DPDK进程同时也要作为服务端，则需要给每个队列配置服务端的流量规则，与客户端一致，服务端的流量规则只与接收报文相关。在TCP/IP协议栈中，服务端会监听一个固定端口的流量，那么为了充分发挥服务端多核线程并发工作的性能，本申请将每个队列的服务端规则设计为目标端口等于监听端口，源端口对服务端工作线程数取模等于队列序号，这样保证不同机器发给服务端的不同流量可以为多队列、多线程均衡接收处理。
6.每个工作线程开始轮询2个网卡上与之对应的队列，若能读到数据包，则在用户态处理逻辑完成协议栈解析，转发给应用层做业务逻辑处理，再通过本线程做协议栈封装，选择一个网卡发送出去，发送过程与网卡的流量规则无关。选择网卡的算法很多，可以简单的做轮流发送，也可以做hash算法等。
7.直到收到退出信号，进程才退出。
与上述网络数据包处理方法相对应的，本申请还提供了一种网络数据包处理装置。由于所述装置的实施例基本相似于方法的实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。所述一种网络数据包处理装置实施例如下：
请参考图4，其示出了根据本申请的第二实施例提供的一种网络数据包处理装置的示意图。
所述实现数据库高可用性的装置，包括：数据包接收单元401、进程确定单元402、数据包转发单元403。
数据包接收单元401，用于接收网络数据包；
进程确定单元402，用于根据预设的流量分类算法确定所述网络数据包对应的处理进程；
数据包转发单元403，用于将所述网络数据包转发到所述对应的处理进程。
可选的，所述网络数据包对应的处理进程包括：DPDK进程和内核驱动。
可选的，所述预设的流量分类算法，包括：
对DPDK进程和内核驱动分别分配不同的端口范围，DPDK进程使用该端口作为本端端口封装网络数据包；与该网络数据包对称的网络数据包到达网卡时根据目标端口匹配到DPDK进程。
可选的，当所述网络数据包对应的处理进程为DPDK进程时，所述将所述网络数据包转发到所述对应的处理进程中，包括将所述网络数据包转发到对应的网卡队列中。
可选的，所述网卡为两个或两个以上。
可选的，当网卡为两个或两个以上时，网卡之间互为主备关系。
可选的，所述网卡的工作机制包括：并发工作机制和/或容灾工作机制。
可选的，所述预设的流量分类算法，具体为：
在所述网卡上配置规则哈希表，每个所述网卡队列在相应的网卡哈希表里添加一条不同的规则，所述规则包括每个所述网卡队列需要缓存的网络数据包TCP/IP协议里的端口。
可选的，当网卡为两个以上时，为不同网卡上相同序号的网卡队列配置相同的规则。
可选的，当DPDK进程为客户端时，设置网卡队列的客户端规则，所述客户端规则包括每个网卡队列设置不同的端口范围作为目标端口。
可选的，当DPDK进程为服务端时，设置网卡队列的服务端规则，将每个网卡队列的服务端规则设置为目标端口与监听端口范围，源端口对服务端工作线程取模为队列序号。
可选的，所述装置还包括：
数据读取单元，用于数据包转发单元工作之后，在与所述网卡队列对应的工作线程读取所述网卡队列中的网络数据包；
响应数据生成单元，用于在用户态逻辑对所述网卡队列中的网络数据包进行协议栈解析和业务层处理生成响应数据；
数据封装单元，用于对所述响应数据进行协议栈封装；
数据包发送单元，用于通过选择的网卡队列发送封装后的数据包。
可选的，所述工作线程为物理CPU核上运行的DPDK线程，与物理CPU核一对一绑定，被绑定的物理CPU核只运行绑定的工作线程，且每个工作线程与网卡上的网卡队列一一对应。
可选的，在选择网卡时包括采用以下算法：轮流发送或hash算法。
可选的，所述与网卡队列对应的工作线程读取所述网卡队列中的流量，包括：
所述与网卡队列对应的工作线程采用轮询方式读取不同网卡的网卡队列中的流量。
可选的，所述装置包括：在初始化网卡时，开启网卡的isolate模式。
本申请实施例虽然以较佳实施例公开如上，但其并不是用来限定本申请实施例，任何本领域技术人员在不脱离本申请实施例的精神和范围内，都可以做出可能的变动和修改，因此本申请实施例的保护范围应当以本申请实施例权利要求所界定的范围为准。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
本领域技术人员应明白，本申请实施例的实施例可提供为方法、系统或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

Claims (17)

1.一种网络数据包处理方法，其特征在于，包括：
接收网络数据包；
根据预设的流量分类算法确定所述网络数据包对应的处理进程；
将所述网络数据包转发到所述对应的处理进程中。
2.根据权利要求1所述的网络数据包处理方法，其特征在于，所述网络数据包对应的处理进程包括：DPDK进程和内核驱动。
3.根据权利要求1所述的网络数据包处理方法，其特征在于，所述预设的流量分类算法，包括：
对DPDK进程和内核驱动分别分配不同的端口范围，DPDK进程使用该端口作为本端端口封装网络数据包；与该网络数据包对称的网络数据包到达网卡时根据目标端口匹配到DPDK进程。
4.根据权利要求1所述的网络数据包处理方法，其特征在于，当所述网络数据包对应的处理进程为DPDK进程时，所述将所述网络数据包转发到所述对应的处理进程中，包括将所述网络数据包转发到对应的网卡队列中。
5.根据权利要求4所述的网络数据包处理方法，其特征在于，包括：所述网卡为两个或两个以上。
6.根据权利要求5所述的网络数据包处理方法，其特征在于，包括：当网卡为两个或两个以上时，网卡之间互为主备关系。
7.根据权利要求6所述的网络数据包处理方法，其特征在于，所述网卡的工作机制包括：并发工作机制和/或容灾工作机制。
8.根据权利要求3或5所述的网络数据包处理方法，其特征在于，所述预设的流量分类算法，具体为：
在所述网卡上配置规则哈希表，每个所述网卡队列在相应的网卡哈希表里添加一条不同的规则，所述规则包括每个所述网卡队列需要缓存的网络数据包TCP/IP协议里的端口。
9.根据权利要求8所述的网络数据包处理方法，其特征在于，包括：当网卡为两个以上时，为不同网卡上相同序号的网卡队列配置相同的规则。
10.根据权利要求8所述的网络数据包处理方法，其特征在于，当DPDK进程为客户端时，设置网卡队列的客户端规则，所述客户端规则包括每个网卡队列设置不同的端口范围作为目标端口。
11.根据权利要求8所述的网络数据包处理方法，其特征在于，当DPDK进程为服务端时，设置网卡队列的服务端规则，将每个网卡队列的服务端规则设置为目标端口与监听端口范围一致，源端口对服务端工作线程取模为队列序号。
12.根据权利要求4所述的网络数据包处理方法，其特征在于，在将所述网络数据包转发到与之对应的网卡队列中的步骤之后，包括：
与所述网卡队列对应的工作线程读取所述网卡队列中的网络数据包；
在用户态处理逻辑对所述网卡队列中的网络数据包进行协议栈解析和业务层处理生成响应数据；
对所述响应数据进行协议栈封装；
通过选择的网卡队列发送封装后的数据包。
13.根据权利要求12所述的网络数据包处理方法，其特征在于，所述工作线程为物理CPU核上运行的DPDK线程，与物理CPU核一对一绑定，被绑定的物理CPU核只运行绑定的工作线程，且每个工作线程与网卡上的网卡队列一一对应。
14.根据权利要求13所述的网络数据包处理方法，其特征在于，在选择网卡时包括采用以下算法：轮流发送或hash算法。
15.根据权利要求12所述的网络数据包处理方法，其特征在于，所述与网卡队列对应的工作线程读取所述网卡队列中的流量，包括：
所述与网卡队列对应的工作线程采用轮询方式读取不同网卡的网卡队列中的流量。
16.根据权利要求1所述的网络数据包处理方法，其特征在于，在初始化网卡时，开启网卡的isolate模式。
17.一种网络数据包处理装置，其特征在于，包括：
数据包接收单元，用于接收网络数据包；
进程确定单元，用于根据预设的流量分类算法确定所述网络数据包对应的处理进程；
数据包转发单元，用于将所述网络数据包转发到所述对应的处理进程。
CN201810017450.XA 2018-01-09 2018-01-09 网络数据包处理方法及装置 Pending CN110022267A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810017450.XA CN110022267A (zh) 2018-01-09 2018-01-09 网络数据包处理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810017450.XA CN110022267A (zh) 2018-01-09 2018-01-09 网络数据包处理方法及装置

Publications (1)

Publication Number Publication Date
CN110022267A true CN110022267A (zh) 2019-07-16

Family

ID=67187575

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810017450.XA Pending CN110022267A (zh) 2018-01-09 2018-01-09 网络数据包处理方法及装置

Country Status (1)

Country Link
CN (1) CN110022267A (zh)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110505151A (zh) * 2019-08-22 2019-11-26 深信服科技股份有限公司 流量转发方法、装置、设备及存储介质
CN110636139A (zh) * 2019-10-15 2019-12-31 广州市品高软件股份有限公司 一种云负载均衡的优化方法及系统
CN110912873A (zh) * 2019-11-05 2020-03-24 郑州信大捷安信息技术股份有限公司 一种基于dpdk的双协议栈实现系统及实现方法
CN111211942A (zh) * 2020-01-03 2020-05-29 山东超越数控电子股份有限公司 一种数据包的收发方法、设备及介质
CN111447155A (zh) * 2020-03-24 2020-07-24 广州市百果园信息技术有限公司 数据传输方法、装置、设备及存储介质
CN111694783A (zh) * 2020-06-11 2020-09-22 福建宏创科技信息有限公司 一种应用于dpi设备的并行数据分析方法和装置
CN112749028A (zh) * 2021-01-11 2021-05-04 科大讯飞股份有限公司 网络流量处理方法、相关设备及可读存储介质
CN113518130A (zh) * 2021-08-19 2021-10-19 北京航空航天大学 一种基于多核处理器的分组突发负载均衡方法及系统
CN113722074A (zh) * 2021-09-15 2021-11-30 京东科技信息技术有限公司 一种数据处理方法、装置及相关设备
CN114095251A (zh) * 2021-11-19 2022-02-25 南瑞集团有限公司 一种基于dpdk与vpp的sslvpn实现方法
CN117319224A (zh) * 2023-10-15 2023-12-29 上海同星智能科技有限公司 汽车总线虚拟通道的实现方法及实现系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104281493A (zh) * 2014-09-28 2015-01-14 般固(北京)科技股份有限公司 一种提升应用交付通讯平台多进程程序性能的方法
US20150244804A1 (en) * 2014-02-21 2015-08-27 Coho Data, Inc. Methods, systems and devices for parallel network interface data structures with differential data storage service capabilities
CN105577567A (zh) * 2016-01-29 2016-05-11 国家电网公司 基于Intel DPDK的网络数据包并行处理方法
CN106209506A (zh) * 2016-06-30 2016-12-07 瑞斯康达科技发展股份有限公司 一种虚拟化深度包检测流量分析方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150244804A1 (en) * 2014-02-21 2015-08-27 Coho Data, Inc. Methods, systems and devices for parallel network interface data structures with differential data storage service capabilities
CN104281493A (zh) * 2014-09-28 2015-01-14 般固(北京)科技股份有限公司 一种提升应用交付通讯平台多进程程序性能的方法
CN105577567A (zh) * 2016-01-29 2016-05-11 国家电网公司 基于Intel DPDK的网络数据包并行处理方法
CN106209506A (zh) * 2016-06-30 2016-12-07 瑞斯康达科技发展股份有限公司 一种虚拟化深度包检测流量分析方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
FELVEN: ""DPDK原理概述"", 《HTTPS://BLOG.CSDN.NET/ZHAOXINFAN/ARTICLE/DETAILS/78408945》 *

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110505151A (zh) * 2019-08-22 2019-11-26 深信服科技股份有限公司 流量转发方法、装置、设备及存储介质
CN110505151B (zh) * 2019-08-22 2021-11-19 深信服科技股份有限公司 流量转发方法、装置、设备及存储介质
CN110636139A (zh) * 2019-10-15 2019-12-31 广州市品高软件股份有限公司 一种云负载均衡的优化方法及系统
CN110636139B (zh) * 2019-10-15 2020-07-31 广州市品高软件股份有限公司 一种云负载均衡的优化方法及系统
CN110912873A (zh) * 2019-11-05 2020-03-24 郑州信大捷安信息技术股份有限公司 一种基于dpdk的双协议栈实现系统及实现方法
CN110912873B (zh) * 2019-11-05 2021-10-29 郑州信大捷安信息技术股份有限公司 一种基于dpdk的双协议栈实现系统及实现方法
CN111211942A (zh) * 2020-01-03 2020-05-29 山东超越数控电子股份有限公司 一种数据包的收发方法、设备及介质
CN111447155B (zh) * 2020-03-24 2023-09-19 广州市百果园信息技术有限公司 数据传输方法、装置、设备及存储介质
CN111447155A (zh) * 2020-03-24 2020-07-24 广州市百果园信息技术有限公司 数据传输方法、装置、设备及存储介质
CN111694783A (zh) * 2020-06-11 2020-09-22 福建宏创科技信息有限公司 一种应用于dpi设备的并行数据分析方法和装置
CN112749028A (zh) * 2021-01-11 2021-05-04 科大讯飞股份有限公司 网络流量处理方法、相关设备及可读存储介质
CN113518130A (zh) * 2021-08-19 2021-10-19 北京航空航天大学 一种基于多核处理器的分组突发负载均衡方法及系统
CN113518130B (zh) * 2021-08-19 2023-03-24 北京航空航天大学 一种基于多核处理器的分组突发负载均衡方法及系统
CN113722074A (zh) * 2021-09-15 2021-11-30 京东科技信息技术有限公司 一种数据处理方法、装置及相关设备
CN114095251A (zh) * 2021-11-19 2022-02-25 南瑞集团有限公司 一种基于dpdk与vpp的sslvpn实现方法
CN114095251B (zh) * 2021-11-19 2024-02-13 南瑞集团有限公司 一种基于dpdk与vpp的sslvpn实现方法
CN117319224A (zh) * 2023-10-15 2023-12-29 上海同星智能科技有限公司 汽车总线虚拟通道的实现方法及实现系统

Similar Documents

Publication Publication Date Title
CN110022267A (zh) 网络数据包处理方法及装置
US20200241927A1 (en) Storage transactions with predictable latency
CN110892380B (zh) 用于流处理的数据处理单元
CN105511954B (zh) 一种报文处理方法及装置
JP2015528231A (ja) 仮想マシンのフローの物理的なキューへのオフロード
US20200259763A1 (en) Intelligent resource selection for received content
US9910687B2 (en) Data flow affinity for heterogenous virtual machines
TW200847694A (en) System and method for multicore communication processing
US11379405B2 (en) Internet small computer interface systems extension for remote direct memory access (RDMA) for distributed hyper-converged storage systems
CN108933829A (zh) 一种负载均衡方法及装置
CN106020926A (zh) 一种用于虚拟交换机技术中数据传输的方法及装置
CN112041826A (zh) 用于网络接口卡的细粒度业务整形分流
US10616116B1 (en) Network traffic load balancing using rotating hash
CN109561054A (zh) 一种数据传输方法、控制器及接入设备
US11575620B2 (en) Queue-to-port allocation
CN115509644B (zh) 算力卸载方法、装置、电子设备和存储介质
US20220413910A1 (en) Execution job compute unit composition in computing clusters
US9525713B1 (en) Measuring server availability and managing traffic in adaptive bitrate media delivery
WO2022186997A1 (en) Job target aliasing in disaggregated computing systems
WO2019095942A1 (zh) 一种数据传输方法及通信设备
CN113037812A (zh) 数据包调度方法、装置、电子设备、介质和智能网卡
US9774512B1 (en) Measuring server availability and managing traffic in adaptive bitrate media delivery
US20150254100A1 (en) Software Enabled Network Storage Accelerator (SENSA) - Storage Virtualization Offload Engine (SVOE)
US20150254196A1 (en) Software Enabled Network Storage Accelerator (SENSA) - network - disk DMA (NDDMA)
Kumari et al. Study of Traffic Based Load Balancing Algorithm in the SDN

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40010941

Country of ref document: HK

RJ01 Rejection of invention patent application after publication

Application publication date: 20190716

RJ01 Rejection of invention patent application after publication