Thu, Feb 26, 2015 at 05:21:58AM CET, gospo@cumulusnetworks.com wrote:

On Wed, Feb 25, 2015 at 04:53:24PM -0800, Scott Feldman wrote:

quoted

On Wed, Feb 25, 2015 at 7:46 AM, Andy Gospodarek
[off-list ref] wrote:

quoted

On Wed, Feb 25, 2015 at 03:03:56PM +0100, Andrew Lunn wrote:
[...]

quoted

What we don't want is X chip families and Y different ways to
configure the features. Ideal we want X chip families, and one way to
configure them all.

This statement is really my primary concern.  There is lots of interest
around hardware offload at this point and it seems like there is a risk
that a lack of consistency can create problems.

I think these patches are great as they allow for the programming of the
offload hardware (and it has been pointed out that this drastically
increases performance), but one concern I have with this patch (related
to this) is that I'm not sure there is a major need to create netdevs
automatically if there is not the ability to rx/tx actual frames on
these interfaces.

Even when not used for rx/tx to CPU, it seems the netdevs are still
useful as an anchor to build higher-level constructs such as bridge or
bond, and to hang stuff like netdev stats or ethtool-ish things.

I agree that they are useful, but now we are really dealing with a
netdev that is slightly lower functionality than we expect from a netdev
right now.

Is that a real care for some device now?
I agree with Scott that we need to model is consistently. If there is
such port netdev witch cannot tx/rx, we can expose the fact using some
flag...