linux-kernel - Re: [PATCH] virtio_net: free transmit skbs in a timer

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: <48317FF7.1020707@qumranet.com>
Date:	Mon, 19 May 2008 16:26:15 +0300
From:	Avi Kivity <avi@...ranet.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
CC:	Mark McLoughlin <markmc@...hat.com>,
	Anthony Liguori <aliguori@...ibm.com>,
	linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH] virtio_net: free transmit skbs in a timer

Rusty Russell wrote:
>>>
>>> Well, we do have such a thing, in the ring suppression flags.
>>>       
>> Can you point me at this?
>>     
>
> Ah, sorry, I misunderstood.  No, we don't have a threshold like this, we
> have an all-or-nothing flag in each direction.
>
>   

Please point me anyway?

> We have the ability to add new fields to the rings.  I've put it on my
> TODO to benchmark what this does.  It may or may not help.  In this case,
> notification when there are no more packets in xmit ring would be
> sufficient.  We already kick the host when we fill a ring even if
> it says it doesn't need it, perhaps this would be symmetry.
>   

Notification on ring full is too late with smp.  You need to warn the 
other side in advance.

The reason I'm interested in adjustable thresholds is that you can then 
to tx mitigation without (usually) suffering the worst-case latency when 
you aren't streaming or streaming slower than what you tuned for.

>   
>>>   Note that DaveM
>>> is talking about moving network tx queue into the net drivers themselves,
>>> which will make them much more efficient (ie. drain entire queue before
>>> kick), which may again change the balance of what the Right Thing is.
>>>       
>> That depends on whether Linux knows whether more packets are coming.
>>     
>
> The current problem is that hard_start_xmit gets called with a packet, and 
> has no idea if there are more in the tx queue.  By having the driver control
> the queue, it can at least tell that.
>   

Yes, definitely an improvement, esp. for sendfile().

> The question remains whether this will be sufficient for tx mitigation.  A
> program may be about to write more to the socket, and we can't know that.
> But it can hardly hurt.
>
>   

Right.

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/