On 2018/5/13 15:09, Yanjun Zhu wrote:
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.
And with bonding, more NIC devices are needed when soft roce is used in
the physical host. But with this feature,
less NIC devices are needed.:-P
Zhu Yanjun
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
--
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
