dpdk

内存映射 Linux 内核给每个进程都提供了一个独立的虚拟地址空间，并且这个地址空间是连续的。这样，进程就可以很方便地访问内存，更确切地说是访问虚拟内存。 虚拟地址空间的内部又被分为内核空间和用户空间两部分，不同字长（也就是单个 CPU 指令可以处理数据的最大长度）的处理器，地址空间的范围也不同。比如最常见的 32 位和 64 位系统，如图： 并不是所有的虚拟内存都会分配物理内存，只有那些实际使用的虚拟内存才分配物理内存，并且分配后的物理内存，是通过内存映射来管理的。 内存映射，其实就是将虚拟内存地址映射到物理内存地址。为了完成内存映射，内核为每个进程都维护了一张页表（页表实际上存储在 CPU 的内存管理单元 MMU 中），记录虚拟地址与物理地址的映射关系。 当进程访问的虚拟地址在页表中查不到时，系统会产生一个缺页异常，进入内核空间分配物理内存、更新进程页表，最后再返回用户空间，恢复进程的运行。（ 内存调用，都只在首次访问时才分配，也就是通过缺页异常进入内核中，再由内核来分配内存。 ） 多级页表和大页 MMU 规定了一个内存映射的最小单位，也就是页，通常是 4 KB 大小。这样，每一次内存映射，都需要关联 4 KB 或者 4KB 整数倍的内存空间。 多级页表（Multilevel page tables）就是把内存分成区块来管理，将原来的映射关系改成区块索引和区块内的偏移

dpdk_18_05 应用笔记： l3fwd 例程 查询网卡的 pci 地址 机器上有 4 个的 I350 网卡。 现在只是使用其中 01:00.0 和 01:00.1 两个网卡来绑定到 DPDK 作为测试。 lspci | grep Eth > 01:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection ( rev 01 ) > 01:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection ( rev 01 ) > 01:00.2 Ethernet controller: Intel Corporation I350 Gigabit Network Connection ( rev 01 ) > 01:00.3 Ethernet controller: Intel Corporation I350 Gigabit Network Connection ( rev 01 ) 编译 情况1. 编译的时候没有网卡的驱动。( 使用 ，后续都是以这个为例子) EXTRA_CFLAGS = "-O0 -g3" make 情况1. 编译的时候加上网卡的驱动。( 暂不使用 ) I350 使用的是

