Re: [PATCH net-next 00/12] nfp: add flower app with representors

[Jakub Kicinski]

On Thu, 22 Jun 2017 17:28:25 +0300, Or Gerlitz wrote:
> On Wed, Jun 21, 2017 at 12:42 PM, Jakub Kicinski  wrote:
> 
> > Let me try to describe it a bit more instead.  Sorry but I'm not great
> > at ASCII art at this level of complexity and while having to stay
> > within 80 chars ;)
> >
> > Driver communicates with the Management FW via a mailbox.
> >
> > Driver loads, it gets the Application FW from disk.  It pushes the
> > entire FW to the mailbox and tells the Management FW to load it.  At
> > this point the PCIe datapath is loaded and driver discovers what
> > other communication channels are available.
> >
> > Driver checks which FW is loaded and finds appropriate nfp_app callbacks
> > for that FW.  If the nfp_app requires control message channel it will
> > map the control message queue/vNIC.  Driver spawn netdevs for
> > data vNICs.  Flower nfp_app may upon init spawn physical port
> > representors (single NFP chip supports tens of ports so they are not
> > all guaranteed a full vNIC in many designs).  Whenever representor is
> > spawned Application FW is notified with a control message.
> >
> > When user enables SR-IOV nfp_app sriov callback will be invoked and
> > flower nfp_app will respond by spawning VF reprs.  First version of the
> > Flower APP targets only the switchdev mode.  We plan to add legacy mode
> > and automatically pre-populate the rules if there is user interest.
> > Although I personally hope that people interested in legacy SR-IOV will
> > use our simpler CoreNIC app FW...  Flower APP will initially come up in
> > switchdev mode, no rules installed, all traffic will simply end up at
> > representors.  
> 
> This is much clearer now, thanks for explaining that over. Will be happy
> if you can elaborate a bit on the automatic tables pre-population for
> legacy mode emulation, sounds interesting.

Oh, I just meant that if someone wants to switch between legacy and
switchdev mode without changing the app FW - driver could hide the
representors and populate MAC/VLAN forwarding rules to get the same
behaviour as "legacy" cards have.

Re: [oss-drivers] Re: [PATCH net-next 00/12] nfp: add flower app with representors

[Simon Horman]

On Thu, Jun 22, 2017 at 05:39:09PM +0300, Or Gerlitz wrote:
> On Wed, Jun 21, 2017 at 12:32 PM, Simon Horman
>  wrote:
> 
> > This patchset is in two parts.
> >
> > The first 9 patches add code to allow representors to be instantiated
> > etc... The remaining patches provide the beginning of a flower app which
> > makes use of this infrastructure. So I think there is a clear separation
> > between representor code, in .../nfp/ and app code that uses representors,
> > in this case .../nfp/flower/.
> 
> indeed, got it.
> 
> > I could have supplied a test app to demonstrate using representors - and
> > that is really what the flower app is as of this patchset. But I chose to
> > name it flower as it we have follow-up work to make the app actually
> > offload flower and at that point that will be come its dominant feature.
> 
> As you stated, the separation is there. If got you right, it will be possible 
> to
> use representors in non flower apps, and probably also possible to have
> the flower app used in a non-SRIOV environment, just fine.

Yes, that is correct.

Re: [oss-drivers] Re: [PATCH net-next 00/12] nfp: add flower app with representors

[Or Gerlitz]

On Wed, Jun 21, 2017 at 12:32 PM, Simon Horman
 wrote:

> This patchset is in two parts.
>
> The first 9 patches add code to allow representors to be instantiated
> etc... The remaining patches provide the beginning of a flower app which
> makes use of this infrastructure. So I think there is a clear separation
> between representor code, in .../nfp/ and app code that uses representors,
> in this case .../nfp/flower/.

indeed, got it.

> I could have supplied a test app to demonstrate using representors - and
> that is really what the flower app is as of this patchset. But I chose to
> name it flower as it we have follow-up work to make the app actually
> offload flower and at that point that will be come its dominant feature.

