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? > Switchdev iface (most of it) works with struct net_device. Does not matter > if that is the port netdev direclty, or if it is team/bonding netdev. > It falls into the picture very nicely. Or. -- 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
