Merge branch 'nfp-introduce-nfp_port-and-nfp_app'
authorDavid S. Miller <davem@davemloft.net>
Mon, 22 May 2017 18:59:07 +0000 (14:59 -0400)
committerDavid S. Miller <davem@davemloft.net>
Mon, 22 May 2017 18:59:07 +0000 (14:59 -0400)
Jakub Kicinski says:

====================
nfp: introduce nfp_port and nfp_app

This series builds foundation for upcoming development.  So far the nfp
driver was focused on delivering basic NIC-like functionality.  We want
to switch gears a bit going forward and support more advanced applications.

First few patches are naming clean ups and reshuffling.  The two main
structures this series adds are nfp_port and nfp_app.

nfp_port represents a device port, where port can mean external port,
VF or PF.  For now only external port/MAC/PHY port is added.  nfp_port
is supposed to make it easy to share ethtool and devlink code regardless
of netdev type (full vNIC vs representors).

nfp_app is an abstraction which should allow easier development of new
applications.  So far we have relied fully on port capabilities to detect
which offloads and features are available.  The usual development model
for NFP is that people start with one of our "core NIC" FW apps (C one,
or a macro assembler one) and build advanced functionality on top of that.
Therefore basic netdev code is shared, but the higher-level logic is
usually more project specific.  The higher-level logic is also per-adapter
rather than per-port, so creating per-adapter control entity makes sense.
Hopefully the separation of lower-level netdev code and application logic
will help us limit interdependencies and accelerate parallel projects
(e.g. TC flower offloads vs eBPF offload).

v2:
 - don't hide definition of nfp_app to avoid silly function calls (Dave);
 - reorder kdoc of nfp_main (Simon);
 - make nfp_netdev_is_nfp_net() static inline as well.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>

Trivial merge