As you stated, the separation is there. If got you right, it will be possible to
use representors in non flower apps, and probably also possible to have
the flower app used in a non-SRIOV environment, just fine.

Or.

Re: [PATCH net-next 00/12] nfp: add flower app with representors

[Or Gerlitz]

On Wed, Jun 21, 2017 at 12:42 PM, Jakub Kicinski  wrote:

> Let me try to describe it a bit more instead.  Sorry but I'm not great
> at ASCII art at this level of complexity and while having to stay
> within 80 chars ;)
>
> Driver communicates with the Management FW via a mailbox.
>
> Driver loads, it gets the Application FW from disk.  It pushes the
> entire FW to the mailbox and tells the Management FW to load it.  At
> this point the PCIe datapath is loaded and driver discovers what
> other communication channels are available.
>
> Driver checks which FW is loaded and finds appropriate nfp_app callbacks
> for that FW.  If the nfp_app requires control message channel it will
> map the control message queue/vNIC.  Driver spawn netdevs for
> data vNICs.  Flower nfp_app may upon init spawn physical port
> representors (single NFP chip supports tens of ports so they are not
> all guaranteed a full vNIC in many designs).  Whenever representor is
> spawned Application FW is notified with a control message.
>
> When user enables SR-IOV nfp_app sriov callback will be invoked and
> flower nfp_app will respond by spawning VF reprs.  First version of the
> Flower APP targets only the switchdev mode.  We plan to add legacy mode
> and automatically pre-populate the rules if there is user interest.
> Although I personally hope that people interested in legacy SR-IOV will
> use our simpler CoreNIC app FW...  Flower APP will initially come up in
> switchdev mode, no rules installed, all traffic will simply end up at
> representors.

This is much clearer now, thanks for explaining that over. Will be happy
if you can elaborate a bit on the automatic tables pre-population for
legacy mode emulation, sounds interesting.


>> The VF reps where introduced hand in hand with the devlink way to 
>> create/destroy
>> them -- e.g the devlink eswitch commands (mode change, show, enable encap, 
>> etc).

> Yes, indeed.  FWIW for programmable HW the question of mode of
> operation is more complex than selection between eswitch modes.  We
> are planning on extending devlink and our driver to handle more
> configurations as well as to expose more useful info.  But we need to
> start somewhere :)  We felt like this set with representors will
> establish a good base.  Next set will introduce basic Flower offload
> (~populating tables and reading stats).  And we can build on top of that.

I think you got it, when sriov is set on the NIC and you load this app,
we're in switchdev mode, so the devlink eswitch mode set need not be
called by user-space. But, further configuration eswitch changes could
(and would) be done through devlink callbacks.

> I think you're referring to the fact that we start in switchdev mode?
> I thought you would be happy to see a driver which doesn't even bother
> with the legacy mode ;)

YES, I am happy to see that you start in switchdev mode. I wasn't sure
why the devlink way of further configuring the eswitch can't apply for npf,
but now you made that clear it does apply.

Or.

Re: [PATCH net-next 00/12] nfp: add flower app with representors

[Jakub Kicinski]

