From: Rusty Russell <rusty@rustcorp.com.au>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [RFC] virtio: orphan skbs if we're relying on timer to free them
Date: Thu, 21 May 2009 16:27:05 +0930 [thread overview]
Message-ID: <200905211627.05814.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20090518.194013.109631461.davem@davemloft.net>
On Tue, 19 May 2009 12:10:13 pm David Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Mon, 18 May 2009 22:18:47 +0930
> > We check for finished xmit skbs on every xmit, or on a timer (unless
> > the host promises to force an interrupt when the xmit ring is empty).
> > This can penalize userspace tasks which fill their sockbuf. Not much
> > difference with TSO, but measurable with large numbers of packets.
> >
> > There are a finite number of packets which can be in the transmission
> > queue. We could fire the timer more than every 100ms, but that would
> > just hurt performance for a corner case. This seems neatest.
...
> > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>
> If this is so great for virtio it would also be a great idea
> universally, but we don't do it.
>
> What you're doing by orphan'ing is creating a situation where a single
> UDP socket can loop doing sends and monopolize the TX queue of a
> device. The only control we have over a sender for fairness in
> datagram protocols is that send buffer allocation.
Urgh, that hadn't even occurred to me. Good point.
> I'm guilty of doing this too in the NIU driver, also because there I
> lack a "TX queue empty" interrupt and this can keep TCP sockets from
> getting stuck.
>
> I think we need a generic solution to this issue because it is getting
> quite common to see cases where the packets in the TX queue of a
> device can sit there indefinitely.
I haven't thought this through properly, but how about a hack where we don't
orphan packets if the ring is over half full?
Then I guess we could overload the watchdog as a more general timer-after-no-
xmit?
Rusty.
next prev parent reply other threads:[~2009-05-21 6:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-18 12:48 [RFC] virtio: orphan skbs if we're relying on timer to free them Rusty Russell
2009-05-19 2:40 ` David Miller
2009-05-21 6:57 ` Rusty Russell
2009-05-21 6:57 ` Rusty Russell [this message]
2009-05-21 7:15 ` David Miller
2009-05-21 17:24 ` Dimitris Michailidis
2009-05-21 17:24 ` Dimitris Michailidis
2009-05-25 11:01 ` Rusty Russell
2009-05-25 11:01 ` Rusty Russell
2009-05-21 7:15 ` David Miller
2009-05-19 2:40 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2009-05-18 12:48 Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200905211627.05814.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.