I'm not sure if the following processing power is actually required to reproduce the problem, but this is my setup: - 2 single-board computers (SBCs), each a Xeon C5528 @ 2.13GHz (4-core with HT = 8 cores each) - 10Gb Intel 82599EB NICs (IXGBE); each SBC has 2 of these but only 1 was used for this SCTP testing (i.e. NOT multi-homed) - 10Gb backplane, approx. 0.2 ms RTT (however I also tested this with RTT = 10 ms, 20 ms, 50 ms and it is reproducible in all scenarios) - send buffer size = 1200000, receive buffer size = 3000000 -----Original Message----- From: linux-sctp-owner@xxxxxxxxxxxxxxx [mailto:linux-sctp-owner@xxxxxxxxxxxxxxx] On Behalf Of Alexander Sverdlin Sent: April-15-14 2:44 AM To: ext Daniel Borkmann; davem@xxxxxxxxxxxxx Cc: netdev@xxxxxxxxxxxxxxx; linux-sctp@xxxxxxxxxxxxxxx; Matija Glavinic Pecotic; Vlad Yasevich Subject: Re: [PATCH net] Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer" Hello Daniel, On 14/04/14 21:45, ext Daniel Borkmann wrote: > This reverts commit ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd > management to reflect real state of the receiver's buffer") as it > introduced a serious performance regression on SCTP over IPv4 and > IPv6, though a not as dramatic on the latter. Measurements are on 10Gbit/s with ixgbe NICs. Could you please share other HW details? I wonder how much CPU power one needs for such a throughput? -- Best regards, Alexander Sverdlin. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n�����{������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
