All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Renzmann <mrenzmann@otaku42.de>
To: lartc@vger.kernel.org
Subject: [LARTC] Question(s) for the programming gurus
Date: Thu, 29 Jan 2004 00:06:29 +0000	[thread overview]
Message-ID: <40184E85.6000807@otaku42.de> (raw)

Hi all.

I'm quite new to the concepts of the "traffic control" framework, and 
I've got a programming-related question. Hopefully someone has the answer...

Is it possible, either for the device driver itself or for a userspace 
program, to get information about how many packets are currently queued 
for a given network interface?

Let's describe it a little more in detail:

I have a network interface eth0 in my linux box. Now I apply traffic 
shaping to that interface, for example the outgoing traffic is shaped 
down to 1 MBit/s. There is an application that creates packets which are 
meant to be sent out via eth0, and the application creates its packets 
with a much higher rate than 1 MBit/s. This would result in the shaper 
enqueuing packets for eth0 and, sooner or later, in dropping some of the 
packets if the queue is full.

So I want to slow down the rate at which the application creates its 
packets. The easiest way would be to take a look at the "traffic 
control" queues for eth0 and check their current state. When the queue 
is filled up to a specified level, the application should stop creation 
of new packets until the queue has been emptied. (*)

So, is there any way for my application to check the state of the 
eth0-queues? Or is this possible for the driver of eth0 (as I'm in 
control of this driver, I could implement a way to pass the needed 
information down to the application if necessary)?

Next question: if I understood the concepts of the "traffic control" 
system correctly, one could add several queues to a single device. Is 
there any way to simply get the total amount of packets that are waiting 
in all attached queues? Or would I need to check each queue and sum up 
the values?

And last question: what kind of information can I get about the 
currently enqueued packets? Just the amount of packets that are 
enqueued, or only the amount of enqueued bytes, or both?

I'd appreciate any kind of help very much. Pointers to existing 
documentation welcome - I didn't find the answers in the docs I found, 
but maybe I just didn't search well enough (or in the wrong places)?

Thanks in advance.

Bye, Mike

(*) In other words: I want to have the effects of slowing down the 
traffic generation of my application without having to care about the 
actual implementation of the traffic shaping. In my special case this 
makes sense and would save me a lot of work.

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

             reply	other threads:[~2004-01-29  0:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-29  0:06 Michael Renzmann [this message]
2004-01-29  8:43 ` [LARTC] Question(s) for the programming gurus Lars Landmark
2004-01-29 10:23 ` Michael Renzmann
2004-01-29 13:12 ` Lars Landmark
2004-01-29 18:07 ` Michael Renzmann
2004-01-30 10:44 ` Lars Landmark

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=40184E85.6000807@otaku42.de \
    --to=mrenzmann@otaku42.de \
    --cc=lartc@vger.kernel.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.