DPDK报文分类与访问控制

dpdk提供了一个访问控制库,提供了基于一系列分类规则对接收到的报文进行分类的能力。
ACL库用来在一系列规则上执行N元组查找,可以实现多个分类和对每个分类查找最佳匹配(最高优先级),ACL库的api提供如下基本操作:

  • 创建一个新的访问控制(AC)环境实例(context)
  • 添加规则到这个环境实例
  • 为这个实例里所有的规则,创建必需的运行时结构体来指针报文分类
  • 执行接收报文分类
  • 删除AC环境实例和对应的运行时结构体,并释放内存

概述
1.规则定义
当前的实现允许用户对将要执行的报文分类需要的每一个context指定它独有规则(字段集合)。但这在规则字段上有一些限制条件:
    规则定义的第一个字段必须是一个字节的长度
    之后的字段必须以4个连续的字节分组
这主要是为性能考虑,查找函数处理第一个输入字节做为这个流的设置的一部分,然后这查找函数的内部循环被展开来同时处理4字节的输入。
要定义规则的每一个字段,需要使用如下的结构体:

1 struct rte_acl_field_def {
2     uint8_t type;        /*< type - ACL_FIELD_TYPE. */
3     uint8_t size;        /*< size of field 1,2,4, or 8. */
4     uint8_t field_index; /*< index of field inside the rule. */
5     uint8_t input_index; /*< 0-N input index. */
6     uint32_t offset;     /*< offset to start of field. */
7 };

type
字段的类型,有3种选项:
    _MASK    表示有值和掩码的IP地址字段,定义相关的bit位
    _RANGE   表示端口字段的低位和高位值
    _BITMASK 表示协议标识字段的值和掩码位

size 这个参数定义了字段的字节数大小。允许的值范围有(1,2,4,8)bytes,注意,由于输入字节的分组,1或2字节的字段必须定义为连续的来组成4字节连续。通用,最好的做法是定义8或更多字节数的字段,这样构建进程会消除那些乱的字段。

field_index
一个0开始的值,用来指定字段在规则内部的位置,0~n-1表示n个字段。

input_index
上面提到过,所有输入字段,除了第一个,其他必须以4个连续字节分组,这个input_index就是来指定字段在那个组。

offset
这个定义了字段的偏移量,为查找指定了从缓冲区的起始位置的偏移。

举个栗子,定义一个IPv4的五元组的分类:

1 struct ipv4_5tuple {
2     uint8_t  proto;
3     uint32_t ip_src;
4     uint32_t ip_dst;
5     uint16_t port_src;
6     uint16_t port_dst;
7 };

需要使用下面的字段定义数组:

 1 struct rte_acl_field_def ipv4_defs[5] = {
 2     /* first input field - always one byte long. */
 3     {
 4         .type = RTE_ACL_FIELD_TYPE_BITMASK,
 5         .size = sizeof (uint8_t),
 6         .field_index = 0,
 7         .input_index = 0,
 8         .offset = offsetof (struct ipv4_5tuple, proto),
 9     },
10     /* next input field (IPv4 source address) - 4 consecutive bytes. */
11     {
12         .type = RTE_ACL_FIELD_TYPE_MASK,
13         .size = sizeof (uint32_t),
14         .field_index = 1,
15         .input_index = 1,
16         .offset = offsetof (struct ipv4_5tuple, ip_src),
17     },
18     /* next input field (IPv4 destination address) - 4 consecutive bytes. */
19     {
20         .type = RTE_ACL_FIELD_TYPE_MASK,
21         .size = sizeof (uint32_t),
22         .field_index = 2,
23         .input_index = 2,
24         .offset = offsetof (struct ipv4_5tuple, ip_dst),
25     },
26     /*
27     * Next 2 fields (src & dst ports) form 4 consecutive bytes.
28     * They share the same input index.
29     */
30     {
31         .type = RTE_ACL_FIELD_TYPE_RANGE,
32         .size = sizeof (uint16_t),
33         .field_index = 3,
34         .input_index = 3,
35         .offset = offsetof (struct ipv4_5tuple, port_src),
36     },
37     {
38         .type = RTE_ACL_FIELD_TYPE_RANGE,
39         .size = sizeof (uint16_t),
40         .field_index = 4,
41         .input_index = 3,
42         .offset = offsetof (struct ipv4_5tuple, port_dst),
43     },
44 };

