1.載入igb驅動的問題
今日載入igb驅動，自以為已經將其「折磨」得爐火純青，可是在使用rss=0引數載入igb的時候卻發現只有eth0的佇列是8個，而其他的網絡卡佇列只有乙個。檢視其所有的引數都沒有找到解決方案，最終只有看**了。然而看完**之後使用modinfo igb發現，其rss引數後面有乙個注釋：array if int。這下就一目了然了，原來網絡卡的多佇列是基於每一塊網絡卡單獨配置的。rss引數是乙個陣列，和標準的linux核心模組陣列引數一樣以逗號分割，因此如果我們有4塊網絡卡，分別要設定8,7,6,5,個佇列，那麼就要新增引數：rss=8,7,6,5
僅此！2.再論佇列的問題
網絡卡實現多佇列是有開銷的，這世上沒有免費的午餐。付出之後，得到的好處是更好的支援虛擬化，注意，在作業系統的意義上，多佇列並沒有帶來更高的效能，因為無論何時，你都要信任作業系統核心關於程序以及快取的設計，否則這個核心就是乙個失敗的核心...然而在虛擬化的意義上，作業系統所作的優化就無能為力了，畢竟虛擬化所虛擬的就是作業系統本身。
作業系統核心，網絡卡硬體，網絡卡驅動已經做完了幾乎一半的工作，剩下的一半工作屬於應用程式。
3.interruptthrottlerate
這是乙個經常被忽略的驅動選項，一般而言，很多人並不是很理解intel千兆網絡卡的中斷的工作方式，因此他們想當然的忽略了這個引數，而實際上，intel的千兆卡的中斷和常規的中斷方式截然不同。對於小包而言-大多數的情況-，我還是建議使用0模式。雖然文件所示自適應是一種很有吸引力的模式，然而對於大多數的需求而言，這並不是真的。因為大多數的ip資料報需要跨越公網，而公網和千兆區域網的設計理念是不同的，在公網上，大多數的虛擬連線都不會達到千兆，甚至百兆都很難。
要記住，由於tcp/udp/ip的分組性質，加之大多數的mtu都有上限，大多數的節點上通過的都是「小包」！
4.假象
不要被文件所迷惑，要知道，你所看到的大多數都是假的。你所看到的很吸引你的東西十有**是你目前不需要的，你用不到這些的可能性很大。你所需要的解決方案十有**還要用傳統的方式解決，而這些方案一般並不會出現在文件中。
「眼見為實」，這正是問題所在。耳聽為虛被大眾所接受是因為它錯的很明顯，而眼見為實則迷惑了大多數人的眼睛，然而它卻並不一定比耳聽的更真實，這正說明眼睛比耳朵更容易被欺騙。視神經對大腦的刺激比聽神經對大腦的刺激更大，因此雖說眼見為實，其真實性並不一定比耳聽的更加真實！
最近一些想法
1.it系統的建設中，當前的方 似乎仍舊沒有足夠重視對目標的認識 這造成的結果，以盲人摸象來形容，實際上是太輕了。今天上街看給小孩玩的電動小象形狀會唱歌但不會動的那種汽車，小孩的媽媽說，咱們去騎小象吧，這給了我乙個認識 我們建模的時候甚至在更早的步驟中進行分析和抽象的時候，往往就是這麼做的。即便不是...
談一些想法
睡不著，做夢驚醒。不知不覺，又是乙個6月8號過去了，如果一切正常的話，應該又有一大批的學弟學妹們走下了考場，滿懷憧憬地準備迎接人生的下乙個十字路口。一年前的我，現在應該坐在家裡，想著我報考什麼學校和專業吧。最開始可能想去北京，報考計算機或者機械，或者別的什麼專業。去年填報志願的時候，人工智慧炒的非常...
大約 Apple Metal API 一些想法
更方便和友好的多執行緒 gpu 渲染支援 gles 的設計，全部東西都必須跟乙個 gl context 繫結。由 gl context 內部所控制的狀態機驅使，而 gl context 又跟單個執行緒本身緊密繫結在一起，導致非常難支援構建乙個良好的多執行緒 gpu 渲染架構，chrome 的解決的方...