From: David S. Miller Date: Mon, 22 May 2017 18:59:07 +0000 (-0400) Subject: Merge branch 'nfp-introduce-nfp_port-and-nfp_app' X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=0172397e2fcc29dc803c7d0b22aa2a25e4b02991;p=GitHub%2Fmoto-9609%2Fandroid_kernel_motorola_exynos9610.git Merge branch 'nfp-introduce-nfp_port-and-nfp_app' 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 --- 0172397e2fcc29dc803c7d0b22aa2a25e4b02991