From: David Ahern <dsahern@gmail.com>
To: "Yi Yang (杨燚)-云服务集团" <yangyi01@inspur.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "nikolay@cumulusnetworks.com" <nikolay@cumulusnetworks.com>
Subject: Re: 答复: [vger.kernel.org代发]Re: 答复: [PATCH] can current ECMP implementation support consistent hashing for next hop?
Date: Mon, 15 Jun 2020 16:42:52 -0600 [thread overview]
Message-ID: <cdbeca15-da70-119b-9f0c-04813cb82766@gmail.com> (raw)
In-Reply-To: <b9e0245f58ca44ed80b07a58cd0399be@inspur.com>
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.
next prev parent reply other threads:[~2020-06-15 22:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 14:56 [PATCH] can current ECMP implementation support consistent hashing for next hop? Yi Yang (杨燚)-云服务集团
2020-06-11 18:27 ` David Ahern
2020-06-12 0:32 ` 答复: " Yi Yang (杨燚)-云服务集团
2020-06-12 4:36 ` David Ahern
2020-06-15 6:56 ` 答复: [vger.kernel.org代发]Re: " Yi Yang (杨燚)-云服务集团
2020-06-15 22:42 ` David Ahern [this message]
2020-06-16 0:29 ` 答复: " Yi Yang (杨燚)-云服务集团
2020-08-02 14:49 ` Ido Schimmel
2020-08-06 16:45 ` David Ahern
2020-08-08 18:40 ` Ido Schimmel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cdbeca15-da70-119b-9f0c-04813cb82766@gmail.com \
--to=dsahern@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=yangyi01@inspur.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).