On 19 December 2014 at 14:31, B Viswanath <marichi...@gmail.com> wrote: > On 19 December 2014 at 13:57, Jiri Pirko <j...@resnulli.us> wrote: >> Fri, Dec 19, 2014 at 06:14:57AM CET, marichi...@gmail.com wrote: >>>On 19 December 2014 at 05:18, Roopa Prabhu <ro...@cumulusnetworks.com> wrote: >>>> On 12/18/14, 3:26 PM, Samudrala, Sridhar wrote: > <snipped for ease of reading> >>>>> >>>>> >>>>> We also need an interface to set per-switch attributes. Can this work? >>>>> bridge link set dev sw0 sw_attr bcast_flooding 1 master >>>>> where sw0 is a bridge representing the hardware switch. >>>> >>>> >>>> Not today. We discussed this @ LPC, and one way to do this would be to have >>>> a device >>>> representing the switch asic. This is in the works. >>> >>> >>>Can I assume that on platforms which house more than one asic (say >>>two 24 port asics, interconnected via a 10G link or equivalent, to get >>>a 48 port 'switch') , the 'rocker' driver (or similar) should expose >>>them as a single set of ports, and not as two 'switch ports' ? >> >> Well that really depends on particular implementation and drivers. If you >> have 2 pci-e devices, I think you should expose them as 2 entities. For >> sure, you can have the driver to do the masking for you. I don't believe >> that is correct though. >> > > In a platform that houses two asic chips, IMO, the user is still > expected to manage the router as a single entity. The configuration > being applied on both asic devices need to be matching if not > identical, and may not be conflicting. The FDB is to be synchronized > so that (offloaded) switching can happen across the asics. Some of > this stuff is asic specific anyway. Another example is that of the > learning. The (hardware) learning can't be enabled on one asic, while > being disabled on another one. The general use cases I have seen are > all involving managing the 'router' as a single entity. That the > 'router' is implemented with two asics instead of a single asic (with > more ports) is to be treated as an implementation detail. This is the > usual router management method that exists today. > > I hope I make sense. > > So I am trying to figure out what this single entity that will be used > from a user perspective. It can be a bridge, but our bridges are more > 802.1q bridges. We can use the 'self' mode, but then it means that it > should reflect the entire port count, and not just an asic. > > So I was trying to deduce that in our switchdevice model, the best bet > would be to leave the unification to the driver (i.e., to project the > multiple physical asics as a single virtual switch device). This > allows any 'switch' level configurations to the bridge in 'self' mode. > > And then we would need to consider stacking. Stacking differs from > this multi-asic scenario since there would be multiple CPU involved. > > Thanks > Vissu >
Another example i can provide is that of mirroring. Imagine user wanted to mirror all traffic from port 1 of asic 1 to port 2 of asic 2. This can be offloaded to hardware. However, user would be able to enter such a command only if he/she can look at a single management entity. Thanks Vissu >>> >>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe netdev" in >>>> the body of a message to majord...@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
