Re: IFB and bridges

["John A. Sullivan III" <jsullivan@opensourcedevel.com>]

----- Original Message -----
> From: "Eric Dumazet" <eric.dumazet@gmail.com>
> To: "John A. Sullivan III" <jsullivan@opensourcedevel.com>
> 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 :
> > 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