On Wed, 21 Jun 2017 12:00:50 +0300, Or Gerlitz wrote:
> On Tue, Jun 20, 2017 at 10:24 PM, Jakub Kicinski
>  wrote:
> > On Tue, 20 Jun 2017 19:13:43 +0300, Or Gerlitz wrote:  
> 
> >>> Control queues are used to send and receive control messages which are
> >>> used to communicate configuration information with the firmware. These
> >>> are in separate vNIC to the queues belonging to the PF netdev. The control
> >>> queues are not exposed to use-space via a netdev or any other means.  
> 
> >> Do you have documentation for the control channel or I should look on
> >> earlier commits?  
> 
> > We don't have any docs, the ctrl channel was merged in e5c5180a2302
> > ("Merge branch 'nfp-ctrl-vNIC'").  The "control channel" is essentially
> > a normal data queue which is specially marked as carrying control
> > messages.  
> 
> >> The control messages you describe here are also the ones that are used
> >> to load/unload specific app?  
> 
> > No, the app loading, PHY port management and other low-level tasks are
> > handled by management FW.  The control messages are an application FW
> > construct.  The control messages are transported by the datapath and
> > since the datapath is entirely under control of apps the management FW
> > can't depend on it.  The apps today also completely reload the PCIe
> > datapath implementation (which is software defined), so we need to use
> > raw memory mappings to communicate with management FW.  
> 
> > The control messages are mostly used for populating tables and reading
> > statistics, because those two need to be fast and low overhead.  
> 
> Thanks Jakub for that clarification -- I still not sure to see the
> high level picture -
> will appreciate if you can make a simple  text based sketch here of the
> source/dest/sequence of calls/messages (say) from the time the driver is 
> loaded
> to when sriov is set with VFs and VF reps

Let me try to describe it a bit more instead.  Sorry but I'm not great
at ASCII art at this level of complexity and while having to stay
within 80 chars ;)

Driver communicates with the Management FW via a mailbox.

Driver loads, it gets the Application FW from disk.  It pushes the
entire FW to the mailbox and tells the Management FW to load it.  At
this point the PCIe datapath is loaded and driver discovers what
other communication channels are available.

Driver checks which FW is loaded and finds appropriate nfp_app callbacks
for that FW.  If the nfp_app requires control message channel it will
map the control message queue/vNIC.  Driver spawn netdevs for
data vNICs.  Flower nfp_app may upon init spawn physical port
representors (single NFP chip supports tens of ports so they are not
all guaranteed a full vNIC in many designs).  Whenever representor is
spawned Application FW is notified with a control message.

When user enables SR-IOV nfp_app sriov callback will be invoked and
flower nfp_app will respond by spawning VF reprs.  First version of the
Flower APP targets only the switchdev mode.  We plan to add legacy mode
and automatically pre-populate the rules if there is user interest.
Although I personally hope that people interested in legacy SR-IOV will
use our simpler CoreNIC app FW...  Flower APP will initially come up in
switchdev mode, no rules installed, all traffic will simply end up at
representors.

> The VF reps where introduced hand in hand with the devlink way to 
> create/destroy
> them -- e.g the devlink eswitch commands (mode change, show, enable encap, 
> etc).

Yes, indeed.  FWIW for programmable HW the question of mode of
operation is more complex than selection between eswitch modes.  We
are planning on extending devlink and our driver to handle more
configurations as well as to expose more useful info.  But we need to
start somewhere :)  We felt like this set with representors will
establish a good base.  Next set will introduce basic Flower offload
(~populating tables and reading stats).  And we can build on top of
that.

> Taking your comment that the channels are mostly used for table
> population and such,
> is there any real reason for you not to use devlink for applying the
> configuration? you can
> communicate with the FW from your devlink callbacks, isn't that?

I think you're referring to the fact that we start in switchdev mode?
I thought you would be happy to see a driver which doesn't even bother
with the legacy mode ;)

Re: [oss-drivers] Re: [PATCH net-next 00/12] nfp: add flower app with representors

[Simon Horman]

