Add NFP_NET_META_XDP_META_LEN metatype

[aspsk]

This PR required by Netronome/nic-firmware#6

[JohanM84]

I'm fine with this change, but @mrapson-netronome and @kuba-moo must also approve

[mrapson-netronome]

The particular file modified by this patch (kernel/nfp_net_ctrl.h) the firmware copy of https://github.com/Netronome/nfp-drv-kmods/blob/master/src/nfp_net_ctrl.h. The usual process for changes that will be upsteamed is as follows:

1. Prototype new feature and determine host-FW ABI changes required
2. With prototype FW, test final nfp-drv-kmods change sets, start upstreaming process for that repo
3. When nfp-drv-kmods changes are accepted upstream, expose the new APIs to FW via the kernel/nfp_net_ctrl.h file.

Note that NFP_NET_META "7" has been assigned to NFP_NET_META_CONN_HANDLE.

Overall, you are welcome to continue testing with a NFP_NET_META_XDP_META_LEN meta type, but this pull request can only be accepted once the driver side changes are accepted upstream.

[aspsk]

With prototype FW, test final nfp-drv-kmods change sets, start upstreaming process for that repo

Thanks for the explanations @mrapson-netronome!

A question for you and/or @kuba-moo. Is the https://github.com/Netronome/nfp-drv-kmods repository the source of truth for host driver or the linux kernel? (i.e., should I rebase my host-side patch on top of the nfp-drv-kmods repo or, the net-next kernel?)

[kuba-moo]

They should be in sync, if in doubt kernel is the source of truth. To be precise whatever exists in a released kernel (i.e. not a -rc release or someone's tree) is hard driver ABI, beyond that it's case-by-case, but David Miller's net-next tree usually takes precedence.
In your case whatever is easiest, with enough parameters git should be able to cross apply the patches and I will have to cross apply them to one of the two, anyway, to keep them in sync. Unless you want to produce both versions, obviously :)