欧美性猛交xxxx免费看_牛牛在线视频国产免费_天堂草原电视剧在线观看免费_国产粉嫩高清在线观看_国产欧美日本亚洲精品一5区

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

如何用eBPF寫TCP擁塞控制算法?

Linux閱碼場(chǎng) ? 來(lái)源:csdn ? 作者:dog250 ? 2020-12-26 09:44 ? 次閱讀

其實(shí)不想用這個(gè)題目的,只因?yàn)門CP相關(guān)的東西比較吸引人的眼球,這篇文章的主題還是eBPF,而不是TCP。

用eBPF寫TCP擁塞控制算法只是本文所講內(nèi)容的一個(gè)再平凡不過(guò)的例子。

先看兩個(gè)問(wèn)題,或者說(shuō)是兩個(gè)痛點(diǎn):

內(nèi)核越來(lái)越策略化。

內(nèi)核接口不穩(wěn)定。

分別簡(jiǎn)單說(shuō)一下。

所謂內(nèi)核策略化就是說(shuō)越來(lái)越多的靈巧的算法,小tricks等靈活多變的代碼進(jìn)入內(nèi)核,舉例來(lái)講,包括但不限于以下這些:

TCP擁塞控制算法。

TC排隊(duì)規(guī)則,數(shù)據(jù)包調(diào)度算法。

各種查找的哈希算法。

這部分策略化的代碼幾乎都是用“回調(diào)函數(shù)”實(shí)現(xiàn)的,這在另一方面烘托了Linux內(nèi)核也是模塊化設(shè)計(jì)的,且機(jī)制和策略分離,當(dāng)需要一種新的算法時(shí),只需要register一組新的回調(diào)函數(shù)即可。

然而,…

然而不夠完美,因?yàn)樯鲜龅?點(diǎn),“內(nèi)核接口不穩(wěn)定”!即每一個(gè)內(nèi)核版本的數(shù)據(jù)結(jié)構(gòu)以及API都是不兼容的。

這意味著什么?

這意味著,即便是高度封裝好的算法模塊代碼,也需要為不同版本的Linux內(nèi)核維護(hù)一套代碼,當(dāng)涉及內(nèi)核模塊由于版本問(wèn)題不得不升級(jí)時(shí),數(shù)據(jù)結(jié)構(gòu)和api的適配工作往往是耗時(shí)且出力不討好的。

但其實(shí),很多算法根本就是與內(nèi)核數(shù)據(jù)結(jié)構(gòu),內(nèi)核api這些無(wú)關(guān)的。

兩個(gè)內(nèi)核版本,數(shù)據(jù)結(jié)構(gòu)只是字段變化了位置,新增了字段,更新了字段名字,即便如此,不得不對(duì)算法模塊進(jìn)行重新編譯…

如果能在模塊載入內(nèi)核的時(shí)候,對(duì)函數(shù)和數(shù)據(jù)結(jié)構(gòu)字段進(jìn)行重定位就好了!

我們的目標(biāo)是,一次編寫,多次運(yùn)行。

又是Facebook走在了前面,來(lái)自Facebook的BPF CO-RE(Compile Once – Run Everywhere):
http://vger.kernel.org/bpfconf2019_talks/bpf-core.pdf
沒(méi)錯(cuò),eBPF,就是它!

我們看下其描述:

BPF CO-RE talk discussed issues that developers currently run into when developing, testing, deploying, and running BPF applications at scale, taking Facebook’s experience as an example. Today, most types of BPF programs access internal kernel structures, which necessitates the need to compile BPF program’s C code “on the fly” on every single production machine due to changing struct/union layouts and definitions inside kernel. This causes many problems and inconveniences, starting from the need to have kernel sources available everywhere and in sync with running kernel, which is a hassle to set up and maintain. Reliance on embedded LLVM/Clang for compilation means big application binary size, increased memory usage, and some rare, but impactful production issues due to increased resource usage due to compilation. With current approach testing BPF programs against multitude of production kernels is a stressful, time-consuming, and error-prone process. The goal of BPF CO-RE is to solve all of those issues and move BPF app development flow closer to typical experience, one would expect when developing applications: compile BPF code once and distribute it as a binary. Having a good way to validate that BPF application will run without issues on all active kernels is also a must.