On Wed, Jun 21, 2017 at 12:00:50PM +0300, Or Gerlitz wrote:
> On Tue, Jun 20, 2017 at 10:24 PM, Jakub Kicinski
>  wrote:
> > On Tue, 20 Jun 2017 19:13:43 +0300, Or Gerlitz wrote:
> 
> >>> Control queues are used to send and receive control messages which are
> >>> used to communicate configuration information with the firmware. These
> >>> are in separate vNIC to the queues belonging to the PF netdev. The control
> >>> queues are not exposed to use-space via a netdev or any other means.
> 
> >> Do you have documentation for the control channel or I should look on
> >> earlier commits?
> 
> > We don't have any docs, the ctrl channel was merged in e5c5180a2302
> > ("Merge branch 'nfp-ctrl-vNIC'").  The "control channel" is essentially
> > a normal data queue which is specially marked as carrying control
> > messages.
> 
> >> The control messages you describe here are also the ones that are used
> >> to load/unload specific app?
> 
> > No, the app loading, PHY port management and other low-level tasks are
> > handled by management FW.  The control messages are an application FW
> > construct.  The control messages are transported by the datapath and
> > since the datapath is entirely under control of apps the management FW
> > can't depend on it.  The apps today also completely reload the PCIe
> > datapath implementation (which is software defined), so we need to use
> > raw memory mappings to communicate with management FW.
> 
> > The control messages are mostly used for populating tables and reading
> > statistics, because those two need to be fast and low overhead.
> 
> Thanks Jakub for that clarification -- I still not sure to see the
> high level picture -
> will appreciate if you can make a simple  text based sketch here of the
> source/dest/sequence of calls/messages (say) from the time the driver is 
> loaded
> to when sriov is set with VFs and VF reps
> 
> The VF reps where introduced hand in hand with the devlink way to 
> create/destroy
> them -- e.g the devlink eswitch commands (mode change, show, enable encap, 
> etc).
> 
> Taking your comment that the channels are mostly used for table
> population and such,
> is there any real reason for you not to use devlink for applying the
> configuration? you can
> communicate with the FW from your devlink callbacks, isn't that?

I will leave Jakub to respond to this question.

> Simon, another comment on this series/app, is that the VF reps can
> apply for more
> use cases beyond flower offload -- e.g FDB or FIB offloads and also
> the other way
> around, flower offloads can apply to more use cases beyond SRIOV, as any easy
> example, you can offload native NIC RX TC rule (drop, header re-write, etc).
>
> Indeed your current app code doesn't have any relation to flower beyond the
> name... maybe you can just make a rename and this way it will be less
> confusing for you.. when coming to apply more use-cases?
>
> As for flower offloads being applicable beyond SRIOV, lets see if/how
> you re-name/phrase the VF reps.

This patchset is in two parts.

The first 9 patches add code to allow representors to be instantiated
etc... The remaining patches provide the beginning of a flower app which
makes use of this infrastructure. So I think there is a clear separation
between representor code, in .../nfp/ and app code that uses representors,
in this case .../nfp/flower/.

I could have supplied a test app to demonstrate using representors - and
that is really what the flower app is as of this patchset. But I chose to
name it flower as it we have follow-up work to make the app actually
offload flower and at that point that will be come its dominant feature.

Re: [oss-drivers] Re: [PATCH net-next 00/12] nfp: add flower app with representors

[Or Gerlitz]

On Tue, Jun 20, 2017 at 10:24 PM, Jakub Kicinski
 wrote:
> On Tue, 20 Jun 2017 19:13:43 +0300, Or Gerlitz wrote:

>>> Control queues are used to send and receive control messages which are
>>> used to communicate configuration information with the firmware. These
>>> are in separate vNIC to the queues belonging to the PF netdev. The control
>>> queues are not exposed to use-space via a netdev or any other means.

>> Do you have documentation for the control channel or I should look on
>> earlier commits?

> We don't have any docs, the ctrl channel was merged in e5c5180a2302
> ("Merge branch 'nfp-ctrl-vNIC'").  The "control channel" is essentially
> a normal data queue which is specially marked as carrying control
> messages.

>> The control messages you describe here are also the ones that are used
>> to load/unload specific app?

> No, the app loading, PHY port management and other low-level tasks are
> handled by management FW.  The control messages are an application FW
> construct.  The control messages are transported by the datapath and
> since the datapath is entirely under control of apps the management FW
> can't depend on it.  The apps today also completely reload the PCIe
> datapath implementation (which is software defined), so we need to use
> raw memory mappings to communicate with management FW.

