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, pjonn...@broadcom.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
