netdev - Re: [PATCH v3 3/5] vhost_net: remove virtio_net_hdr validation, let tun/tap do it themselves

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: <CCEDFBF6-0E63-40BA-8F29-55222113BA45@infradead.org>
Date:   Tue, 29 Jun 2021 07:59:13 +0100
From:   David Woodhouse <dwmw2@...radead.org>
To:     Jason Wang <jasowang@...hat.com>, netdev@...r.kernel.org
CC:     Eugenio Pérez <eperezma@...hat.com>,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH v3 3/5] vhost_net: remove virtio_net_hdr validation, let tun/tap do it themselves



On 29 June 2021 04:43:15 BST, Jason Wang <jasowang@...hat.com> wrote:
>
>在 2021/6/29 上午7:29, David Woodhouse 写道:
>> On Mon, 2021-06-28 at 12:23 +0100, David Woodhouse wrote:
>>> To be clear: from the point of view of my *application* I don't care
>>> about any of this; my only motivation here is to clean up the kernel
>>> behaviour and make life easier for potential future users. I have
>found
>>> a setup that works in today's kernels (even though I have to disable
>>> XDP, and have to use a virtio header that I don't want), and will
>stick
>>> with that for now, if I actually commit it to my master branch at
>all:
>>>
>https://gitlab.com/openconnect/openconnect/-/commit/0da4fe43b886403e6
>>>
>>> I might yet abandon it because I haven't *yet* seen it go any faster
>>> than the code which just does read()/write() on the tun device from
>>> userspace. And without XDP or zerocopy it's not clear that it could
>>> ever give me any benefit that I couldn't achieve purely in userspace
>by
>>> having a separate thread to do tun device I/O. But we'll see...
>> I managed to do some proper testing, between EC2 c5 (Skylake) virtual
>> instances.
>>
>> The kernel on a c5.metal can transmit (AES128-SHA1) ESP at about
>> 1.2Gb/s from iperf, as it seems to be doing it all from the iperf
>> thread.
>>
>> Before I started messing with OpenConnect, it could transmit 1.6Gb/s.
>>
>> When I pull in the 'stitched' AES+SHA code from OpenSSL instead of
>> doing the encryption and the HMAC in separate passes, I get to
>2.1Gb/s.
>>
>> Adding vhost support on top of that takes me to 2.46Gb/s, which is a
>> decent enough win.
>
>
>Interesting, I think the latency should be improved as well in this
>case.

I don't know about that. I figured it would be worse in the packet by packet case (especially VoIP traffic) since instead of just *writing* a packet to the tun device, we stick it in the ring and then make the same write() syscall on an eventfd to wake up the vhost thread which then has to do the *same* copy_from_user() that could have happened directly in our own process.

Maybe if I have a batch of only 1 or 2 packets I should just write it directly. I still could :)

>> That's with OpenConnect taking 100% CPU, iperf3
>> taking 50% of another one, and the vhost kernel thread taking ~20%.
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.