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/
【完】