netdev - Re: [kvm-devel] [virtio-net][PATCH] Don't arm tx hrtimer with a constant 500us each transmit

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: <47675AE0.8050808@qumranet.com>
Date:	Tue, 18 Dec 2007 07:30:08 +0200
From:	Avi Kivity <avi@...ranet.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
CC:	dor.laor@...ranet.com, kvm-devel <kvm-devel@...ts.sourceforge.net>,
	netdev@...r.kernel.org,
	virtualization <virtualization@...ts.linux-foundation.org>
Subject: Re: [kvm-devel] [virtio-net][PATCH] Don't arm tx hrtimer with a	constant
 500us each transmit

Rusty Russell wrote:
> On Wednesday 12 December 2007 23:54:00 Dor Laor wrote:
>   
>> commit 763769621d271d92204ed27552d75448587c1ac0
>> Author: Dor Laor <dor.laor@...ranet.com>
>> Date:   Wed Dec 12 14:52:00 2007 +0200
>>
>>     [virtio-net][PATCH] Don't arm tx hrtimer with a constant 50us each
>> transmit
>>
>>     The current start_xmit sets 500us hrtimer to kick the host.
>>     The problem is that if another xmit happens before the timer was
>> fired then
>>     the first xmit will have to wait additional 500us.
>>     This patch does not re-arm the timer if there is existing one.
>>     This will shorten the latency for tx.
>>     
>
> Hi Dor!
>
>     Yes, I pondered this when I wrote the code.  On the one hand, it's a 
> low-probability pathological corner case, on the other, your patch reduces 
> the number of timer reprograms in the normal case.
>   

One thing that came up in our discussions is to let the host do the 
timer processing instead of the guest.  When tx exit mitigation is 
enabled, the guest bumps the queue pointer, but carefully refrains from 
kicking the host.  The host polls the tx pointer using a timer, kicking 
itself periodically; if polling yields no packets it disables tx exit 
mitigation.  This saves the guest the bother of programming the timer, 
which presumably requires an exit if the timer is the closest one to 
expiration.

[btw, this can be implemented in virtqueue rather than virtio-net, no?]

-- 
Any sufficiently difficult bug is indistinguishable from a feature.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html