邻居子系统的一些个人总结neighboursubsystem.doc

邻居子系统的一些个人总结neighbour subsystem作为多个网络的转发器（网关设备），该网关设备可能是成千上万台主机的网关，这样就需要一个好的ARP管理机制。一个好的ARP缓存体现在1、查找速度 2、计时机制 3、缓存空间的管理（例如当缓存空间不够时，又是如何处理）linux在neighbour management对于上述的几方面的处理方式：1、查找速度采用哈希表，来加快查找。2、计时机制计时机制比较复杂，里面涉及很多的计时器。采用IPV6的state transition 机制，IPv6 defines an NUD mechanism that can help determine quickly whether the neighbour is disconnected or gone down.linux内核就是以这种nud state transition scheme为基础来设计neighbour infrastructure。现在就讨论一下这个NUD机制为什么如此设计？（可参见figure 26-13）哪些状态NUD_NONE、NUD_INCOMPLETE、NUD_REACHABLE、NUD_STALE、NUD_DELAY、NUD_PROBE、NUD_PERMANENT、NUD_NOARP。NUD scheme多了一个reachable detection scheme，这主要是借鉴了IPV6 NUD scheme的精髓。一般的ARP处理方式是时间超时，NUD_REACHABLE状态马上进入FAILED。而这里多了个可达性的检测。因为造成arp entry很长没有被使用的原因有（1）本身就没有主机要引用到它，也就是说主机没有发送相关的数据报。（2）主机想发送相关的数据包，但是由于接收方或网络传输路径中间的网络设备出现故障而不能传送成功，遇到这种情况高层协议像TCP需要重传，而中间就有一段延迟，这段延迟时间会使得相关的arp entry没有被引用。reachable detection引入到三个state:NUD_DELAY、NUD_PROBE、NUD_STALE。处于NUD_STALE状态的entry一旦被引用时，就进入NUD_DELAY,说明第（1）种情况排除，可能是目的主机的问题。同时start the reachable verification。进入NUD_DELAY状态，这个状态是一个优化，在该状态下并没有启动ARP请求，而是进一步等待反方向的确认数据报。本来可以马上进NUD_PROBE，但是并没有马上进入而是先进入NUD_DELAY，这样做是有原因的，如果在大的网络中，arp entry很多，而每个arp entry都启动一个arp请求，这样开销太大了，所以引入了这样一个过渡状态。进入NUD_PROBE就启动arp请求进程，发送arp请求。在NUD_INCOMPLETE、NUD_DELAY、NUD_PROBE这三个state都设置了计时器，其计时器的处理方式都为neigh_timer_handler。在neighbour中设置了confirmed，这是可达性检验时高层协议用来更新neighbour的最新确认信息，例如TCP协议每收到反方向发过来的确认数据包，就会调用dst-confirm(dst-confirm又会再调用neigh_confirm)来更新confirm。这样计时器超时之后就可以利用confirmed来进行比较从而确认是否超时，例如当nowkmem_cachep中获得的，这同skbuff的分配方式有点相同。每当释放neighbour空间时也是把它放到neightable-kmem_cachep中去，这样加速了对neighbour空间的获得。还有垃圾回收机制，因为state一进入NUD_FAILED，并不能马上对其空间进行回收，可能还有别的用户在使用它，所以每当state进入NUD_FAILED就通过error_report通告其它subsystem(such as route subsystem)其neighbour发生错误。让回收工作交给一个定时器来进行。如果每次回收都要扫描整个hash table必然要耗费很多的时间，所以每次只扫描一个bucket。neigh_table中设置了gc_thresh2、gc_thresh3，可以参看neigh_forced_gc。gc_thresh2相当于一个警报器。/*this is synchronus garbage collection.When there is no enough memory pool (neigh_table-entries=gc_thresh3) or the memory used has arrive at the alert line(neigh_table-entries=gc_thresh2),then the neighbour subsystem will activate the synchronus garbage collection. the neigh_forced_gc will clear the neighbour whose refcnt is 1(there is no one referring to it) include all the states except NUD_PERMANENT. The cleaned neighbour objects is different with the asynchronus function neigh_periodic_timer who only clear the state of NUD_FAILED.Why? Because the synchronus function neigh_forced_gc is called when there is no enough memory pool. Its destination is to get memory pool. But the asynchronus function neigh_perioridic_timer is callled by the timer.Maybe the memory pool is enough when the timer is running.So neigh_perioridic_timer only clean the state of NUD_FAILED neighbour.*/static int neigh_forced_gc(struct neigh_table *tbl)int shrunk = 0;/*shrunk用于该函数的返回值,shrunk=1代表至少有 一个neighbour被移除,shrunk=0代表没有neighbour被移除*/int i;NEIGH_CACHE_STAT_INC(tbl, forced_gc_runs);write_lock_bh(&tbl-lock);for (i = 0; i hash_mask; i+) struct neighbour *n, *np; np = &tbl-hash_bucketsi; while (n = *np) != NULL) /* Neighbour record may be discarded if: * - nobody refers to it. * - it is not permanent */ write_lock(&n-lock); if (atomic_read(&n-refcnt) = 1 & !(n-nud_state & NUD_PERMANENT) *np = n-next; n-dead = 1; shrunk = 1; write_unlock(&n-lock); neigh_release(n); continue; write_unlo