> The control messages are mostly used for populating tables and reading
> statistics, because those two need to be fast and low overhead.

Thanks Jakub for that clarification -- I still not sure to see the
high level picture -
will appreciate if you can make a simple  text based sketch here of the
source/dest/sequence of calls/messages (say) from the time the driver is loaded
to when sriov is set with VFs and VF reps

The VF reps where introduced hand in hand with the devlink way to create/destroy
them -- e.g the devlink eswitch commands (mode change, show, enable encap, etc).

Taking your comment that the channels are mostly used for table
population and such,
is there any real reason for you not to use devlink for applying the
configuration? you can
communicate with the FW from your devlink callbacks, isn't that?

Simon, another comment on this series/app, is that the VF reps can
apply for more
use cases beyond flower offload -- e.g FDB or FIB offloads and also
the other way
around, flower offloads can apply to more use cases beyond SRIOV, as any easy
example, you can offload native NIC RX TC rule (drop, header re-write, etc).

Indeed your current app code doesn't have any relation to flower beyond the
name... maybe you can just make a rename and this way it will be less
confusing for you.. when coming to apply more use-cases?

As for flower offloads being applicable beyond SRIOV, lets see if/how
you re-name/phrase the VF reps.

Or.

Re: [oss-drivers] Re: [PATCH net-next 00/12] nfp: add flower app with representors

[Jakub Kicinski]

On Tue, 20 Jun 2017 19:13:43 +0300, Or Gerlitz wrote:
> > Control queues are used to send and receive control messages which are
> > used to communicate configuration information with the firmware. These
> > are in separate vNIC to the queues belonging to the PF netdev. The control
> > queues are not exposed to use-space via a netdev or any other means.  
> 
> Do you have documentation for the control channel or I should look on
> earlier commits?

Hi Or!

We don't have any docs, the ctrl channel was merged in e5c5180a2302
("Merge branch 'nfp-ctrl-vNIC'").  The "control channel" is essentially
a normal data queue which is specially marked as carrying control
messages.

> The control messages you describe here are also the ones that are used
> to load/unload specific app?

No, the app loading, PHY port management and other low-level tasks are
handled by management FW.  The control messages are an application FW
construct.  The control messages are transported by the datapath and
since the datapath is entirely under control of apps the management FW
can't depend on it.  The apps today also completely reload the PCIe
datapath implementation (which is software defined), so we need to use
raw memory mappings to communicate with management FW.

The control messages are mostly used for populating tables and reading
statistics, because those two need to be fast and low overhead.

Re: [PATCH net-next 00/12] nfp: add flower app with representors

[Simon Horman]

On Tue, Jun 20, 2017 at 07:13:43PM +0300, Or Gerlitz wrote:
> On Tue, Jun 20, 2017 at 8:51 AM, Simon Horman
>  wrote:
> > this series adds a flower app to the NFP driver.
> > It initialises four types of netdevs:
> >
> > * PF netdev - lower-device for communication of packets to device
> > * PF representor netdev
> > * VF representor netdevs
> > * Phys port representor netdevs
> >
> > The PF netdev acts as a lower-device which sends and receives packets to
> > and from the firmware. The representors act as upper-devices. For TX
> > representors attach a metadata dst to the skb which is used by the PF
> > netdev to prepend metadata to the packet before forwarding the firmware. On
> > RX the PF netdev looks up the representor based on the prepended metadata
> > recieved from the firmware and forwards the skb to the representor after
> > removing the metadata.
> 
> Hi Simon, Jakub
> 
> Good to have more VF representors around...
> 
> > Control queues are used to send and receive control messages which are
> > used to communicate configuration information with the firmware. These
> > are in separate vNIC to the queues belonging to the PF netdev. The control
> > queues are not exposed to use-space via a netdev or any other means.
> 
> 
> 
> Do you have documentation for the control channel or I should look on
> earlier commits?

