netdev - Re: Hardware capabilities and bonding offload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151117220349.GA7762@penelope.isobedori.kobe.vergenet.net>
Date:	Tue, 17 Nov 2015 14:03:51 -0800
From:	Simon Horman <simon.horman@...ronome.com>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	Jiri Pirko <jiri@...nulli.us>,
	Premkumar Jonnala <pjonnala@...adcom.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Hardware capabilities and bonding offload

On Mon, Nov 16, 2015 at 08:10:27AM -0800, John Fastabend wrote:
> On 15-11-16 07:30 AM, Jiri Pirko wrote:
> > Mon, Nov 16, 2015 at 10:29:12AM CET, pjonnala@...adcom.com wrote:
> >> Hello,
> >>
> >> I am looking to offload bond interfaces to hardware for forwarding.  Linux allows for configuring 
> >> a variety of parameters on bonds or slave interfaces.  Not all configurations can be offloaded to 
> >> hardware.  For example, certain hardware cannot support bonds with mode of adaptive load balancing.
> >>
> >> When such a configuration is provided by user, we have two options at hand (for platforms supporting
> >> hardware offloads):
> >>
> >> 1. Reject the configuration.  
> >>
> >> 2. Handle the bond interface in software.  In a scenario where this bond interface is part
> >> of a bridge interface, for simplicity purpose, all other interfaces in the bridge need to be 
> >> handled in software - which results in a very low packet processing performance.
> > 
> > Although it might sound intriguing to fallback to sw here, it makes no
> > sense and user certainly does not want that. For example in case of our
> > HW, we have 100gbit forwarding which would be degraded to ~1gbit (for one
> > port pair). Another thing is that for some HW this mignt not be even
> > possible. In our case it would be very complicated.
> > 
> > I believe that the correct approach is to let driver decide if the
> > configuration is acceptable or not and reject it in case it is not.
> > 
> 
> +1 I agree the best approach is to throw a hard error and reject
> it if there is no mapping on to the hardware. This lets your
> management software propagate that error up so you can handle it
> correctly at higher levels in the stack.
> 
> You could if needed add a bit to enable setup in software only
> if that is needed.

FWIW, I agree that such a scheme ought to cover the bases.
But perhaps it would be best to old off on adding the software only
bit until a use-case arises. John, perhaps you already have one?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html