eth1phy
㈠ phy，mac，switch晶元有什麼區別
一、功能方面的區別
1、MAC晶元的功能，乙太網數據鏈路層其實包含MAC（介質訪問控制）子層和LLC（邏輯鏈路控制）子層。一塊乙太網卡MAC晶元的作用不但要實現MAC子層和LLC子層的功能。
2、PHY的功能就是實現CSMA/CD的部分功能，可以檢測到網路上是否有數據在傳送，如果有數據在傳送中就等待，一旦檢測到網路空閑，再等待一個隨機時間後將送數據出去。
如果兩塊網卡碰巧同時送出了數據，這時候，沖突檢測機構可以檢測到沖突，然後各等待一個隨機的時間重新發送數據。
二、數據傳輸流程的區別
1、MAC是從PCI匯流排收到IP數據包（或者其他網路層協議的數據包）後，將之拆分並重新打包成最大1518Byte，最小64Byte的幀。這個幀裡麵包括了目標MAC地址、自己的源MAC地址和數據包裡面的協議類型。
2、PHY在發送數據的時候，收到MAC過來的數據（PHY沒有幀的概念，都是數據而不管什麼地址數據還是CRC），每4bit就增加1bit的檢錯碼，然後把並行數據轉化為串列流數據，再按照物理層的編碼規則把數據編碼，再變為模擬信號把數據送出去。
3、Phy-Mac-Switch分屬osi不同層。eth是點對點通訊，兩個及以上點要交換eth數據就必須通過switch。
三、信號上的區別
1、PHY晶元，主要是將這些模擬信號進行解碼，通過MII等介面，將數字信號傳送出去。在解碼的過程中，它只是做信號的轉換，而不對數字信號進行任何的處理，即使一幀有問題的數據，它也會如實的轉發出去。
2、switch晶元是對幀數據的內容做處理，更新MAC地址列表等等，是先有PHY後有switch。
(1)eth1phy擴展閱讀：
把太網媒體接入控制器MAC和物理介面收發器PHY整合進同一晶元，能去掉許多外接元器件。
乙太網MAC由IEEE-802.3乙太網標準定義。它實現了一個數據鏈路層。最新的MAC同時支持10Mbps和100Mbps兩種速率。通常情況下，它實現MII介面。
媒體獨立介面，它是IEEE-802.3定義的乙太網行業標准。它包括一個數據介面，以及一個MAC和PHY之間的管理介面(圖1)。MII數據介面總共需要16個信號。管理介面是個雙信號介面：一個是時鍾信號，另一個是數據信號。通過管理介面，上層能監視和控制PHY。
物理介面收發器，它實現物理層。IEEE-802.3標準定義了乙太網PHY。它符合IEEE-802.3k中用於10BaseT(第14條)和100BaseTX(第24條和第25條)的規范。
PHY提供絕大多數模擬支持，但在一個典型實現中，仍需外接6、7隻分立元件及一個區域網絕緣模塊。絕緣模塊一般採用一個1：1的變壓器。 這些部件的主要功能是為了保護PHY免遭由於電氣失誤而引起的損壞。
㈡ 鍩轟簬openstack緗戠粶妯″紡鐨剉lan鍒嗘瀽
OpenStack姒傚康
OpenStack鏄涓涓緹庡浗鍥藉惰埅絀鴻埅澶╁矓鍜孯ackspace鍚堜綔鐮斿彂鐨勶紝浠Apache璁稿彲璇佹巿鏉冿紝騫朵笖鏄涓涓鑷鐢辮蔣浠跺拰寮鏀炬簮浠ｇ爜欏圭洰銆傘
OpenStack鏄涓涓鏃ㄥ湪涓哄叕鍏卞強縐佹湁浜戠殑寤鴻句笌綆＄悊鎻愪緵杞浠剁殑寮婧愰」鐩銆傚畠鐨勭ぞ鍖烘嫢鏈夎秴榪130瀹朵紒涓氬強1350浣嶅紑鍙戣咃紝榪欎簺鏈烘瀯涓庝釜浜洪兘灝哋penStack浣滀負鍩虹璁炬柦鍗蟲湇鍔★紙綆縐癐aaS錛夎祫婧愮殑閫氱敤鍓嶇銆侽penStack欏圭洰鐨勯栬佷換鍔℃槸綆鍖栦簯鐨勯儴緗茶繃紼嬪苟涓哄叾甯︽潵鑹濂界殑鍙鎵╁睍鎬с傛湰鏂囧笇鏈涢氳繃鎻愪緵蹇呰佺殑鎸囧間俊鎮錛屽府鍔╁ぇ瀹跺埄鐢∣penStack鍓嶇鏉ヨ劇疆鍙婄＄悊鑷宸辯殑鍏鍏變簯鎴栫佹湁浜戙
openstack neutron涓瀹氫箟浜嗗洓縐嶇綉緇滄ā寮忥細
# tenant_network_type = local
# tenant_network_type = vlan
# Example: tenant_network_type = gre
# Example: tenant_network_type = vxlan
鏈鏂囦富瑕佷互vlan涓轟緥錛屽苟緇撳悎local鏉ヨ︾粏鐨勫垎鏋愪笅openstack鐨勭綉緇滄ā寮忋
1. local妯″紡
姝ゆā寮忎富瑕佺敤鏉ュ仛嫻嬭瘯錛屽彧鑳藉仛鍗曡妭鐐圭殑閮ㄧ講(all-in-one)錛岃繖鏄鍥犱負姝ょ綉緇滄ā寮忎笅嫻侀噺騫朵笉鑳介氳繃鐪熷疄鐨勭墿鐞嗙綉鍗℃祦鍑猴紝鍗硜eutron鐨剗ntegration bridge騫舵病鏈変笌鐪熷疄鐨勭墿鐞嗙綉鍗″仛mapping錛屽彧鑳戒繚璇佸悓涓涓繪満涓婄殑vm鏄榪為氱殑錛屽叿浣撳弬瑙丷DO鍜宯eutron鐨勯厤緗鏂囦歡銆
(1)RDO閰嶇疆鏂囦歡(answer.conf)
涓昏佺湅涓嬮潰綰㈣壊鐨勯厤緗欏癸紝榛樿や負絀恆
澶嶅埗浠ｇ爜
浠ｇ爜濡備笅:
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS
openswitch榛樿ょ殑緗戞ˉ鐨勬槧灝勫埌鍝錛屽嵆br-int鏄犲皠鍒板摢銆 姝ｅ紡鐢變簬br-int娌℃湁鏄犲皠鍒頒換浣昩ridge鎴杋nterface錛屾墍浠ュ彧鑳絙r-int涓婄殑鉶氭嫙鏈轟箣闂存槸榪為氱殑銆
澶嶅埗浠ｇ爜
浠ｇ爜濡備笅:
CONFIG_NEUTRON_OVS_BRIDGE_IFACES
嫻侀噺鏈鍚庝粠鍝鍧楃墿鐞嗙綉鍗℃祦鍑洪厤緗欏
澶嶅埗浠ｇ爜
浠ｇ爜濡備笅:
# Type of network to allocate for tenant networks (eg. vlan, local,
# gre)
CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=local
# A comma separated list of VLAN ranges for the Neutron openvswitch
# plugin (eg. physnet1:1:4094,physnet2,physnet3:3000:3999)
CONFIG_NEUTRON_OVS_VLAN_RANGES=
# A comma separated list of bridge mappings for the Neutron
# openvswitch plugin (eg. physnet1:br-eth1,physnet2:br-eth2,physnet3
# :br-eth3)
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=
# A comma separated list of colon-separated OVS bridge:interface
# pairs. The interface will be added to the associated bridge.
CONFIG_NEUTRON_OVS_BRIDGE_IFACES=
(2)neutron閰嶇疆鏂囦歡(/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini)
澶嶅埗浠ｇ爜
浠ｇ爜濡備笅:
[ovs]
# (StrOpt) Type of network to allocate for tenant networks. The
# default value 'local' is useful only for single-box testing and
# provides no connectivity between hosts. You MUST either change this
# to 'vlan' and configure network_vlan_ranges below or change this to
# 'gre' or 'vxlan' and configure tunnel_id_ranges below in order for
# tenant networks to provide connectivity between hosts. Set to 'none'
# to disable creation of tenant networks.
#
tenant_network_type = local
RDO浼氭牴鎹產nswer.conf涓璴ocal鐨勯厤緗灝唍eutron涓璷pen vswitch閰嶇疆鏂囦歡涓閰嶇疆涓簂ocal
2. vlan妯″紡
澶у跺箆lan鍙鑳芥瘮杈冪啛鎮夛紝灝變笉鍐嶈禈榪幫紝鐩存帴鐪婻DO鍜宯eutron鐨勯厤緗鏂囦歡銆
(1)RDO閰嶇疆鏂囦歡
澶嶅埗浠ｇ爜
浠ｇ爜濡備笅:
# Type of network to allocate for tenant networks (eg. vlan, local,
# gre)
CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=vlan //鎸囧畾緗戠粶妯″紡涓簐lan
# A comma separated list of VLAN ranges for the Neutron openvswitch
# plugin (eg. physnet1:1:4094,physnet2,physnet3:3000:3999)
CONFIG_NEUTRON_OVS_VLAN_RANGES=physnet1:100:200 //璁劇疆vlan ID value涓100~200
# A comma separated list of bridge mappings for the Neutron
# openvswitch plugin (eg. physnet1:br-eth1,physnet2:br-eth2,physnet3
# :br-eth3)
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=physnet1:br-eth1 //璁劇疆灝哹r-int鏄犲皠鍒版ˉbr-eth1(浼氳嚜鍔ㄥ壋寤簆hy-br-eth1鍜宨nt-br-eth1鏉ヨ繛鎺br-int鍜宐r-eth1)
# A comma separated list of colon-separated OVS bridge:interface
# pairs. The interface will be added to the associated bridge.
CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-eth1:eth1 //璁劇疆eth0妗ユ帴鍒癰r-eth1涓婏紝鍗蟲渶鍚庣殑緗戠粶嫻侀噺浠巈th1嫻佸嚭 (浼氳嚜鍔ㄦ墽琛宱vs-vsctl add br-eth1 eth1)
姝ら厤緗鎻忚堪鐨勭綉妗ヤ笌緗戞ˉ涔嬮棿錛岀綉妗ヤ笌緗戝崱涔嬮棿鐨勬槧灝勫拰榪炴帴鍏崇郴鍏蜂綋鍙緇撳悎 銆婂浘1 vlan妯″紡涓嬭＄畻鑺傜偣鐨勭綉緇滆懼囨嫇鎵戠粨鏋勫浘銆嬪拰 銆婂浘2 vlan妯″紡涓嬬綉緇滆妭鐐圭殑緗戠粶璁懼囨嫇鎵戠粨鏋勫浘 銆嬫潵鐞嗚В銆
鎬濊冿細寰堝氬悓瀛﹀彲鑳戒細紕板埌涓鍦烘櫙錛氱墿鐞嗘満鍙鏈変竴鍧楃綉鍗★紝鎴栨湁涓ゅ潡緗戝崱浣嗗彧鏈変竴鍧楃綉鍗¤繛鎺ユ湁緗戠嚎
姝ゆ椂錛屽彲浠ュ仛濡備笅閰嶇疆
(2)鍗曠綉鍗★細
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=physnet1:br-eth0 //璁劇疆灝哹r-int鏄犲皠鍒版ˉbr-eth10
澶嶅埗浠ｇ爜
浠ｇ爜濡備笅:
# A comma separated list of colon-separated OVS bridge:interface
# pairs. The interface will be added to the associated bridge
CONFIG_NEUTRON_OVS_BRIDGE_IFACES= //閰嶇疆涓虹┖
榪欎釜閰嶇疆鐨勫惈涔夋槸灝哹r-int鏄犲皠鍒癰r-eth0錛屼絾鏄痓r-eth0騫舵病鏈変笌鐪熸ｇ殑鐗╃悊緗戝崱緇戝畾錛岃繖灝遍渶瑕佷綘浜嬪厛鍦ㄦ墍鏈夌殑璁＄畻鑺傜偣(鎴栫綉緇滆妭鐐)涓婁簨鍏堝壋寤哄ソbr-eth0妗ワ紝騫跺皢eth0娣誨姞鍒癰r-eth0涓婏紝鐒跺悗鍦╞r-eth0涓婇厤緗濂絠p錛岄偅涔圧DO鍦ㄥ畨瑁呯殑鏃跺欙紝鍙瑕佸緩絝嬪ソbr-int涓巄r-eth0涔嬮棿鐨勮繛鎺ワ紝鏁翠釜緗戠粶灝遍氫簡銆
姝ゆ椂濡傛灉緗戠粶鑺傜偣涔熸槸鍗曠綉鍗＄殑璇濓紝鍙鑳藉氨涓嶈兘浣跨敤float ip鐨勫姛鑳戒簡銆
(3)鍙岀綉鍗★紝鍗曠綉綰
澶嶅埗浠ｇ爜
浠ｇ爜濡備笅:
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=physnet1:br-eth1 //璁劇疆灝哹r-int鏄犲皠鍒版ˉbr-eth1
/pp# A comma separated list of colon-separated OVS bridge:interface
/pp# pairs. The interface will be added to the associated bridge.
/ppCONFIG_NEUTRON_OVS_BRIDGE_IFACES=eth1 //閰嶇疆涓虹┖
榪樻槸榛樿ら兘閰嶇疆鍒癳th1涓婏紝鐒跺悗閫氳繃iptables灝唀th1鐨勬祦閲廸orward鍒癳th0(娌℃湁璇曢獙榪囷紝涓嶇『瀹氭槸鍚﹀彲琛)
3. vlan緗戠粶妯″紡璇﹁В
鍥1 vlan妯″紡涓嬭＄畻鑺傜偣鐨勭綉緇滆懼囨嫇鎵戠粨鏋勫浘
棣栧厛鏉ュ垎鏋愪笅vlan緗戠粶妯″紡涓嬶紝璁＄畻鑺傜偣涓婅櫄鎷熺綉緇滆懼囩殑鎷撴墤緇撴瀯銆
(1)qbrXXX 絳夎懼
鍓嶉潰宸茬粡璁茶繃錛屼富瑕佹槸鍥犱負涓嶈兘鍐峵ap璁懼噕net0涓婇厤緗畁etwork ACL rules鑰屽炲姞鐨
(2)qvbXXX/qvoXXX絳夎懼
榪欐槸涓瀵箆eth pair devices錛岀敤鏉ヨ繛鎺bridge device鍜宻witch錛屼粠鍚嶅瓧鐚滄祴涓嬶細q-quantum, v-veth, b-bridge, o-open vswitch(quantum騫翠唬鐨勯仐鐣)銆
(3) int-br-eth1鍜宲hy-br-eth1
榪欎篃鏄涓瀵箆eth pair devices錛岀敤鏉ヨ繛鎺br-int鍜宐r-eth1, 鍙﹀栵紝vlan ID鐨勮漿鍖栦篃鏄鍦ㄨ繖鎵ц岀殑錛屾瘮濡備粠int-br-eth1榪涙潵鐨刾ackets錛屽叾vlan id=101浼氳杞鍖栨垚1錛屽悓鐞嗭紝浠巔hy-br-eth1鍑哄幓鐨刾ackets錛屽叾vlan id浼氫粠1杞鍖栨垚101
(4)br-eth1鍜宔th1
packets瑕佹兂榪涘叆physical network鏈鍚庤繕寰楀埌鐪熸ｇ殑鐗╃悊緗戝崱eth1錛屾墍浠add eth1 to br-eth1涓婏紝鏁翠釜閾捐礬鎵嶅畬鍏ㄦ墦閫
鍥2 vlan妯″紡涓嬬綉緇滆妭鐐圭殑緗戠粶璁懼囨嫇鎵戠粨鏋勫浘
緗戠粶鑺傜偣涓庤＄畻鑺傜偣鐩告瘮錛屽氨鏄澶氫簡external network錛孡3 agent鍜宒hcp agent銆
(1)network namespace
姣忎釜L3 router瀵瑰簲涓涓猵rivate network錛屼絾鏄鎬庝箞淇濊瘉姣忎釜private鐨剗p address鍙浠overlapping鑰屽張涓嶇浉浜掑獎鍝嶅憿錛岃繖灝卞埄鐢ㄤ簡linux kernel鐨刵etwork namespace
(2)qr-YYY鍜宷g-VVV絳夎懼 (q-quantum, r-router, g-gateway)
qr-YYY鑾峰緱浜嗕竴涓猧nternal鐨剗p錛宷g-VVV鏄涓涓猠xternal鐨剗p錛岄氳繃iptables rules榪涜孨AT鏄犲皠銆
鎬濊冿細phy-br-ex鍜宨nt-br-ex鏄騫插暐鐨?
鍧氭寔"鎵鏈塸ackets蹇呴』緇忚繃鐗╃悊鐨勭嚎璺鎵嶈兘閫"鐨勬濇兂錛岃櫧鐒 qr-YYY鍜宷g-VVV涔嬮棿寤虹珛鐨凬AT鐨勬槧灝勶紝褰掓牴鍒板簳榪樺緱閫氳繃涓鏉＄墿鐞嗛摼璺錛岄偅涔坧hy-br-ex鍜宨nt-br-ex灝卞緩絝嬩簡榪欐潯鐗╃悊閾捐礬銆
㈢ ZYNQ+linux網口調試筆記（3）PL-ETH
在ZYNQ上使用gigE Vision協議的網路介面相機。
第一步：調通PS側網口GEM0（Xilinx BSP默認配好）。
第二步：調通PS側網口GEM1（見前一篇文檔：開發筆記(1)）。
第三步：調通PL側網口（本文闡述）。
第四步：在PL側網口上驗證Jumbo Frame特性，並在應用層適配gigE Vision協議。
根據《xapp1082》可知，PL側的PHY支持1000Base-X和SGMII兩種配置，這兩種配置對應兩種不同的PHY引腳介面（連接到MAC）。而我們的hdf文件使用的是1000Base-X的配置。
關於網口的Linux驅動，我們在官網找到一份資料： Xilinx Wiki - Zynq PL Ethernet 。資料很長，我們只看與我們相關的2.4.1 PL Ethernet BSP installation for 1000Base-X」這一章節就可以了。
首先導入FPGA設計同事提供的hdf文件：
在彈出的圖形界面里，進入Subsystem AUTO Hardware Settings——Ethernet Settings——Primary Ethernet，確認可以看到PL側網路設備axi_ethernet_0，說明hdf文件里已包含了必要的網口硬體信息：
上圖中被選中的網口將成為Linux上的設備eth0。這里我們默認選擇ps7_ethernet_0，即使用GEM0作為首選網口。
啟用Xilinx AXI Ethernet驅動
進入Device Drivers -- Network device support – 選中Xilinx AXI Ethernet（以及Xilinx Ethernet GEM，這是PS側網口的驅動）
進入Networking support – 選中 Random ethaddr if unset
進入Device Drivers -- Network device support -- PHY Device support and infrastructure – 啟用Drivers for xilinx PHYs
進入~~~~Device Drivers -- DMA Engine Support -– 禁用~~~~Xilinx AXI DMAS Engine~~~ （對應的配置項名為 ~~ CONFIG_XILINX_DMA ~~~）
注意： Xilinx Wiki里對設備樹節點的引用有誤（&axi_ethernet），導致編譯報錯，應改為&axi_ethernet_0。
註：PL-ETH驅動所在路徑：<project>/build/tmp/work-shared/plnx_arm/kernel-source/drivers/net/ethernet/xilinx/xilinx_axienet_main.c和xilinx_axienet_mdio.c。對應的內核配置項為CONFIG_NET_VENDOR_XILINX和CONFIG_XILINX_AXI_EMAC。
啟用ethtool和tcpmp（調試用，非必須）：
然後將生成的BOOT.BIN和image.ub拷貝到SD卡根目錄下，將SD卡插入板子上，上電運行。
上電後，使用ifconfig eth1查看網口信息，觀察MAC地址與設置的一致，且ifconfig eth1 192.168.1.11 up沒有報錯。
測試網路通路：ping PC是通的。說明網口工作正常。
Linux下eth1（即PL-ETH）的MAC地址有誤
問題描述：
開機列印：
注意：
MAC地址是錯的，驅動里解析出的是GEM0的MAC地址。
試驗發現，即使在system-user.dtsi里不寫local-mac-address，也照樣解析出的是GEM0的MAC。
而將system-user.dtsi里的local-mac-address改名為pl-mac-address，並將驅動里解析的字元串也對應更改為pl-mac-address，則可以正確解析出來：
Passing MAC address to kernel via Device Tree Blob and U-Boot：
http://zedboard.org/content/passing-mac-address-kernel-device-tree-blob
通過更改u-boot環境變數和設備樹，為每個板子設置一個獨特的MAC地址：
https://www.xilinx.com/support/answers/53476.html
U-Boot里的環境變數ethaddr會覆蓋掉設備樹里pl-eth的local-mac-addr欄位，從而影響Linux啟動後的網卡MAC地址；
但U-Boot里的環境變數ipaddr不會對Linux啟動後的配置產生任何影響。因為設備樹里根本就沒有關於IP地址的配置。
phy-mode怎麼會是sgmii？查了下官方的提供的BSP里，也是「sgmii」。說明這個沒問題。具體原因不清楚。
@TODO: 設備樹里的中斷號的順序如何影響功能？
為何讀出來的IRQ號不對呢？這是因為這里讀到的不是硬體的中斷號，而是經過系統映射之後的軟體IRQ number。兩者不具有線性關系。
關於中斷號的疑問：
Linux上的網口eth0、eth1的順序，似乎是按照phy地址從小到大來排布的。
Xilinx xapp1082-zynq-eth.pdf (v5.0) July 16, 2018
https://www.xilinx.com/support/documentation/application_notes/xapp1082-zynq-eth.pdf
Xilinx Wiki - Zynq PL Ethernet:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841633/Zynq+PL+Ethernet
Xilinx Wiki - Linux Drivers:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841873/Linux+Drivers
Xilinx Wiki - Linux Drivers - Macb Driver:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841740/Macb+Driver
Xilinx Wiki - Zynq Ethernet Performance:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841743/Zynq+Ethernet+Performance
查到關於Jumbo frame MTU的定義，當前值為9000，可否改大一些？
驅動源碼里關於jumbo frame的說明：
設置MTU為9000，發現ping包最大長度只能設為ping 192.168.1.10 -s 1472
https://lore.kernel.org/patchwork/patch/939535/
【完】