Wed, Dec 02, 2015 at 06:53:35AM CET, gerlitz...@gmail.com wrote: >On Tue, Dec 1, 2015 at 6:47 PM, Jiri Pirko <j...@resnulli.us> wrote: >> Tue, Dec 01, 2015 at 05:35:43PM CET, gerlitz...@gmail.com wrote: >>>On Tue, Dec 1, 2015 at 5:12 PM, Jiri Pirko <j...@resnulli.us> wrote: >>>> Tue, Dec 01, 2015 at 04:06:23PM CET, gerlitz...@gmail.com wrote: >>>>>On Tue, Dec 1, 2015 at 4:43 PM, Jiri Pirko <j...@resnulli.us> wrote: >>>>>> Tue, Dec 01, 2015 at 02:48:38PM CET, j...@resnulli.us wrote: > >>>>>>>This patchset introduces needed infrastructure for link aggregation >>>>>>>offload - for both team and bonding. It also implements the offload >>>>>>>in mlxsw driver. > >>>>>I didn't see any changes to switchdev.h, can you elaborate on that please. > >>>> Correct. This patchset does not extend switchdev api. The extension is >>>> done for netdev notifiers. It seems natural and correct. >>>> As we discussed already with John on a different thread, it makes sense >>>> for non-switchdev drivers to benefit from this extensions as well. > >>>This is understood. > >>>However, the point which is still not clear to me related to the LAG / >>>switchdev object model. > >>>All of FDB/VLAN/FIB switchdev objects have corresponding software >>>counterparts >>>in the kernel --- what's the case for LAG? the software construct is >>>bond or team >>>instance, shouldn't there be a modeling of the HW LAG object in switchdev? > >> No need for that, what that would be good for? > >I'll give it 2nd thought, also lets see what other reviewers think on >this matter. > >Another question relates to users bonding/teaming netdevice ports from >different HW switches, or of two vlans over ports from the same HW switch. > >This is something that AFAIK not supported by HW -- do we want to >disallow that? >what layer in the kernel we want to enforce that limitation? team/bond >or switchdev >core or the switchdev HW driver?
It is not handled at the moment. In can be easily disallowed by driver. -- 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
