一、概述      MAC轉發表是二層交換機原型中的核心内容，所有的數據操作(zuò)都是圍繞這(zhè)張表而來(lái)。前一篇文(wén)章中講到(dào)了(le)該表涉及的兩個核心字段：端口号與MAC地址。本篇文(wén)章專門(mén)講解一下(xià)該MAC轉發表的設計(jì)與表的操作(zuò)方法。 二、MAC轉發表的設計(jì)      MAC轉發表的設計(jì)我們還是遵循漸進式的方法，從(cóng)最基本的字段開(kāi)始，根據需要再逐步增加。      1）字段設計(jì)      從(cóng)前一篇文(wén)章分析，對(duì)于MAC轉發表來(lái)說，其核心字段就2個：端口号和(hé)MAC地址，故我們對(duì)其字段的設計(jì)也(yě)就采用(yòng)此二元數據。交換機的端口号一般不超過64，故用(yòng)char（8位）類型定義即可，MAC地址的位寬爲48位，可定義爲6個字節數組。一般在協議(yì)字段中或以協議(yì)字段作(zuò)爲字段的表結構定義中，采用(yòng)無符号類型做定義，這(zhè)樣方便數據與或運算(suàn)，也(yě)方便硬件移植。字段數據類型的定義一般也(yě)建議(yì)重定義爲簡寫方式，在讀寫代碼時(shí)，更好(hǎo)理(lǐ)解和(hé)把握數據是否溢出、越界等。
     數據類型重定義如下(xià)：

typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned int u32;
//typedef unsigned long u64;/*64位系統*/
/*請(qǐng)特别的注意!!!在32位系統下(xià)，long的數據位寬隻有32位，64位的數據類型必須使用(yòng)long long的方式定義*/
typedef unsigned long long u64;/*32位系統,實驗平台OpenBox-S4爲32位系統*/

      2）表結構設計(jì)      數據存儲結構的設計(jì)有很(hěn)多方式可選，如數組、多維數組、單向鏈表、雙向鏈表和(hé)樹結構等。在原型系統的設計(jì)中，因爲表結構定義會(huì)影響到(dào)整個代碼實現(xiàn)，且需要考慮将來(lái)硬件卸載的便捷性，所以我們一般建議(yì)采用(yòng)較爲簡單的表存儲結構。又因爲每條表項的大(dà)小(xiǎo)是固定空(kōng)間，所以采用(yòng)數組的形式是較優的選擇。
     先定義一條表項的數據結構如下(xià)：

struct row_port_mac
{
u8 port;
u8 pad;/*爲了(le)對(duì)齊做的補充*/
u8 mac[MAC_LEN];
};

     補充對(duì)齊：上(shàng)述表項一條寬度爲7個字節，如此按數組形式組織的話(huà)，則會(huì)讓mac字段在非内存對(duì)齊位置出現(xiàn)，導緻數據比較時(shí)需要兩次對(duì)比。若是跨了(le)CacheLine，則會(huì)導緻更長的時(shí)間損耗。具體原因請(qǐng)網上(shàng)搜索“内存對(duì)齊”深入學習。我們建議(yì)在定義數組項的時(shí)候一定按照8字節倍數對(duì)齊方式來(lái)定義，若小(xiǎo)于8字節，則補充爲8；若多于8，則再多補充直到(dào)成爲8的倍數（特别說明(míng)，這(zhè)是針對(duì)數組定義要求，不同數據結構根據分析會(huì)有不同的優化定義方法）。
     再定義整張表的數據結構如下(xià)：