一个典型的IPv4五元组规则如下:

source addr/mask destination addr/mask source ports dest ports protocol/mask
192.168.1.0/24 192.168.2.31/32 0:65535 1234:1234 17/0xff

任何带有协议ID为17(UDP),源地址为192.168.1.[0-255],目的地址为192.168.2.31,源端口在[0-65535],目的端口为1234的ipv4报文将会匹配上面的规则。

定义IPv6 2元组: <protocol, IPv6 source address>的报文分类,
IPv6 头:

1 struct struct ipv6_hdr {
2     uint32_t vtc_flow; /* IP version, traffic class & flow label. */
3     uint16_t payload_len; /* IP packet length - includes sizeof(ip_header). */
4     uint8_t proto; /* Protocol, next header. */
5     uint8_t hop_limits; /* Hop limits. */
6     uint8_t src_addr[16]; /* IP address of source host. */
7     uint8_t dst_addr[16]; /* IP address of destination host(s). */
8 } __attribute__((__packed__));

需要使用下面的字段定义数组:

 1 struct struct rte_acl_field_def ipv6_2tuple_defs[5] = {
 2     {
 3         .type = RTE_ACL_FIELD_TYPE_BITMASK,
 4         .size = sizeof (uint8_t),
 5         .field_index = 0,
 6         .input_index = 0,
 7         .offset = offsetof (struct ipv6_hdr, proto),
 8     },
 9     {
10         .type = RTE_ACL_FIELD_TYPE_MASK,
11         .size = sizeof (uint32_t),
12         .field_index = 1,
13         .input_index = 1,
14         .offset = offsetof (struct ipv6_hdr, src_addr[0]),
15     },
16     {
17         .type = RTE_ACL_FIELD_TYPE_MASK,
18         .size = sizeof (uint32_t),
19         .field_index = 2,
20         .input_index = 2,
21         .offset = offsetof (struct ipv6_hdr, src_addr[4]),
22     },
23     {
24         .type = RTE_ACL_FIELD_TYPE_MASK,
25         .size = sizeof (uint32_t),
26         .field_index = 3,
27         .input_index = 3,
28         .offset = offsetof (struct ipv6_hdr, src_addr[8]),
29     },
30     {
31         .type = RTE_ACL_FIELD_TYPE_MASK,
32         .size = sizeof (uint32_t),
33         .field_index = 4,
34         .input_index = 4,
35         .offset = offsetof (struct ipv6_hdr, src_addr[12]),
36     },
37 };

一个典型的IPv4二元组规则如下:

source addr/mask protocol/mask
2001:db8:1234:0000:0000:0000:0000:0000/48 6/0xff

任何带有协议ID为6 (TCP),源地址在
[2001:db8:1234:0000:0000:0000:0000:0000 - 2001:db8:1234:ffff:ffff:ffff:ffff:ffff] 之间的报文会匹配上的规则。

时间: 2024-10-24 17:39:55

DPDK报文分类与访问控制的相关文章

Httpd安装,request报文以及相关访问控制

1.Centos7系统下实现httpd-2.2的安装,并分别实现prefork.worker.event等几种工作方式 prefork prefork是一个两级进程模型,非线程的模式,其实通过由父进程管理创建子进程,子进程响应的相应的请求的方式来运行的.以prefork模式运行的httpd,在启动之际就预派生fork了一些子进程,然后等待请求.每个子进程只有一个线程,在一个时间点内只能处理一个请求. 优点:成熟.稳定.兼容所有新老模块.进程之间完全独立,无须担心线程安全的问题. 缺点:一个进程相

一种基于uCos-II操作系统和lwIP协议栈的IEEE-1588主站以及基于该主站的报文处理方法

本发明公开了一种基于uCos‐II操作系统和lwIP协议栈的IEEE‐1588主站以及应用于电力系统的支持IEEE‐1588协议的主时钟(IEEE‐1588主站)的实现方法.该方法是在一个低成本的硬件平台上,借助uCos‐II操作系统和TCP/IP的协议栈,对以太网数据进行了分类处理,实现了在同一个以太网端口提供基于二层和三层报文交换的IEEE‐1588的主站功能.另外,通过使用不同的操作系统进程来处理E2E和P2P对时,实现了两种对时模式在同一端口上的共存. 技术领域 [0001] 本发明属于