I don't believe there is any publicly available documentation
other than the code.

> The control messages you describe here are also the ones that are used
> to load/unload
> specific app?

In this patchset PORTMOD messages are used for (app-specific) configuration.

> > As the name implies this app is targeted at providing offload of TC flower.
> > That will be added by follow-up work. This patchset focuses on adding phys
> > port and VF representor netdevs to which flower classifiers may be attached.
> 
> I guess you want to have switch ID so if someone looks on the reps (ip -d)
> they can realize they all belong to the same e-switch, we are using
> switchdev attribute for that matter.

Yes, that intended to be part of follow-up patches.

> Few nits from building from static checker below.

Thanks, sorry for letting that through.
I'll fix them up ASAP.

> Or.
> 
> drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:78:1: warning:
> symbol 'nfp_repr_phy_port_get_stats64' was not declared. Should it be
> static?
> drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:98:1: warning:
> symbol 'nfp_repr_vf_get_stats64' was not declared. Should it be
> static?
> drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:118:1: warning:
> symbol 'nfp_repr_pf_get_stats64' was not declared. Should it be
> static?
> drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:262:40: warning:
> incorrect type in assignment (different base types)
> drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:262:40:expected
> unsigned int [unsigned] [usertype] port_id
> drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:262:40:got
> restricted __be32 [usertype] 
> drivers/net/ethernet/netronome/nfp/flower/main.c:116:19: warning: cast
> to restricted __be32

Re: [PATCH net-next 00/12] nfp: add flower app with representors

[Or Gerlitz]

On Tue, Jun 20, 2017 at 8:51 AM, Simon Horman
 wrote:
> this series adds a flower app to the NFP driver.
> It initialises four types of netdevs:
>
> * PF netdev - lower-device for communication of packets to device
> * PF representor netdev
> * VF representor netdevs
> * Phys port representor netdevs
>
> The PF netdev acts as a lower-device which sends and receives packets to
> and from the firmware. The representors act as upper-devices. For TX
> representors attach a metadata dst to the skb which is used by the PF
> netdev to prepend metadata to the packet before forwarding the firmware. On
> RX the PF netdev looks up the representor based on the prepended metadata
> recieved from the firmware and forwards the skb to the representor after
> removing the metadata.

Hi Simon, Jakub

Good to have more VF representors around...

> Control queues are used to send and receive control messages which are
> used to communicate configuration information with the firmware. These
> are in separate vNIC to the queues belonging to the PF netdev. The control
> queues are not exposed to use-space via a netdev or any other means.



Do you have documentation for the control channel or I should look on
earlier commits?

The control messages you describe here are also the ones that are used
to load/unload
specific app?

> As the name implies this app is targeted at providing offload of TC flower.
> That will be added by follow-up work. This patchset focuses on adding phys
> port and VF representor netdevs to which flower classifiers may be attached.

I guess you want to have switch ID so if someone looks on the reps (ip -d)
they can realize they all belong to the same e-switch, we are using
switchdev attribute for that matter.

Few nits from building from static checker below.

Or.

drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:78:1: warning:
symbol 'nfp_repr_phy_port_get_stats64' was not declared. Should it be
static?
drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:98:1: warning:
symbol 'nfp_repr_vf_get_stats64' was not declared. Should it be
static?
drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:118:1: warning:
symbol 'nfp_repr_pf_get_stats64' was not declared. Should it be
static?
drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:262:40: warning:
incorrect type in assignment (different base types)
drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:262:40:expected
unsigned int [unsigned] [usertype] port_id
drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:262:40:got
restricted __be32 [usertype] 
drivers/net/ethernet/netronome/nfp/flower/main.c:116:19: warning: cast
to restricted __be32

[PATCH net-next 00/12] nfp: add flower app with representors

[Simon Horman]

Hi,

this series adds a flower app to the NFP driver.
It initialises four types of netdevs:

