FPGA 内部有块SRAM，里面放配置信息
配置信息初始化的方式有3：
AS 主动模式: FPGA主动去读另外一块Flash，把Flash内数据放到自己的SRAM中
PS 被动模式: CPU把内存中的数据 通过数据线 发到FPGA的SRAM中
JTAG 在线模式: 外部计算机用仿真器通过JTAG接口 来 直接写 FPGA的 SRAM
--------------------------------------------------------------------------------------
ip neigh flush dev eth0 清空arp表
------------------------------------------------------------------------------------------
su 没有加“-”时，是非登录SHELL。不会改变当前工作目录，改变用户前的环境变量依然可用 。
而加上“-”就成了登录SHELL，你在改变前的用户里的环境变量就不可用了。
---------------------------------------------------------------------------------------------
判断CPU是32位还是64位：
grep flags /proc/cpuinfo
如果找到lm, 则说明你的CPU是64位的.
* Long Mode - 64位CPU
* Real Mode - 16位CPU
* Protected Mode - 32位CPU
判断OS是32为还是64位：
getconf LONG_BIT
如果是32，OS就是32位的
如果是64，OS就是64位的
getconf WORD_BIT
--------------------------------
HP机器在两个网卡上面配置同一网段的IP 192.168.1.2、192.168.1.3，eth0为192.168.1.2并且插了网线，eth1 没有插网线，此时2个IP都可以ping通。这个是怎么回事，大家能解释一下么？
另外默认路由走的是eth0，此时交换机上只能看到eth0的mac，哪位大侠能讲下这个原理到底是因为什么么？
和路由表的直通路由顺序有关
route -n 看一下你会发现其实该网段 eth0 是先走的，而因此 eth1 实际就不走了
言外之意，ping eth0 所在地址，数据包流经 eth0，而 ping eth1 所在地址，数据包先流经 eth0，后由内部转向 eth1
可以再做个试验，仍然只插一根网线，但插在 eth1 上，你会发现两个 IP 都不通了
在网络上，linux 与 windows 的实现不同，因此通常意义上不建议两个网卡相同网段
若一定要这样做，可以有 3 个解决办法
1、两个网卡做 bond（但我没这样做过）
2、两个网卡做 bridge，设置桥地址及桥地址的 alias（我通常这样解决）
3、设置策略路由（这个我到现在也还糊涂呢）
echo "210 local100" >> /etc/iproute2/rt_tables
echo "220 local200" >> /etc/iproute2/rt_tables
ip route add 192.168.1.0/24 dev eth0 src 192.168.1.1 table local100
ip route add 192.168.1.0/24 dev eth2 src 192.168.1.253 table local200
ip route add default dev eth0 table local100
ip route add default dev eth2 table local200
ip rule add from 192.168.1.1 table local100
ip rule add from 192.168.1.253 table local200
ip route flush cache
我的理解是： linux内核 在响应外部ARP请求的时候， 2块网卡 在同一个路由里面，因此 都有机会去响应arp请求
因此出现了 MAC地址错乱的情况
现在 的思路就是 把2块网卡 分到2个不同的路由表中， 这样就不出现 MAC地址冲突的事情了
如果非要在一个系统配置同一子网的两块网卡请在路由表中指定各自的网络。
什么为什么win就可以配置双网卡到一个子网都没有问题，这就是个蠢问题！！！
简单点说：win会自动给你的双网卡加跳点。你找个CCiE让他来评价评价win的网络设置吧！
我设置双IP是这么做的，没有那样的问题
[Copy to clipboard] [ - ]
CODE:
ifconfig eth0 IP1 netmask 255.255.255.0 up
ifconfig eth1 IP2 netmask 255.255.255.0 up
ip route add default via GATEWAY
ip route add default via GATEWAY dev eth0 src IP1 table 100
ip route add default via GATEWAY dev eth1 src IP2 table 200
ip rule add from IP1 table 100
ip rule add from IP2 table 200
http://blog.csdn.net/ling1874/archive/2010/01/04/5128269.aspx
-------------------------------------------------------------------------------------------
在网络设备里面区分不同的路径是一个很自然的选择，因为网络设备的首要任务是转发网络包，不同的网络包，在设备里面的处理路径不同。
fast path 就是那些可以依据已有状态转发的路径，在这些路径上，网关，二层地址等都已经准备好了，不需要缓存数据包，而是可以直接转发。
slow path 是那些需要额外信息的包，比如查找路由，解析MAC地址等。
first path 是设备收到流上第一个包所走过的路径，比如tcp里面的syn包，有些实现把三次握手都放到first path里面处理，
而有些只需处理syn包，其他包就进入fast path的处理路径。
在NP或者ASIC里面也需要区分slow path和fast path，
fast path上的包都放在SRAM里面，而slow path的包放在DRAM里面。
不过这也非绝对。决定处理路径的是对于速度的考虑。处理器的速度，内存的速度等。访问内存的速度由速度和带宽两个因素决定。
因此，把SRAM放到fast path上，也是很自然的选择。
系统的性能要从两方面考虑，硬件的设计和软件的设计，这两个方面的配合或者是分工，决定着系统的性能。
---------------------------------------------------------------------------------------------
if(data_was_unread != 0) {
/* Unread data was tossed, zap the connection. */
NET_INC_STATS_USER(TCPAbortOnClose);
tcp_set_state(sk, TCP_CLOSE);
....................................
Q:如果某个socket正处于联接的状态(ESTABLISHED),那么岂不是直接跳到了CLOSE状态吗?
可是应该进入 FIN_WAIT1 不是吗?
A: tcp_close()只在用户态调用了close()系统调用后才调用。
如果此时还有数据没有读取，则说明用户是要提前终止连接，
此时要向对方发RST，因为有对方发送的数据丢失了。
因此将连接直接跳到CLOSE状态，而不是正常的FIN_WAIT_1
Q:为什么在tcp_close()中只释放 receive_queue 而不处理write_queue , 如果write_queue不为空怎么办?
A:只清除receive queue是因为已经不可能读数据了，
而先前发送的数据可能还在write queue中等待发送。
这里的tcp_close()只是关闭了套接字层,tcp协议层仍然在运做。
注意点：
1、2MSL是基于IP报文的跳数，而不是时间；
2、当TCP处于2MSL状态，不可以创建同一连接；
--------------------------------------------------------------------------------------------
在A,B,C三类IP地址中,分别保留了一部分私有地址提供给企业内部使用
A：10.0.0.0 - 10.255.255.255
B：172.16.0.0 - 172.31.255.255
C：192.168.0.0 - 192.168.255.255
这些地址是不会被Internet分配的，它们在Internet上也不会被路由，
虽然它们不能直接和Internet网连接，但通过技术手段仍旧可以和 Internet通讯。
我们可以根据需要来选择适当的地址类，在内部局域网中将这些地址像公用IP地址一样地使用。
在Internet上，有些不需要与 Internet通讯的设备，
如打印机、可管理集线器等也可以使用这些地址，以节省IP地址资源。
组播地址是从224.0.0.0---239.255.255.255,
其中224.0.0.1用于永久组播组，指本地所有主机，包括网关
RFC2908: The Internet Multicast Address Allocation Architecture
RFC2365: Administratively Scoped IP Multicast
--------------------------------------------------------------------------------------------
#define min(x, y) (( \
const typeof(x) _x = (x); \
const typeof(y) _y = (y); \
(void) (&_x == &_y); \
_x < _y ? _x : _y; ))
(void) (&_x == &_y)
如果_x和_y的类型不一样，其指针类型也会不一样，会抛出一个编译警告。
举个例子：
char *p; int *q;
p==q; // 会在编译时产生一个警告
const typeof(x) _x = (x); \
const typeof(y) _y = (y); \
x,y 可能是表达式，所以又定义了两个变量 _x和_y
-----------------------------------------------------------------------------------------
fgets just only make '\n' as last character, can read "0 char"
strlen make "0 char" as end of string
fgets 0x01 0x00 '\n' -----> buf[]
strlen buf , result is 1 , acturally buf[] store three char
------------------------------------------------------------------------------------------
MAC地址分成三类，分别是广播地址、组播地址和单播地址。首先，FF：FF：FF：FF：FF：FF毫无疑问是广播地址。每个网卡出厂时被分配唯
一一个单播地址，头24位是设备制造厂商的编号，由IEEE(电气与电子工程师协会)分配，后24位是设备厂商为网卡制定的唯一编号。例如
08：00：20：0A：8C：6D是单播地址的例子，其中08：00：20是著名的CPU厂商AMD的编号。单播地址的特征是头8位的最低位为0，于是
单播地址共有47位的地址空间。
另一类地址就是组播地址。MAC组播地址的特征是头8位的最低位是1，于是MAC组播地址空间相当巨大——除去全1的47位地址空间。例如
01：80：C2：00：00：00是一个组播地址，表示802.1d网桥多播组。网桥就是使用这个地址，相互之间交换配置信息，运行分布式生成树算法，
消除网络拓扑结构中的环路。
IP层也有单播、组播和广播的概念。MAC组播地址中的01：00：5E：00：00：00到01：00：5E：7F：FF：FF共计23位对应于IP组
播地址。给定一个IP组播地址，将其低23位与01：00：5E：00：00：00的低位取“与”运算，即可的到一个
MAC组播地址。但IP组播地址有28位地址空间，对应的MAC组播地址却只有23位，这样每32个IP组播地址被映射到同一MAC地址上。
MAC组播地址空间远远大于IP组播地址空间。如果网络层仅有IP协议，那么完全能将IP组播地址一对一地映射到MAC组播地址！但MAC地址是一个数据链路层的概念，其上层的网络层远远不只有IP。
----------------------------------------------------------------------------------------
程序中若要使用 uint64_t 常量的话，要记得加后缀
ull，否则有告警
'warning: integer constant is too large for "long" type'
#include
const uint64_t val2 =0x0123456789ABCDEFull;