The complexity hides in the need to adjust compiled BPF assembly code to every specific kernel in production, as memory layout of kernel data structures changes between kernel versions and even different kernel build configurations. BPF CO-RE solution relies on self-describing kernel providing BTF type information and layout (ability to produce it was recently committed upstream). With the help from Clang compiler emitting special relocations during BPF compilation and with libbpf as a dynamic loader, it’s possible to reconciliate correct field offsets just before loading BPF program into kernel. As BPF programs are often required to work without modification (i.e., re-compilation) on multiple kernel versions/configurations with incompatible internal changes, there is a way to specify conditional BPF logic based on actual kernel version and configuration, also using relocations emitted from Clang. Not having to rely on kernel headers significantly improves the testing story and makes it possible to have a good tooling support to do pre-validation before deploying to production.

There are still issues which will have to be worked around for now. There is currently no good way to extract #define macro from kernel, so this has to be dealt with by copy/pasting the necessary definitions manually. Code directly relying on size of structs/unions has to be avoided as well, as it isn’t relocatable in general case. While there are some raw ideas how to solve issues like that in the future, BPF CO-RE developers prioritize providing basic mechanisms to allow “Compile Once - Run Everywhere” approach and significantly improve testing and pre-validation experience through better tooling, enabled by BPF CO-RE. As existing applications are adapted to BPF CO-RE, there will be new learning and better understanding of additional facilities that need to be provided to provide best developer experience possible.

該機(jī)制可以:

用eBPF的一組字節(jié)碼實(shí)現(xiàn)內(nèi)核模塊的一組回調(diào)函數(shù)。

對(duì)使用到的內(nèi)核數(shù)據(jù)結(jié)構(gòu)字段進(jìn)行重定位,適配當(dāng)前內(nèi)核的對(duì)應(yīng)偏移。

后果就是:

很多內(nèi)核算法模塊可以用eBPF來(lái)編寫了。

Linux 5.6用TCP擁塞控制算法舉了一例,我們看一下:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09903869f69f

可以看到,這個(gè)eBPF程序是與內(nèi)核版本無(wú)關(guān)的,你可以看到它的tcp_sock結(jié)構(gòu)體的定義:

struct tcp_sock { struct inet_connection_sock inet_conn; __u32 rcv_nxt; __u32 snd_nxt; __u32 snd_una; __u8 ecn_flags; __u32 delivered; __u32 delivered_ce; __u32 snd_cwnd; __u32 snd_cwnd_cnt; __u32 snd_cwnd_clamp; __u32 snd_ssthresh; __u8 syn_data:1, /* SYN includes data */ syn_fastopen:1, /* SYN includes Fast Open option */ syn_fastopen_exp:1,/* SYN includes Fast Open exp. option */ syn_fastopen_ch:1, /* Active TFO re-enabling probe */ syn_data_acked:1,/* data in SYN is acked by SYN-ACK */ save_syn:1, /* Save headers of SYN packet */ is_cwnd_limited:1,/* forward progress limited by snd_cwnd? */ syn_smc:1; /* SYN includes SMC */ __u32 max_packets_out; __u32 lsndtime; __u32 prior_cwnd;} __attribute__((preserve_access_index));

這里注意到兩點(diǎn):

該結(jié)構(gòu)體并非內(nèi)核頭文件里的對(duì)應(yīng)結(jié)構(gòu)體,它只包含了內(nèi)核對(duì)應(yīng)結(jié)構(gòu)體里TCP CC算法用到的字段,它是內(nèi)核對(duì)應(yīng)同名結(jié)構(gòu)體的子集。

preserve_access_index屬性表示eBPF字節(jié)碼在載入的時(shí)候,會(huì)對(duì)這個(gè)結(jié)構(gòu)體里的字段進(jìn)行重定向,滿足當(dāng)前內(nèi)核版本的同名結(jié)構(gòu)體字段的偏移。

我們?cè)诳聪耬BPF實(shí)現(xiàn)的TCP CC回調(diào)函數(shù)是個(gè)什么樣子:

