linux路由表拷贝问题

qtdszws

coreA路由的配置信息不能在coreB上重新配置吗? 我想这样更合理更科学.

雨丝风片

我前面说过，路由表不是数组，是用指针串起来的一堆struct，就算可以利用其内存管理方面的特性将整个表拷贝到它处，你也不能改变其中的指针值，就好像你把一个网页保存到本地，网页中的链接还是指向internet的。所以，对整表memcpy是没有意义的。

对于你的系统，我觉得可选的方案有：
1、对等方案。不管是静态路由也好，动态路由也好，均在添加路由的时候完成路由配置数据的同步，使coreA和coreB动态维护相同的路由表。

2、主从方案。废弃coreB协议栈中的路由功能，coreB上的所有路由添加、删除、查询的请求均通过进程间通信的方式转发给coreA。实际上，系统中只有coreA的一张路由表，coreB在路由上仅相当于一个“接口模块”。这种方案还可继续优化，即在coreB上维护一个路由缓存，以提高近期常用路由的查找速度。

如果对coreB的路由查找效率要求较高的话，还是第一种方案比较合适。

Goodfriend

原帖由 雨丝风片 于 2007-4-14 09:48 发表于 12楼  
我前面说过，路由表不是数组，是用指针串起来的一堆struct，就算可以利用其内存管理方面的特性将整个表拷贝到它处，你也不能改变其中的指针值，就好像你把一个网页保存到本地，网页中的链接还是指向internet的。 ...

是的，memcpy是不行的。如果要拷贝的话，我想只有按照结构来拷贝。不过，对于路由表比较复杂的结构来说，拷贝的方式确实不是一个比较好的方法。效率也是一个问题。

雨丝风片兄提出的两个方案，我也曾考虑过，其中的主从方案，我的想法是在CoreA linux kernel上维护一张路由表，CoreB使用CoreA linux kernel中的路由表。不过，这样一来就必须用到锁，可是我老大不太喜欢用锁呀。呵呵。只有再沟通了。

谢谢雨丝风片兄!

jobman

最大的问题是?你如何保证路由信息的同步?如果要保持同步,就必须用锁,那你这样做的意义何在?

Goodfriend

原帖由 jobman 于 2007-4-16 12:50 发表于 14楼  
最大的问题是?你如何保证路由信息的同步?如果要保持同步,就必须用锁,那你这样做的意义何在?

保持同步的想法是这样，将kernel中的routing table拷贝到share memory中，CoreB的程序使用share memory
中的路由表。因为share memory中的routing table只有CoreB的程序使用，并且CoreB只对routing table做search
的操作，所以不需要用锁同步。

对路由表的配置，全部再CoreA上做，CoreA上的路由表是有锁，进行同步的。

设想是希望CoreB的程序去独享一张路由表，并且由于只对表做search的操作，这样CoreB的程序的效率要高的多。

albcamus

你想在每个cpu上运行一个kernel? 目前的linux支持吗?

雨丝风片

原帖由 Goodfriend 于 2007-4-16 13:16 发表于 15楼  


保持同步的想法是这样，将kernel中的routing table拷贝到share memory中，CoreB的程序使用share memory
中的路由表。因为share memory中的routing table只有CoreB的程序使用，并且CoreB只对routing table做 ...

我觉得这个方案不可取。比如，何时拷贝？如何拷贝？

1、应该是只要有变化就“拷贝”吧，显然，表中的链接信息拷也无用，需要拷贝是就是路由配置数据而已。share memory中的路由表显然需要“重建”，那么，用什么算法重建？采用哪种路由查找算法？这是一个问题。

2、应该只有coreA来完成这个“拷贝”吧，也就是说，这个表由coreA来维护，由coreB来访问，那么至少对这个表来说，coreA和coreB必须用同一套路由管理代码才行。而且，coreB对表的访问必须要同步，因为coreA随时会去修改这个表。

从上述两点来看，你所设想的方案最大的特点就是coreB所用的路由表只能是一个根据路由配置数据“重建”的路由表，这里面没有任何实际的“拷贝”的概念。

因此，与其coreA和coreB必须使用同一套路由管理代码，与其coreA和coreB对表的访问需要同步，不如根本就不考虑share memory的方案，在coreA和coreB之间同步的只是数据，实际的路由配置数据。在coreA和coreB之间建立一个数据同步通道，在coreA收到用户的路由配置数据之后，除了添加自己的路由表之外，还需以coreB理解的格式将数据转发给coreB，由coreB自行维护自己的路由表。

具体采用什么方案还要取决于你的系统中的路由总量和变化情况，如果需要查询的目的地较为稳定的话，我觉得采用主从方案比较合适，即coreB上只维护少量路由缓存，而不是完整的路由表。除开最初的几次路由查询需要发给coreA处理之外，之后的路由查询操作基本可由coreB本地的路由缓存满足。

最后还有一点，也取决于你的系统的设计方式：你设计的share memroy中的路由表能不能让coreA来维护？查路由最终查的是什么？无非就是下一跳和出接口，这些都是在路由配置的时候就要指定的信息。因此，要达到你的目的，这些信息必须在你的系统中共享。即不管采用哪种模式，你的coreA都将是你的系统中的一个协议栈总控单元，否则，关于路由表分布方式的讨论也是没有任何意义的。

Goodfriend

我用的是cavium公司的主板和网络加速芯片，支持同时在不同处理器上单独运行不同的kernel/process，而互不干扰。

Goodfriend

原帖由 雨丝风片 于 2007-4-16 14:44 发表于 17楼  



我觉得这个方案不可取。比如，何时拷贝？如何拷贝？

1、应该是只要有变化就“拷贝”吧，显然，表中的链接信息拷也无用，需要拷贝是就是路由配置数据而已。share memory中的路由表显然需要“重建”，那 ...

雨丝风片兄分析的很到位！“拷贝”的方式确实有很多问题，现在这种方式我已经不予考虑了。

我现在的想法是：CoreA上维护一个Routing table，CoreB上维护一个Routing table的cache。
当CoreB无法在cache中命中，就去查CoreA的Routing table。路由的配置在CoreA上做。相当于
雨丝风片兄所提的“主从方案”。

再次感谢雨丝风片兄！

雨丝风片

原帖由 Goodfriend 于 2007-4-16 14:58 发表于 19楼  


雨丝风片兄分析的很到位！“拷贝”的方式确实有很多问题，现在这种方式我已经不予考虑了。

我现在的想法是：CoreA上维护一个Routing table，CoreB上维护一个Routing table的cache。
当CoreB无法在cache ...

使用这种方案需要注意的是：
coreB上的cache由coreB来“加”，但别忘了让coreA来“删”，即当coreA知道某条路由已经无效的时候，需要确保该条路由在coreB的cache中（如果在里面的话）也失效。否则路由查询结果就可能是错误的，具体怎么实现就是细节问题了。