Re: [patch net-next 00/26] bonding/team offload + mlxsw implementation

Or Gerlitz
2015-12-02T05:53:35Z

On Tue, Dec 1, 2015 at 6:47 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, Dec 01, 2015 at 05:35:43PM CET, gerlitz.or@gmail.com wrote:
>>On Tue, Dec 1, 2015 at 5:12 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> Tue, Dec 01, 2015 at 04:06:23PM CET, gerlitz.or@gmail.com wrote:
>>>>On Tue, Dec 1, 2015 at 4:43 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>>> Tue, Dec 01, 2015 at 02:48:38PM CET, jiri@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.