Hello.
We have too much buffer in conjunction with traffic control. We need to drop/reduce the buffer. I can't name the buffer, so I will describe the problem:
An user space application was programmed by us, which opens a TAP interface.
This application resends the data from the TAP interface to an veeeery slow (800 bps!) proprietary network adapter.
Now we want to use traffic control on the tap interface: We create a prio 5-band queue and set the filter.
1:
/ | \
1:1 1:2 1:3 ..
This works fine:
(Example data:)
test:/root # tc -s class show dev xxx0
class prio 1:1 parent 1:
Sent 1848 bytes 44 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class prio 1:2 parent 1:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class prio 1:3 parent 1:
Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class prio 1:4 parent 1:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class prio 1:5 parent 1:
Sent 18398 bytes 31 pkt (dropped 2, overlimits 0 requeues 0)
backlog 588b 6p requeues 0
But... It seems, that there is a buffer which we didn't expect: The data will slip through the buffer in 1:x
On a fresh clear (empty) system, we send send burst data.
We expect a filling of the "backlog". But we discovered first a filling of "Sent". E.g.:
class prio 1:5 parent 1:
Sent xxx bytes 15 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
The buffer ("15" in this example) fills until TX queue size of the interface (plus one or two). Then it fills the backlog (again till TX queue size) - then it drops.
Why didn't it fill the backlog at once (ok, one or two can be already sended)? We need to drop/reduce this buffer - how to?
(We have no buffer in our application! This application just receive one packet an resend this, then it receives the next packet...)
Please help.
Regards
Ralph Erdt
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
