IFB and bridges

Hello, all.  This is more an "out of curiosity" question.  I'm starting
to build a test environment for all I've learned about Linux traffic
shaping over the last week.  One of the devices happens to be configured
as a bridge.  It quickly became apparent that I needed to do shaping on
the individual ports and not the bridge port.

This would be a real pain if I have lots of ports - 8 or 10 or 20
identical configurations.  Would this be an ideal use for IFB? That is,
to redirect all ports to IFB and apply one set qdiscs/classes? Thanks -
John

Le samedi 10 décembre 2011 à 20:15 -0500, John A. Sullivan III a écrit :

Hello, all.  This is more an "out of curiosity" question.  I'm starting
to build a test environment for all I've learned about Linux traffic
shaping over the last week.  One of the devices happens to be configured
as a bridge.  It quickly became apparent that I needed to do shaping on
the individual ports and not the bridge port.

This would be a real pain if I have lots of ports - 8 or 10 or 20
identical configurations.  Would this be an ideal use for IFB? That is,
to redirect all ports to IFB and apply one set qdiscs/classes? Thanks -

I have no idea what your problem is.

You want to shape either egress or ingress, for different reasons (most
people shape egress), but on proxies an ingress and egress combination
is welcomed.

But having to use ingress on the same machine in place of egress, I dont
see why.

----- Original Message -----

From: "Eric Dumazet" <redacted>
To: "John A. Sullivan III" <redacted>
Cc: netdev@vger.kernel.org
Sent: Sunday, December 11, 2011 3:58:26 AM
Subject: Re: IFB and bridges

Le samedi 10 décembre 2011 à 20:15 -0500, John A. Sullivan III a
écrit :

quoted

Hello, all.  This is more an "out of curiosity" question.  I'm
starting
to build a test environment for all I've learned about Linux
traffic
shaping over the last week.  One of the devices happens to be
configured
as a bridge.  It quickly became apparent that I needed to do
shaping on
the individual ports and not the bridge port.

This would be a real pain if I have lots of ports - 8 or 10 or 20
identical configurations.  Would this be an ideal use for IFB? That
is,
to redirect all ports to IFB and apply one set qdiscs/classes?
Thanks -

I have no idea what your problem is.

You want to shape either egress or ingress, for different reasons
(most
people shape egress), but on proxies an ingress and egress
combination
is welcomed.

But having to use ingress on the same machine in place of egress, I
dont
see why.

I know IFB is often used for ingress but I wasn't really thinking of ingress filtering.  Let's say I have a 12 port Linux switch.  If any of the ports become backlogged, I want them to prioritize time sensitive traffic so I implement traffic shaping but I don't want to have to define my qdiscs, classes, and filters 12 times over if they are all the same.  So I would direct each port to an IFB (not sure if that's intolerable overhead), have a single set of qdiscs, classes, and filters, and, once those are applied, the packet arrives back on the same interface and proceeds assuming if has not been dropped or delayed. - John

Le dimanche 11 décembre 2011 à 17:38 -0500, John A. Sullivan III a > 

I know IFB is often used for ingress but I wasn't really thinking of
ingress filtering.  Let's say I have a 12 port Linux switch.  If any
of the ports become backlogged, I want them to prioritize time
sensitive traffic so I implement traffic shaping but I don't want to
have to define my qdiscs, classes, and filters 12 times over if they
are all the same.  So I would direct each port to an IFB (not sure if
that's intolerable overhead), have a single set of qdiscs, classes,
and filters, and, once those are applied, the packet arrives back on
the same interface and proceeds assuming if has not been dropped or
delayed. - John

Really ? How are you going to shape a single IFB device, if you really
have independant 12 ports. (Its a switch, not a hub after all)

A script can define your qdiscs/classes/filters hundred times, or one
thousand times, and writing such a script is far more easier than setup
IFB.

----- Original Message -----

From: "Eric Dumazet" <redacted>
To: "John A. Sullivan III" <redacted>
Cc: netdev@vger.kernel.org
Sent: Sunday, December 11, 2011 5:00:59 PM
Subject: Re: IFB and bridges

Le dimanche 11 décembre 2011 à 17:38 -0500, John A. Sullivan III a >

quoted

I know IFB is often used for ingress but I wasn't really thinking
of
ingress filtering.  Let's say I have a 12 port Linux switch.  If
any
of the ports become backlogged, I want them to prioritize time
sensitive traffic so I implement traffic shaping but I don't want
to
have to define my qdiscs, classes, and filters 12 times over if
they
are all the same.  So I would direct each port to an IFB (not sure
if
that's intolerable overhead), have a single set of qdiscs, classes,
and filters, and, once those are applied, the packet arrives back
on
the same interface and proceeds assuming if has not been dropped or
delayed. - John

Really ? How are you going to shape a single IFB device, if you
really
have independant 12 ports. (Its a switch, not a hub after all)

A script can define your qdiscs/classes/filters hundred times, or one
thousand times, and writing such a script is far more easier than
setup
IFB.

<grin> That's why I thought I'd ask the experts :) - John

W dniu 2011-12-12 01:42, John A. Sullivan III pisze:

----- Original Message -----

quoted

From: "Eric Dumazet"<redacted>
To: "John A. Sullivan III"<redacted>
Cc: netdev@vger.kernel.org
Sent: Sunday, December 11, 2011 5:00:59 PM
Subject: Re: IFB and bridges

Le dimanche 11 décembre 2011 à 17:38 -0500, John A. Sullivan III a>

quoted

I know IFB is often used for ingress but I wasn't really thinking
of
ingress filtering.  Let's say I have a 12 port Linux switch.  If
any
of the ports become backlogged, I want them to prioritize time
sensitive traffic so I implement traffic shaping but I don't want
to
have to define my qdiscs, classes, and filters 12 times over if
they
are all the same.  So I would direct each port to an IFB (not sure
if
that's intolerable overhead), have a single set of qdiscs, classes,
and filters, and, once those are applied, the packet arrives back
on
the same interface and proceeds assuming if has not been dropped or
delayed. - John

Really ? How are you going to shape a single IFB device, if you
really
have independant 12 ports. (Its a switch, not a hub after all)

A script can define your qdiscs/classes/filters hundred times, or one
thousand times, and writing such a script is far more easier than
setup
IFB.

<grin>  That's why I thought I'd ask the experts :) - John
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Also directing all traffic from all 12 ports is not good idea :)
It is performance killer

IFB can't handle too much pps

Also - You can't have too many tc filters/classes on one single IFB 
device because this is also performance killer.