* IFB and bridges @ 2011-12-11 1:15 John A. Sullivan III 2011-12-11 8:58 ` Eric Dumazet 0 siblings, 1 reply; 6+ messages in thread From: John A. Sullivan III @ 2011-12-11 1:15 UTC (permalink / raw) To: netdev 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IFB and bridges 2011-12-11 1:15 IFB and bridges John A. Sullivan III @ 2011-12-11 8:58 ` Eric Dumazet 2011-12-11 22:38 ` John A. Sullivan III 0 siblings, 1 reply; 6+ messages in thread From: Eric Dumazet @ 2011-12-11 8:58 UTC (permalink / raw) To: John A. Sullivan III; +Cc: netdev 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IFB and bridges 2011-12-11 8:58 ` Eric Dumazet @ 2011-12-11 22:38 ` John A. Sullivan III 2011-12-11 22:00 ` Eric Dumazet 0 siblings, 1 reply; 6+ messages in thread From: John A. Sullivan III @ 2011-12-11 22:38 UTC (permalink / raw) To: Eric Dumazet; +Cc: netdev ----- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IFB and bridges 2011-12-11 22:38 ` John A. Sullivan III @ 2011-12-11 22:00 ` Eric Dumazet 2011-12-12 0:42 ` John A. Sullivan III 0 siblings, 1 reply; 6+ messages in thread From: Eric Dumazet @ 2011-12-11 22:00 UTC (permalink / raw) To: John A. Sullivan III; +Cc: netdev 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IFB and bridges 2011-12-11 22:00 ` Eric Dumazet @ 2011-12-12 0:42 ` John A. Sullivan III 2011-12-14 19:36 ` Paweł Staszewski 0 siblings, 1 reply; 6+ messages in thread From: John A. Sullivan III @ 2011-12-12 0:42 UTC (permalink / raw) To: Eric Dumazet; +Cc: netdev ----- 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 5:00:59 PM > Subject: Re: IFB and bridges > > 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. > > > > <grin> That's why I thought I'd ask the experts :) - John ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: IFB and bridges 2011-12-12 0:42 ` John A. Sullivan III @ 2011-12-14 19:36 ` Paweł Staszewski 0 siblings, 0 replies; 6+ messages in thread From: Paweł Staszewski @ 2011-12-14 19:36 UTC (permalink / raw) To: John A. Sullivan III; +Cc: Eric Dumazet, netdev W dniu 2011-12-12 01:42, John A. Sullivan III pisze: > > ----- 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 5:00:59 PM >> Subject: Re: IFB and bridges >> >> 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. >> >> >> >> > <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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-12-14 19:36 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-11 1:15 IFB and bridges John A. Sullivan III 2011-12-11 8:58 ` Eric Dumazet 2011-12-11 22:38 ` John A. Sullivan III 2011-12-11 22:00 ` Eric Dumazet 2011-12-12 0:42 ` John A. Sullivan III 2011-12-14 19:36 ` Paweł Staszewski
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.