All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: Nuutti Kotivuori <naked@iki.fi>, Young Koh <young.koh@gmail.com>
Subject: Re: [uml-devel] Re: tun/tap network throughput problem
Date: Thu, 10 Mar 2005 12:39:11 -0500	[thread overview]
Message-ID: <200503101239.11072.rob@landley.net> (raw)
In-Reply-To: <87u0nm2fow.fsf@aka.i.naked.iki.fi>

On Tuesday 08 March 2005 12:46 pm, Nuutti Kotivuori wrote:

> With UDP, the userland program has no way to throttle itself or know
> how fast the network can send UDP packets. In there, saying sendto for
> the UDP packets, might return ENOBUFS, but from the manpage of
> sendto():
>
>   ENOBUFS
>          The output queue for a network interface was full.  This  gener-
>          ally  indicates  that the interface has stopped sending, but may
>          be caused by transient congestion.   (Normally,  this  does  not
>          occur  in Linux. Packets are just silently dropped when a device
>          queue overflows.)
>
> So, UDP send performance measures with packet drop are not really
> meaningful, since it all depends on how much time the userland process
> gets time and if that is more than what the network device can dish out.
>
> -- Naked

The logical thing to return for a temporary nonblocking congestion condition 
is -EAGAIN to indicate the packet was dropped, but retransmitting it should 
work.  (Client programs are free to ignore this, and if broken clients didn't 
ignore it and it screwed up existing implementations, possibly an extra open 
flag would be necessary to trigger it.)  Putting this in UML itself wouldn't 
help, but if the host kernel did this UML (and TCP in general) could throttle 
more sanely.

However, nobody's ever bothered to fix this because UDP is not a guaranteed 
protocol over the internet or hub-based ethernet.  Now that we've got 
switched ethernet (synchronous in the case of gigabit), packets are virtually 
never dropped over a LAN and it's possible that some infrastructure to not 
drop packets without remarking on it in the kernel's own packet handling 
layers is now worth the bother...

But I'm unlikely to personally code it up any time soon. :)

Rob


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  parent reply	other threads:[~2005-03-11  3:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-07 20:56 [uml-devel] tun/tap network throughput problem Young Koh
2005-03-08 11:27 ` [uml-devel] " Nuutti Kotivuori
2005-03-08 16:42   ` Young Koh
2005-03-08 17:46     ` Nuutti Kotivuori
2005-03-08 18:51       ` Young Koh
2005-03-09  9:25         ` Nuutti Kotivuori
2005-03-09 11:48           ` Nuutti Kotivuori
2005-03-10 17:39       ` Rob Landley [this message]
2005-03-09 19:29 ` [uml-devel] " Blaisorblade
2005-03-09 21:46   ` Young Koh

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=200503101239.11072.rob@landley.net \
    --to=rob@landley.net \
    --cc=naked@iki.fi \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --cc=young.koh@gmail.com \
    /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.