QDISC y loopback

[Miguel Oyarzo]

At 11:47 a.m. 12/01/2005, Rodrigo Henriquez M - Corporacion Linux S.A. wrote:
>On Wed, Jan 12, 2005 at 11:41:53AM -0300, Miguel Oyarzo wrote:
> > >
> > >Agregarle un componente extra para limitar el acceso a un dispositivo
> > >(ya sea fisico o virtual) es solo darle mas trabajo al kernel.
> >
> >
> > No es suficiente argumento. Piensalo as?:
> >
> > Un ejemplo de ello:
> > La mayor?a de los kernels de Linux manejan el trafico de las interfaces su
> > cola por omision:  pfifo_fast.
> >
> > Pero esta cola no es "justa" y en sistemas de mucho trafico es muy inutil.
> > Por eso se programaron colas con clases (para QoS) con posibilida de
> > cambiar a SFQ y colas similares.
> >
> > Yo me cambie hace tiempo desde pfifo_fast  a SFQ pues  al kernel 
> necesitaba
> > darle una cola mas justa  y que le permira gestionar mejor el trafico.
> >
> > El resultado final es es mejor que bueno.
>
>Y estas seguro que eso se aplica a interfaces de tipo loopback?
>Yo no lo creo.


Pues creelo:

mira:

# ip link show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue     (NO TIENE COLA)

# tc qdisc add dev lo root handle 1: htb
# ip link show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc htb     (AHORA TIENE COLA Y CON CLASE!!!)

es decir,  puedes permitir clases en "lo".. además,
tambien puedo aplicar SFQ a subclases creadas a esta interfaz.
No veo donde vez el problema aun.

Lo anterior sería como la primera parte del experimiento.

La II parte es saber si puedo controlar mediante HTB la carga de algunas 
aplicaciones
encolando y clasificando su trafico interno.

cuando tenga algo lo comento.

Salu2

Miguel Oyarzo
INALAMBRICA
Punta Arenas