RE: Pfifo_fast "Unknown qdisc" and asking for basic design advice

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Andy,

Many thanks for the reply.

Is there a reason why the user is not supposed to use pfifo_fast?  I
don't think I need a full-on PRIO (surely pfifo_fast is more efficient
if it is classless?).  Sorry for asking, but I didn't come across this
limitation in the documentation.

Following your suggestions, I've come up with the following:

	#!/bin/sh
	SQ="tc qdisc add dev eth0"
	SC="tc class add dev eth0"
	SF="tc filter add dev eth0"
	
	tc qdisc del dev eth0 root
	$SQ root handle 1:0 htb
	$SC parent 1:0 classid 1:1 htb rate 4096kbit
	$SC parent 1:1 classid 1:2 htb prio 0 rate 768kbit #Video
Conferencing
	$SC parent 1:1 classid 1:3 htb prio 1 rate 1545kbit #Company 1
	$SC parent 1:1 classid 1:4 htb prio 1 rate 832kbit #Company 2
	$SC parent 1:1 classid 1:5 htb prio 1 rate 713kbit #Company 3
	$SC parent 1:1 classid 1:6 htb prio 1 rate 238kbit #Company 4
	$SQ parent 1:2 handle 5:0 prio #Video Conferencing
	$SQ parent 1:3 handle 6:0 prio #Company 1
	$SQ parent 1:4 handle 7:0 prio #Company 2
	$SQ parent 1:5 handle 8:0 prio #Company 3
	$SQ parent 1:6 handle 9:0 prio #Company 4
	
	$SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.4/32
flowid 5:0
	$SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.5/32
flowid 6:0
	$SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.6/32
flowid 7:0
	$SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.7/32
flowid 8:0
	$SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.8/32
flowid 9:0

(I've a horrible feeling there's something obviously and fundamentally
wrong with this)

What happens with any traffic not from these IPs?

Many thanks,

Mark Lidstone
IT and Network Support Administrator

BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton.  SO14 3TJ. UK
Tel: +44 (0)23 8063 5122         
Fax: +44 (0)23 8063 5144

E-Mail:  mailto:mark.lidstone@xxxxxxxxxxxxxxxx
Website: www.bmtseatech.co.uk
========================================================================
==
Confidentiality Notice and Disclaimer: 
The contents of this e-mail and any attachments are intended only for
the
use of the e-mail addressee(s) shown. If you are not that person, or one
of those persons, you are not allowed to take any action based upon it
or
to copy it, forward, distribute or disclose the contents of it and you
should please delete it from your system. BMT SeaTech Limited does not
accept liability for any errors or omissions in the context of this
e-mail
or its attachments which arise as a result of Internet transmission, nor
accept liability for statements which are those of the author and not
clearly made on behalf of BMT SeaTech Limited.
========================================================================
==
  
-----Original Message-----
From: Andy Furniss [mailto:andy.furniss@xxxxxxxxxxxxx] 
Sent: 11 November 2005 14:22
To: Mark Lidstone
Cc: lartc@xxxxxxxxxxxxxxx
Subject: Re:  Pfifo_fast "Unknown qdisc" and asking for basic
design advice

Mark Lidstone wrote:
> Hi all,
> 
> I've done a search through the archives but I can't find a 
> cause/solution to this.
> 
> I'm running a FC4 box with the stock 2.6.12 kernel and a FC2 box with 
> a stock 2.6.9 kernel.  I'm obviously using
> iproute2 and the patched tc.
> 
> When I clear down the qdiscs with "tc qdisc del dev <DEV> root" I get 
> the following in response to "tc qdisc":
> 
> 	qdisc pfifo_fast 0: dev eth0 [Unknown qdisc, optlen=20]
> 	qdisc pfifo_fast 0: dev eth1 [Unknown qdisc, optlen=20]
> 
> Unfortunately I cannot add pfifo_fast as a queue type (I was hoping to

> use one - see below).  Have I missed something?

pfifo_fast is what you get as default on interfaces - it's just like
prio but not meant to be used by you - I suppose you could nest prios,
but in this case I think what you need is just pfifo or bfifo.


> 
> Secondly, I was wondering if anyone could look over what I am trying 
> to do and point out any stupid mistakes I've made.  I am trying to get

> the following setup working:
> 
>               root
>                |
>                |
>               PRIO
>              / | \
>       ______/  |  \______
>      |         |         |
>      0         |         2
>  pfifo_fast    1        sfq
>               HTB__________
>              / | \         \
>       ______/  |  \______   \______
>      |         |         |         |
>     sfq       sfq       sfq       sfq
> 
> Basically, we have 4 companies that will be sharing bandwidth on a 
> connection (the four sfq's at the bottom) and some video conferencing 
> equipment that needs priority over everything (the pfifo_fast).  Have 
> I misunderstood anything vital here?

You would be better off having htb as root so you can throttle traffic
to below link speed. You can htb's prio parameter to do much the same.

Sfq is nice but the perturb causes packet reordering I would think about
trying to seperate each customers traffic into bulk and interactive
aswell and just use sfq on bulk.

Andy.


> 
> Many thanks,
> 
> Mark Lidstone
> IT and Network Support Administrator
> 
> BMT SeaTech Ltd
> Grove House, Meridians Cross, 7 Ocean Way Ocean Village, Southampton.
> SO14 3TJ. UK
> Tel: +44 (0)23 8063 5122         
> Fax: +44 (0)23 8063 5144
> 
> E-Mail:  mailto:mark.lidstone@xxxxxxxxxxxxxxxx
> Website: www.bmtseatech.co.uk
> ======================================================================
> ==
> ==
> Confidentiality Notice and Disclaimer: 
> The contents of this e-mail and any attachments are intended only for 
> the use of the e-mail addressee(s) shown. If you are not that person, 
> or one of those persons, you are not allowed to take any action based 
> upon it or to copy it, forward, distribute or disclose the contents of

> it and you should please delete it from your system. BMT SeaTech 
> Limited does not accept liability for any errors or omissions in the 
> context of this e-mail or its attachments which arise as a result of 
> Internet transmission, nor accept liability for statements which are 
> those of the author and not clearly made on behalf of BMT SeaTech
Limited.
> ======================================================================
> ==
> ==
>   
> _______________________________________________
> LARTC mailing list
> LARTC@xxxxxxxxxxxxxxx
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 

_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux