Re: Hardware capabilities and bonding offload

[Andrew Lunn <andrew@lunn.ch>]

On Wed, Nov 18, 2015 at 03:29:23PM +0100, Jiri Pirko wrote:
> Wed, Nov 18, 2015 at 03:05:12PM CET, andrew@lunn.ch wrote:
> >> To be honest though this is more of an argument in theory versus
> >> some existing management agent I know of today. If you need to do
> >> bonding type X in your network and the particular switch doesn't support
> >> it I'm not even sure what the mgmt layer is going to do. Maybe just
> >> put the switch offline for that network segment.
> >> 
> >> If you leave the sw bit out in the first iteration I'm OK with that
> >> we can easily add it when we have software that needs it.
> >
> >Taking a step back...
> >
> >Have we defined a consistent way for signalling:
> >
> >1) Failed to offload to the hardware, because the hardware cannot do
> >   what you requested.
> >2) Do this in software, rather than trying and failing to offload to
> >   hardware.
> >
> >At least in DSA, we return EOPNOTSUP for 1).
> 
> Well for example in case of bonding there is quite impossible to do
> things in software in case the hardware datapath simply cannot pass
> packets to kernel. Driver should know and should forbid such
> non-functional setup.

I said, "taking a step back..." meaning, in the general case, do we
have a well defined way to do this. What we don't want is X different
ways for Y difference API calls to say, if offload of this to hardware
fails, do it in software, if that is possible.

       Andrew