Got it, thanks David, so it is only one way to do it by ourselves :-), yes performance has to been hurt by consistent hashing, but I also found consistent hashing can't make sure the flows are always dispatched to the server which is handling them, it can just ensure most of cases are so. For our cases, consistent hashing is not enough.
-----邮件原件----- 发件人: David Ahern [mailto:dsah...@gmail.com] 发送时间: 2020年6月16日 6:43 收件人: Yi Yang (杨燚)-云服务集团 <yangy...@inspur.com>; netdev@vger.kernel.org 抄送: niko...@cumulusnetworks.com 主题: Re: 答复: [vger.kernel.org代发]Re: 答复: [PATCH] can current ECMP implementation support consistent hashing for next hop? On 6/15/20 12:56 AM, Yi Yang (杨燚)-云服务集团 wrote: > My next hops are final real servers but not load balancers, say we sets > maximum number of servers to 64, but next hop entry is added or removed > dynamically, we are unlikely to know them beforehand. I can't understand how > user space can attain consistent distribution without in-kernel consistent > hashing, can you show how ip route cmds can attain this? > I do not see how consistent hashing can be done in the kernel without affecting performance, and a second problem is having it do the right thing for all use cases. That said, feel free to try to implement it. > I find routing cache can help fix this issue, if a flow has been routed to a > real server, then its route has been cached, so packets in this flow should > hit routing cache by fib_lookup, so this can make sure it can be always > routed to right server, as far as the result is concerned, it is equivalent > to consistent hashing. > route cache is invalidated anytime there is a change to the FIB.
smime.p7s
Description: S/MIME cryptographic signature
