netdev - Re: [PATCH net-next v2 06/22] ovpn: introduce the ovpn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f9290545-c5c2-4b2f-967e-33025e5af809@openvpn.net>
Date: Fri, 8 Mar 2024 01:12:15 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
 Sergey Ryazanov <ryazanov.s.a@...il.com>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next v2 06/22] ovpn: introduce the ovpn_peer object

On 06/03/2024 20:23, Andrew Lunn wrote:
>> This is a very good point where I might require some input/feedback.
>> I have not ignored the problem, but I was hoping to solve it in a future
>> iteration. (all the better if we can get it out the way right now)
>>
>> The reason for having these rings is to pass packets between contexts.
>>
>> When packets are received from the network in softirq context, they are
>> queued in the rx_ring and later processed by a dedicated worker. The latter
>> also takes care of decryption, which may sleep.
>>
>> The same, but symmetric, process happens for packets sent by the user to the
>> device: queued in tx_ring and then encrypted by the dedicated worker.
>>
>> netif_rx_ring is just a queue for NAPI.
>>
>>
>> I can definitely have a look at BQL, but feel free to drop me any
>> pointer/keyword as to what I should look at.
> 
> Do you have any measurements about the average and maximum fill size
> of these queues? If you could make the rings smaller, the whole
> question of latency and bufferbloat disappears. NAPI tends to deal
> with up to 64 packets. So could you make these rings 128 in size?

I don't have actual numbers at hand.
Fill size depends on encryption/decryption speed vs network speed.

I can tell you that, while performing stress tests on AWS, we could get 
to the point where all rings are full and packets started being dropped.

However, this may be a ill-formed case, where network is much faster 
than the crypto part.

I will try to measure how many packets are kept in the queue under 
standard utilization. That should tell us if 128 is a decent size or not.

Thanks for the hint!

Regards,

> 
> 	Andrew

-- 
Antonio Quartulli
OpenVPN Inc.