* PF netdev - lower-device for communication of packets to device
* PF representor netdev
* VF representor netdevs
* Phys port representor netdevs

The PF netdev acts as a lower-device which sends and receives packets to
and from the firmware. The representors act as upper-devices. For TX
representors attach a metadata dst to the skb which is used by the PF
netdev to prepend metadata to the packet before forwarding the firmware. On
RX the PF netdev looks up the representor based on the prepended metadata
recieved from the firmware and forwards the skb to the representor after
removing the metadata.

Control queues are used to send and receive control messages which are
used to communicate configuration information with the firmware. These
are in separate vNIC to the queues belonging to the PF netdev. The control
queues are not exposed to use-space via a netdev or any other means.

As the name implies this app is targeted at providing offload of TC flower.
That will be added by follow-up work. This patchset focuses on adding phys
port and VF representor netdevs to which flower classifiers may be attached.

Jakub Kicinski (3):
  net: store port/representator id in metadata_dst
  nfp: devlink add support for getting eswitch mode
  nfp: move physical port init into a helper

Simon Horman (9):
  nfp: map mac_stats and vf_cfg BARs
  nfp: general representor implementation
  nfp: add stats and xmit helpers for representors
  nfp: app callbacks for SRIOV
  nfp: provide nfp_port to of nfp_net_get_mac_addr()
  nfp: add support for tx/rx with metadata portid
  nfp: add support for control messages for flower app
  nfp: add flower app
  nfp: add VF and PF representors to flower app

 drivers/net/ethernet/netronome/nfp/Makefile|   3 +
 drivers/net/ethernet/netronome/nfp/flower/cmsg.c   | 159 +
 drivers/net/ethernet/netronome/nfp/flower/cmsg.h   | 116 +++
 drivers/net/ethernet/netronome/nfp/flower/main.c   | 376 +
 drivers/net/ethernet/netronome/nfp/nfp_app.c   |  26 +-
 drivers/net/ethernet/netronome/nfp/nfp_app.h   |  58 +++-
 drivers/net/ethernet/netronome/nfp/nfp_app_nic.c   |  25 +-
 drivers/net/ethernet/netronome/nfp/nfp_devlink.c   |  18 +
 drivers/net/ethernet/netronome/nfp/nfp_main.c  |  42 ++-
 drivers/net/ethernet/netronome/nfp/nfp_main.h  |  11 +-
 drivers/net/ethernet/netronome/nfp/nfp_net.h   |   1 +
 .../net/ethernet/netronome/nfp/nfp_net_common.c|  57 +++-
 drivers/net/ethernet/netronome/nfp/nfp_net_main.c  | 141 +---
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c  | 352 +++
 drivers/net/ethernet/netronome/nfp/nfp_net_repr.h  | 120 +++
 drivers/net/ethernet/netronome/nfp/nfp_port.c  |  25 ++
 drivers/net/ethernet/netronome/nfp/nfp_port.h  |  63 
 .../net/ethernet/netronome/nfp/nfpcore/nfp_nsp.h   |   2 +
 .../ethernet/netronome/nfp/nfpcore/nfp_nsp_eth.c   |   5 +-
 include/net/dst_metadata.h |  41 ++-
 net/core/dst.c |  15 +-
 net/core/filter.c  |   1 +
 net/ipv4/ip_tunnel_core.c  |   6 +-
 net/openvswitch/flow_netlink.c |   4 +-
 24 files changed, 1574 insertions(+), 93 deletions(-)
 create mode 100644 drivers/net/ethernet/netronome/nfp/flower/cmsg.c
 create mode 100644 drivers/net/ethernet/netronome/nfp/flower/cmsg.h
 create mode 100644 drivers/net/ethernet/netronome/nfp/flower/main.c
 create mode 100644 drivers/net/ethernet/netronome/nfp/nfp_net_repr.c
 create mode 100644 drivers/net/ethernet/netronome/nfp/nfp_net_repr.h

-- 
2.1.4