usbnet驅動程序和網絡子系統

我正在進行項目「AVB」橋接。我們正在通過以太網進行音頻視頻流式傳輸。數據包流式傳輸通過USB進行。它與USB-ETH（MAC）芯片一樣，USB連接到主機端。我們使用「usbnet.c」驅動程序。我們有兩個應用程序（用戶空間進程）：usbnet驅動程序和網絡子系統

1）提供同步的守護進程。

2）發送音頻分組的講話者程序（1722）。

在usbnet中實現了名爲.ndo_start_xmit的函數指針。而且我們已經使用這個函數指針來註冊我們的函數，這樣我們實現的函數就會在上層傳輸數據包時被調用。當我們單獨運行守護進程時，系統工作得很好。但是，只要我們並行地開始講話者程序，對於來自守護程序的一些數據包，xmit函數不會被調用。頻率。從發言人程序發送的數據包比守護程序發送的數據包高得多。所以它就像通過同一接口發送數據包的發言者程序一樣，也會影響守護進程由於這種影響而導致的行爲。但如何解決這個問題仍然困境...

讓我清楚瞭解更多。

現在假設我有兩個應用程序通過相同的接口傳輸數據包，例如eth6。根據我們所知道的知識，我們知道當有一個數據包要傳輸時，會調用undo_start_xmit。但是其中一個應用要求數據包應該在125毫秒內完全從MAC中傳輸出去。當我運行第一個應用程序時，讓我們命名爲「A」，數據包在每個計算的125毫秒時離開MAC。該時間由應用程序本身控制。但是，當我開始執行應用程序「B」時，「A」應用程序數據包不會每隔125毫秒發送一次數據包。由於應用程序B以8,000 /秒發送數據包，並且「A」發送@ 8 /秒。

我認爲子系統中的軟件隊列將來自套接字的所有數據包排隊，將所有「A」應用程序數據包和許多「B」應用程序數據包堆積起來，然後在所有堆中調用ndo_start_xmit上傳「A」應用包進行傳輸。因此，我們無法在MAC每隔125毫秒傳輸數據包。

來源

2013-12-11 Sumeet_Jain

除非您的應用程序下面的tx隊列可以優先，否則我看不到任何明顯的信息答案。你提供了。是否可以檢查較低級別的tx隊列計數，以便可以保持內容不變或減小其大小，以便延遲不會成爲問題？ –

..還有另一個通知，你可以得到一個數據包已被處理併成功傳輸，某種完成事件？ –

有一個叫做netif_queue_stopped（）的函數：它測試傳輸隊列是否被阻塞，我打算實現這個來知道與ndo_start_xmit鏈接的隊列的狀態。將很快更新結果:) - Sumeet –

我認爲你要找的是Linux Hardware Multiqueue API。

來源

2013-12-11 13:43:01

H朋友，你能詳細解釋一下這個問題嗎？。這裏討論了哪種類型的隊列（硬件）以及我如何實現它。這將是一個很大的幫助。 -Sumeet –

usbnet驅動程序和網絡子系統

回答

相關問題