1. 主函数分析 1 /* 命令行解析 2 * 参数输入 ./l2fwd -c 0x3 -n 4 -- -p 3 -q 1 3 * -c 为十六进制的分配的逻辑内核数量 4 * -n 为十进制的内存通道数量，EAL参数和程序参数用--分开 5 * -q 为分配给每个核心的收发队列数量（端口数量) 6 * -p为十六进制的分配的端口数 7 * -t 为可选默认10s打印时间间隔参数 8 */ 9 int main(int argc, char **argv) 10 { 11 struct lcore_queue_conf *qconf; 12 int ret; 13 uint16_t nb_ports; 14 uint16_t nb_ports_available = 0; 15 uint16_t portid, last_port; 16 unsigned lcore_id, rx_lcore_id; 17 unsigned nb_ports_in_mask = 0; 18 unsigned int nb_lcores = 0; 19 unsigned int nb_mbufs; 20 21 /* init EAL */ 22 /* 初始化EAL参数，并解析参数，系统函数getopt以及getopt_long， 23 * 这些处理命令行参数的函数，处理到“--”时就会停止，分割参

前言 所谓的dpdk大页内存的实现，说白了就是dpdk自己实现了一套大页内存的使用库，这个和libhugetlbfs.so是类似的，就是自己实现了大页内存的申请，释放操作, 替代了传统的malloc, free系统调用。先从整体上看下dpdk大页内存有哪些内容。 当应用层需要申请内存时，直接调用rte_malloc接口进行内存申请； 而rte_malloc实际上是从memzone内存区获取内存的，这个内存区存储着已经被所有应用层申请的内存。那memzone内存区中的内存又是从哪里来的呢？答案是直接从rte_memseg段内存中获取来的， 这个段内存中维护着当前哪些段内存还没有被使用。而段内存又是从哪里获取到内存的呢？答案是从每个大页内存中获取，将物理内存上连续的大页存放到一个段内存中。由此可见，rte_malloc最终的底层调用，是从大页内存申请内存空间的，也可以验证dpdk的实现说白了就是自己实现了一个malloc, free的内存管理方式。下面一一来看下大页内存，段内存，内存区，以及ret_malloc的实现。 目录 1、大页内存的映射 1.1、大页内存初始化 1.2、大页内存共享配置映射 1.3、大页内存映射 1.3.1、大页表的创建 1.3.2、第一次大页映射 1.3.3、虚拟地址转为物理地址 1.3.4、将物理地址进行排序 1.3.5、第二次大页映射 1.3.6

DPDK快速上手（linux） 本文档主要来自linux_gsg-18.02.pdf的翻译，翻译肯定有不妥之处，请批评指正，我会随后修改，不胜感激。 1. 介绍 本文档包含有关DPDK（Data Plane Development Kit的缩写）软件的安装和配置的说明，目的就是让用户快速用起来。本文档描述怎样在linux应用环境下编译和运行一个DPDK应用程序，而不过多深入细节。 1.1文档路线图 以下是针对所有DPDK文档建议的阅读顺序： 发布说明（Release Notes）： 提供具体的发布信息，包括支持特性、限制、问题改进、问题报告等等。也提供以FAQ形式的常见问题的回答。 快速上手指南（Getting Started Guide），即本文档： 描述在不同的操作系统上如何安装和配置DPDK软件；帮助用户快速用起来。 编程者指南（programmer's guide）： 描述： 软件架构和怎么用它（通过例子），特别是在linux应用环境下。 DPDK的内容，系统构建（包括用在DPDK根目录 Makefile中的命令，用来构建开发工具包和应用程序）以及移植应用程序的准则。 软件中使用的优化以及新开发应考虑的优化。 还提供术语表。 API参考（API Reference）： 提供有关DPDK函数、数据结构和其它编程结构的详细信息。 示例应用程序用户指南（sample

原创翻译，转载请注明出处。 分层调度器的时机主要体现在TX侧，正好在传递报文之前。它的主要目的是在每个网络节点按照服务级别协议来对不同的流量分类和对不同的用户的报文区分优先级并排序。 一、概述 分层调度器跟以前使用网络处理器实现的每条流或一组流的报文队列和调度的流量管理器很相似。它看起来像在传输之前的一个临时存储了很大数量报文的缓冲区（入队操作）。当网卡TX请求更多报文去发送的时候，这些报文递交给网卡TX的预定义的SLA的报文选择逻辑模块之后会删除。（出队操作）。 分层调度器对大数量的报文队列做了优化。当只需要小数量的队列时，会使用消息传递队列来替代。更多详情参考"Worst Case Scenarios for Performance"。 二、分层调度 如下图： 分层的第一级是 Ethernet TX 1/10/40端口，之后的分级是子端口，流水线，流分类和队列。 有代表性的是，每一个子端口表示一个预定义好的用户组，而每一个流水线表示一个个人用户。每一个流分类表示不同的流量类型，流量类型包含了具体的丢包率，时延，抖动等需求，比如语音，视频或数据传输。每一个队列从一到多个相同用户相同类型的连接里接待（原文是动词：host）报文。 下面的表格对每个分层做了功能描述： # 级别 兄弟 功能描述 1 Port 0 1、以太端口1/10/40 GbE输出； 2、多个端口具有相同的优先级

前言：QoS是网络中提供差异化服务的重要方法，它通过区分不同的流量和优先级，为不同的应用和使用者提供不同质量的网络服务，比如，金融网络，可能购买了专线，要求延迟小，更不能忍受丢包，自然优先级就高些；又比如网络直播和游戏，对于网络的延迟要求非常高，而普通的上网用户则没有这么高的要求（土豪除外）。DPDK中提供了QoS的参考框架，包含了多个流程组件，十分有趣。 一.DPDK QoS 概述 在DPDK提供的QoS框架中，一个复杂的处理流程被分成了几个不同的处理阶段，如下图所示： 对于这些流程中模块，其具体解释是这样的： 从这个图中可以看出，整个包的处理过程被分成了4个阶段完成。 1.第一阶段是在线程0中的,主要的工作就是接收包然后进行检查校验。 2.第二阶段是一个重点，主要工作是进行流分类,测速和负载均衡。把不同的流量导到不同的工作负载核上。 3.第三阶段是在不同的负载核上处理业务报文。 4.第四阶段也是一个非常重要的阶段，主要工作是根据算法调度，丢弃，最后发送出去。 这次重点介绍QoS的部分，也就是第四阶段，第二阶段的流分类和负载均衡在后面再进行单独说明。 二.DPDK QoS模块分析 因为重点分析的是第四阶段的处理过程，所以，这个阶段中主要包含3个模块：测速标记模块（流量监督，police），弃包策略模块（拥塞避免,dropper），调度模块（拥塞管理,sched）

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 分布式技术的发展，深刻地改变了我们编程的模式和思考软件的模式。值 2019 岁末，PingCAP 联合 InfoQ 共同策划出品“分布式系统前沿技术 ”专题， 邀请众多技术团队共同参与，一起探索这个古老领域的新生机。本文出自我司 CTO 黄东旭，为「分布式系统 in 2010s」 系列第三篇。 上篇 我们聊了软件构建方式和演化，今天我们来聊聊硬件吧！ SSD 普及的深远影响 如果说云的出现是一种商业模式的变化的话，驱动这个商业革命的推手就是最近十年硬件的快速更新。比起 CPU，存储和网络设备的进化速度更加迅速。最近五年，SSD 的价格 (包括 PCIe 接口) 的成本持续下降，批量采购的话已经几乎达到和 HDD 接近的价格。 <center>近 5 年 SSD 成本曲线</center> SSD 的普及，对于存储软件厂商的影响是深远的。 其一，是极大地缓解了 IO 瓶颈。对于数据库厂商来说，可以将更多的精力花在其他事情，而不是优化存储引擎上。最近两年发生了一些更大的变化，NVMe 正在成为主流，我们很早就在 Intel Optane 进行实验和投资，类似这样的非易失内存的技术，正在模糊内存和存储的界限，但是同时对开发者带来挑战也是存在的。举一个简单的例子，对于 Optane 这类的非易失内存

导读：5G的商用以及IoT、AI等技术的成熟推动着云技术的发展。无时不刻产生的数据洪流，对云的网络架构和处理数据的能力提出了新的需求，为了满足这些需求，下一代虚拟网络技术路在何方？在探讨这个问题之前，我们以腾讯云数据中心网络为例，介绍一下它的技术发展脉络。 一、腾讯云数据中心网络的技术发展脉络 1. 从千兆到万兆： 2014年，腾讯公有云服务器接入带宽从千兆迈入了万兆。 2. 从万兆到25G： 2017年，腾讯公有云服务器接入带宽从万兆向25G转变，这种转变主要来自于业务对 网络吞吐 的性能诉求。 3. 从25G到50-100G： 未来的1~2年，公有云服务器接入带宽将全面向100G转变。 高密计算 （单台虚拟化服务器的CPU核数越来越多） 、高密存储 （单台存储服务器的盘数和磁盘容量越来越高）、 AI、HPC 的发展，对网络的高吞吐和低延迟提出了更高要求。 不同的服务器接入带宽，对虚拟化网络的架构和扩展性会提出不一样的要求。在100G的网络时代，虚拟化网络架构会是怎样的？ 二、腾讯云100G时代下的VPC架构剖析 1.宿主机vSwitch能力 云网络发展早期， 网络虚拟化的vSwitch通常使用内核模块来实现， 基于netfilter的钩子定制encap/decap/安全组/qos等逻辑，快速满足业务要求。但是 基于内核实现的vSwitch有几个问题： (1