On 2018/5/13 15:01, Leon Romanovsky wrote:
On Sun, May 13, 2018 at 02:42:49PM +0800, Yanjun Zhu wrote:
On 2018/5/13 14:36, Leon Romanovsky wrote:
On Sun, May 13, 2018 at 02:22:42PM +0800, Yanjun Zhu wrote:
On 2018/5/13 14:17, Leon Romanovsky wrote:
On Sun, May 13, 2018 at 09:05:45AM +0800, Yanjun Zhu wrote:
On 2018/5/12 22:55, Leon Romanovsky wrote:
On Sat, May 12, 2018 at 10:24:03AM -0400, Tom Talpey wrote:
On 5/12/2018 9:54 AM, Zhu Yanjun wrote:
When udp port 4791 is blocked, the udp port 4891 is used and vice versa.
Port 4891 is currently unassigned in the IANA registry. Do you intend
to request this? Strongly suggest that this not merge without such a
standard.
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
The whole idea looks to me like a hack, what will we do once the second
port blocked too? Will we introduce option to add more ports?
The second port is a backup. When the first port 4791 is blocked, the port
4891 will be used. At the same time,
some cleanup work will be done to make udp port 4791 work again. When 4891
is blocked, 4791 is used again.
It is like failover in bonding.:-)
Right, so why don't you use bonding for that?
Based on my test results, there is a performance loss with bonding compared
with this feature because
the packets will pass bonding driver before directly pass to the real
physical NIC driver.
I would like to see results, because RXE performance is far away from
the lane rate and it is hard to imagine that something can hurt it even
more.
Several weeks, I made tests to compare them. The performance loss is about
3%. If you need
the details, I am glad to make tests again.
IMHO, 3% loss s not worth all this fuss,
But if bonding is involved, the complexity of the whole system is
enhanced. To a production host,
it is not a good thing.
Zhu Yanjun
but let's wait to hear
feedback from other people.
Thanks
Zhu Yanjun
Thanks
So it is necessary to use this feature.
Zhu Yanjun
Thanks
Zhu Yanjun
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