BPF_TCP_OPS_3(tcp_reno_cong_avoid, void, struct sock *, sk, __u32, ack, __u32, acked){ struct tcp_sock *tp = tcp_sk(sk); if (!tcp_is_cwnd_limited(sk)) return; /* In "safe" area, increase. */ if (tcp_in_slow_start(tp)) { acked = tcp_slow_start(tp, acked); if (!acked) return; } /* In dangerous area, increase slowly. */ tcp_cong_avoid_ai(tp, tp->snd_cwnd, acked);}... SEC(".struct_ops")struct tcp_congestion_ops dctcp = { .init = (void *)dctcp_init, .in_ack_event = (void *)dctcp_update_alpha, .cwnd_event = (void *)dctcp_cwnd_event, .ssthresh = (void *)dctcp_ssthresh, .cong_avoid = (void *)tcp_reno_cong_avoid, .undo_cwnd = (void *)dctcp_cwnd_undo, .set_state = (void *)dctcp_state, .flags = TCP_CONG_NEEDS_ECN, .name = "bpf_dctcp",};

沒(méi)啥特殊的,幾乎和內(nèi)核模塊的寫法一樣,唯一不同的是:

它和內(nèi)核版本無(wú)關(guān)了。你用llvm/clang編譯出來(lái).o字節(jié)碼將可以被載入到所有的內(nèi)核。

它讓人感覺(jué)這是在用戶態(tài)編程

是的,這就是在用戶態(tài)寫的TCP CC算法,eBPF字節(jié)碼的對(duì)應(yīng)verifier會(huì)對(duì)你的代碼進(jìn)行校驗(yàn),它不允許可以crash內(nèi)核的eBPF代碼載入,你的危險(xiǎn)代碼幾乎無(wú)法通過(guò)verify。

如果你想搞明白這一切背后是怎么做到的,看兩個(gè)文件就夠了:

net/ipv4/bpf_tcp_ca.c

kernel/bpf/bpf_struct_ops.c

當(dāng)然,經(jīng)理不會(huì)知道這意味著什么。

浙江溫州皮鞋濕,下雨進(jìn)水不會(huì)胖。

原文標(biāo)題:用eBPF寫TCP擁塞控制算法

文章出處:【微信公眾號(hào):Linuxer】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

責(zé)任編輯:haq

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 內(nèi)核
    +關(guān)注

    關(guān)注

    3

    文章

    1383

    瀏覽量

    40438
  • TCP
    TCP
    +關(guān)注

    關(guān)注

    8

    文章

    1378

    瀏覽量

    79335

原文標(biāo)題:用eBPF寫TCP擁塞控制算法

