From: michi1@michaelblizek.twilightparadox.com (michi1 at michaelblizek.twilightparadox.com)
To: kernelnewbies@lists.kernelnewbies.org
Subject: net_device: limit rate ot tx packets
Date: Sun, 14 Apr 2013 08:15:21 +0200 [thread overview]
Message-ID: <20130414061520.GA2288@grml> (raw)
In-Reply-To: <20130413141121.1aedb750@anton.lan>
Hi!
On 14:11 Sat 13 Apr , christian+kn at wwad.de wrote:
> Hi All,
>
> can someone please explain me, how the kernel handles different
> transfer rates of different net_devices? Or in other words: How does
> the systemcall send() know, when to block?
>
> An example:
> cat /dev/zero | pv | nc -u <someip>
> will show different throughput speeds depending on the network device,
> the packets are sent over (wlan0 will be slower than eth0).
>
> - Can someone point out the location in the linux kernel source, where
> this is handled?
>
> - If I register a net_device. How do I signal to the upper
> network layers that my driver can only accept packets at a
> certain rate? I tried stopping the egress queue by calling
> netif_stop_queue(), but this only has the effect that the queue
> overruns.
>
>
> I have the feeling that I'm missing out a very vital point on how the
> kernel's networking subsystem works. Unfortunately, Understanding Linux
> Network Internals couldn't help me out here.
I think this is what causes the behaviour:
1) If the network device is congested, packets will queue up in the qdisc
2) Socket memory gets used up, semdmsg will probably sleep here:
udp_sendmsg
ip_make_skb
__ip_append_data
sock_alloc_send_skb
sock_alloc_send_pskb
sock_wait_for_wmem
3) When packets are sent, the socket destructor will be called and wake up
the sender:
sock_wfree()
sk->sk_write_space(sk); (which is sock_def_write_space)
It would be interesting to see what will happen if the qdisc is smaller than
the socket memory...
-Michi
--
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com
next prev parent reply other threads:[~2013-04-14 6:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-13 12:11 net_device: limit rate ot tx packets christian+kn at wwad.de
2013-04-14 6:15 ` michi1 at michaelblizek.twilightparadox.com [this message]
2013-04-14 7:45 ` Valdis.Kletnieks at vt.edu
2013-04-14 8:09 ` michi1 at michaelblizek.twilightparadox.com
2013-04-14 14:35 ` Valdis.Kletnieks at vt.edu
2013-04-17 14:30 ` christian+kn at wwad.de
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=20130414061520.GA2288@grml \
--to=michi1@michaelblizek.twilightparadox.com \
--cc=kernelnewbies@lists.kernelnewbies.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.