On 04/19/2018 12:40 AM, Paolo Abeni wrote: > Hi, > > On Wed, 2018-04-18 at 12:21 -0700, Eric Dumazet wrote: >> >> On 04/18/2018 10:15 AM, Paolo Abeni wrote: >> is not appealing to me :/ >>> >>> Thank you for the feedback. >>> Sorry for not being clear about it, but knotd is using SO_REUSEPORT and >>> the above tests are leveraging it. >>> >>> That 5% is on top of that 300%. >> >> Then there is something wrong. >> >> Adding copies should not increase performance. > > The skb and data are copied into the UDP skb cache only if the socket > is under memory pressure, and that happens if and only if the receiver > is slower than the BH/IP receive path.
Which is going to happen under attack. Bimodal behavior is dangerous for system stability.. > > The copy slows down the RX path - which was dropping packets - and > makes the udp_recvmsg() considerably faster, as consuming skb becomes > almost a no-op. > > AFAICS, this is similar to the strategy you used in: > > ommit c8c8b127091b758f5768f906bcdeeb88bc9951ca > Author: Eric Dumazet <eduma...@google.com> > Date: Wed Dec 7 09:19:33 2016 -0800 > > udp: under rx pressure, try to condense skbs > > with the difference that with the UDP skb cache there is an hard limit > to the amount of memory the BH is allowed to copy. > Very different strategy really. We do not copy 500 bytes per skb :/ and the total amount of memory is tunable (socket rcvbuf) instead of hard coded in the kernel :/ >> If it does, there is certainly another way, reaching 10% instead of 5% > > I benchmarked vs a DNS server to test and verify that we get measurable > benefits in real life scenario. The measured performance gain for the > RX path with reasonable configurations is ~20%. Then we probably can make +40% without copies. > > Any suggestions for better results are more than welcome! Yes, remote skb freeing. I mentioned this idea to Jesper and Tariq in Seoul (netdev conference) Not tied to UDP, but a generic solution. You are adding more and more code only that only helps in some benchmarks really. UDP stack is becoming a very complex beast, while heavy duty UDP servers have alternatives, and can not cope with arbitrary flood anyway.