文章出處:【微信號(hào):LinuxDev,微信公眾號(hào):Linux閱碼場(chǎng)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏

    評(píng)論

    相關(guān)推薦

    TCP協(xié)議的性能測(cè)試與評(píng)估方法

    的、基于字節(jié)流的傳輸層通信協(xié)議。它通過(guò)三次握手建立連接,使用序列號(hào)和確認(rèn)應(yīng)答機(jī)制保證數(shù)據(jù)的有序傳輸,并通過(guò)滑動(dòng)窗口機(jī)制控制數(shù)據(jù)流量,以避免網(wǎng)絡(luò)擁塞。 性能測(cè)試指標(biāo) 吞吐量(Throughput) :衡量單位時(shí)間內(nèi)成功傳輸?shù)臄?shù)據(jù)量,通常以Mbps或
    的頭像 發(fā)表于 01-22 10:03 ?171次閱讀

    TCP協(xié)議的安全性分析

    使用確認(rèn)機(jī)制來(lái)確保數(shù)據(jù)段被正確接收。如果一個(gè)段丟失,發(fā)送方將重新發(fā)送該段。 流量控制TCP使用窗口大小來(lái)控制發(fā)送方發(fā)送數(shù)據(jù)的速率,以避免接收方被過(guò)多的數(shù)據(jù)淹沒(méi)。 擁塞
    的頭像 發(fā)表于 01-22 09:48 ?123次閱讀

    TCP協(xié)議是什么

    在網(wǎng)絡(luò)通信的廣闊領(lǐng)域中,TCP(Transmission Control Protocol,傳輸控制協(xié)議)扮演著舉足輕重的角色。作為TCP/IP協(xié)議族中的核心協(xié)議之一,TCP位于網(wǎng)絡(luò)層
    的頭像 發(fā)表于 10-09 13:54 ?899次閱讀

    何用Jacinto內(nèi)部的GPtimer輸出PWM信號(hào)控制屏幕背光

    電子發(fā)燒友網(wǎng)站提供《如何用Jacinto內(nèi)部的GPtimer輸出PWM信號(hào)控制屏幕背光.pdf》資料免費(fèi)下載
    發(fā)表于 09-29 10:25 ?0次下載
    如<b class='flag-5'>何用</b>Jacinto內(nèi)部的GPtimer輸出PWM信號(hào)<b class='flag-5'>控制</b>屏幕背光

    EtherCAT轉(zhuǎn)Modbus TCP協(xié)議網(wǎng)關(guān)(JM-ECT-TCP

    JM-ECT-TCP網(wǎng)關(guān)實(shí)現(xiàn)EtherCAT網(wǎng)絡(luò)與Modbus TCP網(wǎng)絡(luò)之間的數(shù)據(jù)通訊,即將Modbus TCP設(shè)備轉(zhuǎn)換為EtherCAT設(shè)備。
    的頭像 發(fā)表于 09-07 17:05 ?412次閱讀
    EtherCAT轉(zhuǎn)Modbus <b class='flag-5'>TCP</b>協(xié)議網(wǎng)關(guān)(JM-ECT-<b class='flag-5'>TCP</b>)

    EtherCAT主站ModBus TCP協(xié)議網(wǎng)關(guān)(YC-ECTM-TCP

    遠(yuǎn)創(chuàng)智控YC-ECTM-TCP型網(wǎng)關(guān)實(shí)現(xiàn)Modbus TCP網(wǎng)絡(luò)與EtherCAT網(wǎng)絡(luò)的互連互通。該網(wǎng)關(guān)可實(shí)現(xiàn)雙向數(shù)據(jù)交換,實(shí)現(xiàn)EtherCAT設(shè)備和Modbus TCP控制器的數(shù)據(jù)交
    的頭像 發(fā)表于 08-25 09:38 ?440次閱讀
    EtherCAT主站ModBus <b class='flag-5'>TCP</b>協(xié)議網(wǎng)關(guān)(YC-ECTM-<b class='flag-5'>TCP</b>)

    tcp和udp的區(qū)別和聯(lián)系

    一、引言 在現(xiàn)代網(wǎng)絡(luò)通信中,數(shù)據(jù)傳輸是至關(guān)重要的。為了確保數(shù)據(jù)的可靠傳輸,網(wǎng)絡(luò)協(xié)議發(fā)揮著關(guān)鍵作用。傳輸控制協(xié)議(TCP)和用戶數(shù)據(jù)報(bào)協(xié)議(UDP)是兩種常用的網(wǎng)絡(luò)協(xié)議,它們?cè)谠S多應(yīng)用場(chǎng)景中發(fā)
    的頭像 發(fā)表于 08-16 11:06 ?684次閱讀

    神經(jīng)網(wǎng)絡(luò)如何用無(wú)監(jiān)督算法訓(xùn)練

    標(biāo)記數(shù)據(jù)的處理尤為有效,能夠充分利用互聯(lián)網(wǎng)上的海量數(shù)據(jù)資源。以下將詳細(xì)探討神經(jīng)網(wǎng)絡(luò)如何用無(wú)監(jiān)督算法進(jìn)行訓(xùn)練,包括常見(jiàn)的無(wú)監(jiān)督學(xué)習(xí)算法、訓(xùn)練過(guò)程、應(yīng)用及挑戰(zhàn)。
    的頭像 發(fā)表于 07-09 18:06 ?906次閱讀

    BLDC電機(jī)控制算法詳解

    算法。本文將詳細(xì)介紹BLDC電機(jī)的控制算法,包括電速算法、電流環(huán)控制算法、磁場(chǎng)導(dǎo)向
    的頭像 發(fā)表于 06-14 10:49 ?1224次閱讀

    運(yùn)動(dòng)控制算法有哪些

    運(yùn)動(dòng)控制算法是機(jī)器人學(xué)和自動(dòng)化領(lǐng)域中的核心技術(shù)之一,它們負(fù)責(zé)規(guī)劃和執(zhí)行機(jī)器人或自動(dòng)化設(shè)備的精確運(yùn)動(dòng)。以下是一些常見(jiàn)的運(yùn)動(dòng)控制算法,以及它們的基本原理和應(yīng)用場(chǎng)景。 PID
    的頭像 發(fā)表于 06-13 09:17 ?2925次閱讀

    TCP協(xié)議中的擁塞控制機(jī)制與網(wǎng)絡(luò)穩(wěn)定性

    TCP協(xié)議中的擁塞控制機(jī)制與網(wǎng)絡(luò)穩(wěn)定性的深度探討 隨著互聯(lián)網(wǎng)的快速發(fā)展,網(wǎng)絡(luò)流量呈現(xiàn)爆炸式增長(zhǎng),網(wǎng)絡(luò)擁塞問(wèn)題逐漸凸顯。為了維護(hù)網(wǎng)絡(luò)的穩(wěn)定運(yùn)行,TCP
    的頭像 發(fā)表于 04-19 16:42 ?491次閱讀

    eBPF動(dòng)手實(shí)踐系列三:基于原生libbpf庫(kù)的eBPF編程改進(jìn)方案簡(jiǎn)析

    在上一篇文章《eBPF動(dòng)手實(shí)踐系列二:構(gòu)建基于純C語(yǔ)言的eBPF項(xiàng)目》中,我們初步實(shí)現(xiàn)了脫離內(nèi)核源碼進(jìn)行純C語(yǔ)言eBPF項(xiàng)目的構(gòu)建。libbpf庫(kù)在早期和內(nèi)核源碼結(jié)合的比較緊密,如今的libbpf庫(kù)更加成熟,已經(jīng)完全脫離內(nèi)核源碼
    的頭像 發(fā)表于 03-19 14:19 ?921次閱讀
    <b class='flag-5'>eBPF</b>動(dòng)手實(shí)踐系列三:基于原生libbpf庫(kù)的<b class='flag-5'>eBPF</b>編程改進(jìn)方案簡(jiǎn)析

    基于原生libbpf庫(kù)的eBPF編程改進(jìn)方案

    為了簡(jiǎn)化 eBPF程序的開(kāi)發(fā)流程,降低開(kāi)發(fā)者在使用 libbpf 庫(kù)時(shí)的入門難度,libbpf-bootstrap 框架應(yīng)運(yùn)而生?;趌ibbpf-bootstrap框架的編程方案是目前網(wǎng)絡(luò)上看到的最主流編程方案。
    發(fā)表于 03-19 14:19 ?721次閱讀
    基于原生libbpf庫(kù)的<b class='flag-5'>eBPF</b>編程改進(jìn)方案

    以太網(wǎng)存儲(chǔ)網(wǎng)絡(luò)的擁塞管理連載案例(五)

    解決無(wú)損以太網(wǎng)網(wǎng)絡(luò)擁塞問(wèn)題的方法與光纖通道結(jié)構(gòu)相同。兩者都使用逐跳流量控制機(jī)制,只是實(shí)現(xiàn)方式不同而已。
    的頭像 發(fā)表于 03-04 11:17 ?954次閱讀
    以太網(wǎng)存儲(chǔ)網(wǎng)絡(luò)的<b class='flag-5'>擁塞</b>管理連載案例(五)

    TCP發(fā)展受阻的原因是什么呢?RDMA和Linux TCP技術(shù)解析

    在考慮今天如何開(kāi)始時(shí),我回顧了一下這兩天關(guān)于硬件和軟件之間分歧的主題演講。主要探討了擁塞控制如何在這個(gè)不斷發(fā)展的領(lǐng)域中增長(zhǎng)和演變。
    的頭像 發(fā)表于 02-20 10:52 ?1164次閱讀
    <b class='flag-5'>TCP</b>發(fā)展受阻的原因是什么呢?RDMA和Linux <b class='flag-5'>TCP</b>技術(shù)解析