[發明專利]數據包接收方法、裝置、電子設備及存儲介質

在審

• 申請號: 202111595979.8
• 申請日: 2021-12-24
• 公開（公告）號: CN114371942A
• 公開（公告）日: 2022-04-19
• 發明（設計）人: 陳冬冬
• 申請（專利權）人: 銳捷網絡股份有限公司
• 主分類號: G06F9/54
• 分類號: G06F9/54;G06F9/50
• 代理公司: 暫無信息
• 代理人: 暫無信息

本發明實施例提供一種數據包接收方法、裝置、電子設備及存儲介質。所述方法包括：在響應收包中斷事件并關閉收包中斷后，判斷收包工作隊列上一次接收的數據包的收包數量是否大于第一預設數量閾值且收包耗時小于第一預設時長；若是，則休眠第二預設時長；若否，則啟動所述收包工作隊列接收數據包，并記錄本次收取的數據包的收包數量和收包耗時。本發明實施例提供的數據包接收方法，通過優化網口驅動NAPI收包機制，有效的解決了網絡數據泛洪導致設備故障的問題，提高了設備的可靠性。

技術領域

本發明實施例涉及通信技術領域，具體涉及一種數據包接收方法、裝置、電子設備及存儲介質。

背景技術

現有技術中，Linux系統在接收數據包時采用NAPI(New API)機制，該機制將中斷方式與輪詢方式相結合，中斷的優點是響應及時，如果數據量較小，則不會占用太多的CPU時間；缺點是數據量大時，會產生過多中斷，而每個中斷都要消耗不少的CPU時間，從而導致效率反而不如輪詢高。輪詢方式與中斷方式相反，它更適合處理大量數據，因為每次輪詢不需要消耗過多的CPU時間；缺點是即使只接收很少數據或不接收數據時，也要占用CPU時間。NAPI是兩者的結合，數據量低時采用中斷方式，數據量高時采用輪詢方式。

當數據包到來時，首先將數據包存入緩存區，然后打開收包中斷，進入收包中斷處理流程，在收包中斷處理流程中，首先關閉收包中斷，然后等待對應的輪詢函數被調度，當輪詢函數被調度后，每次讀取一定數量的數據包，如果讀取完數據包后緩存區還有多余的數據包，則等待下次調度輪詢函數時讀取，若緩存區中數據包接收完畢，則退出輪詢，重新打開收包中斷。

當收到大量報文時，收包驅動會處于收包工作隊列輪詢狀態，屬于軟中斷級別，會搶占CPU資源，導致其他業務無法正常調度。

發明內容

針對現有技術中的缺陷，本發明實施例提供了一種數據包接收方法、裝置、電子設備及存儲介質。

第一方面，本發明實施例提供一種數據包接收方法，包括：

在響應收包中斷事件并關閉收包中斷后，判斷收包工作隊列上一次接收的數據包的收包數量是否大于第一預設數量閾值且收包耗時小于第一預設時長；

若是，則休眠第二預設時長；

若否，則啟動所述收包工作隊列接收數據包，并記錄本次收取的數據包的收包數量和收包耗時。

如上述方法，可選地，所述判斷收包工作隊列上一次接收的數據包的收包數量是否大于第一預設數量閾值且收包耗時小于第一預設時長之后，還包括：

清零收包工作隊列上一次接收數據包時記錄的收包數量和收包耗時。

如上述方法，可選地，所述第二預設時長等于所述第一預設時長與所述收包耗時之差。

如上述方法，可選地，在響應收包中斷事件之前，還包括：

根據CPU內核數量，確定所述第一預設數量閾值和所述第一預設時長。

如上述方法，可選地，所述休眠第二預設時長之后，還包括：

開啟收包中斷。

如上述方法，可選地，所述啟動所述收包工作隊列接收數據包，并記錄本次收取的數據包的收包數量和收包耗時，包括：

啟動所述收包工作隊列接收數據包：

更新本次收取的數據包的收包數量；

若所述收包數量大于第二預設數量閾值或確定已接收完所有數據包，則停止接收數據包，并確定本次收取數據包的收包耗時；

開啟收包中斷。

第二方面，本發明實施例提供一種數據包接收裝置，包括：