请求、响应报文

HTTP:  通信双方如果想要通信就必须遵循一定的规则,我们把这个规则称之为HTTP协议! 报文:  HTTP协议通信的内容我们称之为:报文  报文格式: 报文首部 空行 报文主体 请求报文 请求首部:请求首行和请求头部 空行 请求主体 响应报文: 响应首部 空行 响应主体 报文分类: 请求报文:浏览器发送给服务器端的内容 get请求 GET /Hello/index.jsp HTTP/1.1  Accept: */* Accept-Language: zh-CN User-Agent: Moz

Socket编程实践(16) --TCP/IP各层报文(1)

以太网帧格式 说明1:链路层的数据包,称为以太网帧. 说明2:链路层不识别IP地址[因为IP地址是逻辑地址],链路层识别物理网卡MAC地址[硬件地址]. 说明3:需要根据IP地址找到对方的MAC地址(ARP地址解析协议)[MAC -> IP地址方向地址解析:RARP反向地址解析协议]. 说明4:应用层根据对等方的IP地址进行通讯,在数据封装过程中,链路层需要目的地址的MAC地址从何而来?需要将IP地址转换成MAC地址,也就是地址解析. 以太网首部代码: struct ethernet_hdr {

计算机网络(5)-----ICMP协议和PING程序

控制报文协议(Internet Control Message Protocol) 定义 它是TCP/IP协议族的一个子协议,用于在IP主机.路由器之间传递控制消息.控制消息是指网络通不通.主机是否可达.路由是否可用等网络本身的消息. 简介 ICMP报文就像是IP报文的小弟,总顶着IP报文的名头出来混.因为ICMP报文是在IP报文内部的,如图: IP协议并不是一个可靠的协议,它不保证数据被送达,那么,自然的,保证数据送达的工作应该由其他的模块来完成.其中一个重要的模块就是ICMP(网络控制报文)

第一章:Http概述

第一章:Http概述 引言 web浏览器.服务器和相关的web应用程序都是通过http相互通信的,http是现代全球英特网中使用的公共语言. 本章主要内容 1.web客户端与服务器是如何通信的 2.资源(表示web内容)来自何方 3.web事务(请求与响应)是怎样工作的 4.http通信所使用的报文(请求报文/响应报文) 5.底层TCP网络协议 6.不同的http协议变体 1.2web客户端与服务器 web内容都是存储在web服务器上的.web服务器所使用的是http协议,因此也经常称web服务

Web内容管理系统 Magnolia 启程-挖掘优良的架构(3)

<h1>Author and Public instances</h1> 第一个关键观念:instance-实例.每一个项目都必须至少有一个Author实例和至少一个Public实例.下面将告诉你为什么: 基本概念:JCR JSR-170定义:是一个高级的信息管理 系统,该系统是对传统的数据仓库的扩展,它提供了诸如版本控制.全文检索,访问控制,内容分类.访问控制.内容事件监视等内容服务. Java Content Repository  API(JSR-170)试图建立一套标准的A

网络服务器监控

一.监控介绍: 他是通过一种代理将数据传递到监控平台的手段. 二.监控方式一(SNMP+RRDTool+CACTI): SNMP(simple network management protocol):简单网络管理协议 RRDtool:绘图工具,他是将收集到的数据通过加工,绘制成某种图形. cacti(php):将图形数据展示出来 1.snmp有三种版本,分别是snmp v1,snmp v2,snmpv3: snmp v1:它是基于communitils来实现的.communty的名字就是双方认

IEEE1588协议简介

IEEE1588协议,又称PTP(precise time protocol,精确时间协议)具有亚微秒级别时间同步精度,于2002年发布version1,2008年发布version2. IEEE1588协议的同步原理,所提出的Delay-response mechanism(延时响应机制)如图1所示. 图1 PTP协议延迟响应机制 图中所描述的PTP报文为以下几种: (1)sync同步报文 (2)Follow_up跟随报文 (3)Delay_req延迟请求报文 (4)Delay_resp延迟响