Share network traffic between process with respect to a priority number.

Share network traffic between process with respect to a priority number.

[Sameer Rahmani]

Hi guys

for years i have problems with sharing my network bandwidth between my 
processes. when one of my running processes (e.g axel) start to download 
data my other processes that needs bandwidth stop working (because they 
can't download their data) . i know that there is some tools like lartc 
but i was thinking about a priority value like NICE for this matter. 
kernel will share the bandwidth between process with respect to their 
network priority number let's call it NNICE ( or what ever ) . The 
process with highest NNICE will use the highest bandwidth.

It's just an raw idea, i want to know your idea about the basic , and 
improve it.
What do you think?

With respect
Sameer Rahmani

Re: Share network traffic between process with respect to a priority number.

[Eric Dumazet]

On Wed, 2012-07-25 at 11:21 +0430, Sameer Rahmani wrote:
> Hi guys
> 
> for years i have problems with sharing my network bandwidth between my 
> processes. when one of my running processes (e.g axel) start to download 
> data my other processes that needs bandwidth stop working (because they 
> can't download their data) . i know that there is some tools like lartc 
> but i was thinking about a priority value like NICE for this matter. 
> kernel will share the bandwidth between process with respect to their 
> network priority number let's call it NNICE ( or what ever ) . The 
> process with highest NNICE will use the highest bandwidth.
> 
> It's just an raw idea, i want to know your idea about the basic , and 
> improve it.
> What do you think?

I think that's its hard to limit incoming data, on a general case.

Once frame is received, its too late, it already used the link
bandwidth.

A solution is to install a shaper on ingress, so that incoming tcp
frames might be delayed a bit _before_ incoming tcp stack, if they come
on a busy flow/link.

Using fq_codel sounds the right way : delay should be minimal for
interactive flows, and bigger for elephant flows.

It really should help you.

Check your kernel config has :

CONFIG_IFB=m
CONFIG_NET_SCH_INGRESS=y
CONFIG_NET_SCH_FQ_CODEL=m (or y)
CONFIG_NET_SCH_CBQ=m (or y)

Then adapt/use following script (can use HTB instead of CBQ of course)

ETH=eth0
IFB=ifb0
LOCALNETS="172.16.0.0/12 192.168.0.0/16 10.0.0.0/8"
RATE="rate 4Mbit bandwidth 4Mbit maxburst 80 minburst 40"
ALLOT="allot 8000" 

modprobe ifb
ip link set dev $IFB up

tc qdisc add dev $ETH ingress 2>/dev/null

tc filter add dev $ETH parent ffff: \
   protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress \
   redirect dev $IFB

tc qdisc del dev $IFB root


# Lets say our NIC is 100Mbit
tc qdisc add dev $IFB root handle 1: cbq avpkt 1000 \
    rate 100Mbit bandwidth 100Mbit

tc class add dev $IFB parent 1: classid 1:1 cbq allot 10000 \
	mpu 64 rate 100Mbit prio 1 \
	bandwidth 100Mbit maxburst 150 avpkt 1500 bounded

# Class for traffic coming from Internet : limited to X Mbits
tc class add dev $IFB parent 1:1 classid 1:11 \
	cbq $ALLOT mpu 64      \
	$RATE prio 2 \
	avpkt 1400 bounded

tc qdisc add dev $IFB parent 1:11 handle 11: fq_codel


# Traffic from machines in our LAN : no limit
for privnet in $LOCALNETS
do
	tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \
		match ip src $privnet flowid 1:1
done

tc filter add dev $IFB parent 1: protocol ip prio 2 u32 \
	match ip protocol 0 0x00 flowid 1:11