All,
i have been playing around with SCTP as transport for knet for a while now, as a possibility to pipe DLM traffic via knet.
The PoC patch is working fine, but the performances vs UDP are rather discouraging (at least using CPG bench), with SCTP being able to handle just a bit more than 50% of UDP performances.
Before I invest too much time into it, the question become: do we really care for a potential knet 1.0?
My take here is to either postpone or drop SCTP for now and re-evaluate for 2.0. Idea here is being also able to make it easier to plugin different network protocols. Right now the code is very much designed around one single network protocol and the patch is very invasive in some areas with little flexibility (meaning having to break API/ABI every time we add a new protocol).
My suggestion would be to refactor the network code to be more modular and after we have a more dynamic/better designed API/ABI, we can add N protocols without suffering too much.
agree? disagree?
Fabio
Heya Fabio,
On Fri, Jun 03, 2016 at 08:53:23AM +0200, Fabio M. Di Nitto wrote:
i have been playing around with SCTP as transport for knet for a while now, as a possibility to pipe DLM traffic via knet.
The PoC patch is working fine, but the performances vs UDP are rather discouraging (at least using CPG bench), with SCTP being able to handle just a bit more than 50% of UDP performances.
Before I invest too much time into it, the question become: do we really care for a potential knet 1.0?
My take here is to either postpone or drop SCTP for now and re-evaluate for 2.0. Idea here is being also able to make it easier to plugin different network protocols. Right now the code is very much designed around one single network protocol and the patch is very invasive in some areas with little flexibility (meaning having to break API/ABI every time we add a new protocol).
My suggestion would be to refactor the network code to be more modular and after we have a more dynamic/better designed API/ABI, we can add N protocols without suffering too much.
agree? disagree?
having been tangentially involved in a few patches here and there with SCTP in Linux, I fully agree with postponing it for 2.0. It is not only that it gets a lot less love in terms of maintenance, but it is also due to the fact that there is pretty much no acceleration in today's NICs for SCTP (except for some Intel NICs which have checksums in HW, there is no GSO/GRO/etc.). So I think your plan makes a lot of sense.
cheers, Michele
-
Fabio M. Di Nitto -
Michele Baldessari