#define OBX_MAC_MAX 128/*系統最多支持128條MAC表項*/
struct table_port_mac
{
struct row_port_mac row[OBX_MAC_MAX];
};

     3）表操作(zuò)方法設計(jì)      表的方法主要是指對(duì)表的操作(zuò)，通常包括表項的增、删、改和(hé)查四個動作(zuò)。這(zhè)些(xiē)表動作(zuò)的設計(jì)與表的結構定義和(hé)表的數據操作(zuò)方法相關，可以利用(yòng)對(duì)表數據的操作(zuò)進行優化和(hé)精簡。如在二維數據中進行任何操作(zuò)，都得先把表遍曆一次，找到(dào)空(kōng)位才能(néng)增加，找到(dào)對(duì)應的内容項才能(néng)修改和(hé)删除。
     根據二層交換的數據處理(lǐ)流程分析，在源MAC的學習過程中，學習到(dào)一個新MAC地址需要進行增加表項操作(zuò)，若已經學習到(dào)的MAC地址發生了(le)端口遷移，則需要更新其端口信息。在目的MAC查表過程中是一個單純的MAC地址查找過程。MAC表項的删除一般發生在MAC表老(lǎo)化的時(shí)候，後面文(wén)章單獨講。 三、MAC表功能(néng)方法設計(jì)      結合前面的表方法設計(jì)和(hé)二層交換的數據處理(lǐ)邏輯，我們暫将MAC轉發表的方法定義爲兩個：一是源MAC學習；二是目的MAC查找。      1）源MAC學習      源MAC學習是指将一個輸入分組的源MAC地址學習并保存到(dào)MAC轉發表中。若MAC轉發表中不存在該源MAC地址信息，則找一個空(kōng)白(bái)位置存儲。若MAC轉發表中已有該地址信息，則刷新（覆蓋）其端口号信息。在查找源MAC地址是否存在時(shí)，同時(shí)查找空(kōng)閑表項位置，這(zhè)樣隻用(yòng)遍曆一次表，即可完成兩件事(shì)情。另外(wài)就是查找到(dào)源MAC地址後，立即刷新其端口号，可以判斷并打印顯示，該MAC地址是否發生了(le)端口轉移。      2）目的MAC查找      目的MAC的查找，其目的是爲了(le)獲得查找MAC對(duì)應的端口号，查表結果有兩種情況，一是查找到(dào)了(le)，返回對(duì)應的端口号信息；二是沒有查找到(dào)，則不能(néng)返回正常端口數據，需要使用(yòng)特殊返回值表示，如-1。 四、總結與下(xià)一步      1）查表設計(jì)      MAC轉發表的方法設計(jì)爲什(shén)麽把二層交換的功能(néng)和(hé)表操作(zuò)混在了(le)一起？因爲在二層交換中，其核心數據處理(lǐ)流程就是針對(duì)MAC轉發表進行的一系列數據查找、存儲和(hé)更新動作(zuò)。按照其邏輯處理(lǐ)方式來(lái)設計(jì)可以讓學生更好(hǎo)理(lǐ)解MAC表的操作(zuò)流程與細節。
     在邏輯設計(jì)的過程中，我們需要針對(duì)一些(xiē)特定功能(néng)進行抽象、模塊化，比如表的四操作(zuò)。但(dàn)在具體實現(xiàn)過程中，其本身的邏輯處理(lǐ)也(yě)就是對(duì)表的内容進行處理(lǐ)，以數據流程爲主線進行設計(jì)比純模塊化的分層設計(jì)更容易讓學生掌握交換的處理(lǐ)過程。模塊化和(hé)分層可以放(fàng)到(dào)後期優化階段。
     表操作(zuò)的方法也(yě)并不一定要馬上(shàng)全部實現(xiàn)，根據邏輯的需要逐個實現(xiàn)，在實現(xiàn)過程中也(yě)會(huì)不斷修改完善。      2）MAC地址學習與查表實現(xiàn)      MAC地址的學習與查找是二層交換的核心，特别是MAC地址學習，如何設計(jì)快(kuài)速、高(gāo)效的學習方法，取決于我們對(duì)系統數據處理(lǐ)流程的深度理(lǐ)解與優化叠代。下(xià)一篇文(wén)章中會(huì)給出一種具體的實現(xiàn)方法供大(dà)家參考。 五、結語       歡迎您和(hé)學生們加入FAST開(kāi)源項目群溝通與探讨，一起體驗不一樣的系統設計(jì)過程。請(qǐng)先加微信号15116127200後邀請(qǐng)入群。