All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <simon.horman@netronome.com>
To: Or Gerlitz <gerlitz.or@gmail.com>
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>,
	David Miller <davem@davemloft.net>,
	Linux Netdev List <netdev@vger.kernel.org>,
	oss-drivers@netronome.com
Subject: Re: [oss-drivers] Re: [PATCH net-next 00/12] nfp: add flower app with representors
Date: Wed, 21 Jun 2017 11:32:17 +0200	[thread overview]
Message-ID: <20170621093212.GA3656@vergenet.net> (raw)
In-Reply-To: <CAJ3xEMjTLs0aDLY_zDerm8o0yPmJktzBDE2rJ=QwXQZeS1+qCg@mail.gmail.com>

On Wed, Jun 21, 2017 at 12:00:50PM +0300, Or Gerlitz wrote:
> On Tue, Jun 20, 2017 at 10:24 PM, Jakub Kicinski
> <jakub.kicinski@netronome.com> 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.

  reply	other threads:[~2017-06-21  9:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-20  5:51 [PATCH net-next 00/12] nfp: add flower app with representors Simon Horman
2017-06-20  5:51 ` [PATCH net-next 01/12] net: store port/representator id in metadata_dst Simon Horman
2017-06-20  5:51 ` [PATCH net-next 02/12] nfp: devlink add support for getting eswitch mode Simon Horman
2017-06-20  5:51 ` [PATCH net-next 03/12] nfp: move physical port init into a helper Simon Horman
2017-06-20  5:51 ` [PATCH net-next 04/12] nfp: map mac_stats and vf_cfg BARs Simon Horman
2017-06-20  5:51 ` [PATCH net-next 05/12] nfp: general representor implementation Simon Horman
2017-06-20  5:51 ` [PATCH net-next 06/12] nfp: add stats and xmit helpers for representors Simon Horman
2017-06-20 17:15   ` kbuild test robot
2017-06-20 20:48     ` Simon Horman
2017-06-20  5:51 ` [PATCH net-next 07/12] nfp: app callbacks for SRIOV Simon Horman
2017-06-20  5:51 ` [PATCH net-next 08/12] nfp: provide nfp_port to of nfp_net_get_mac_addr() Simon Horman
2017-06-20  5:51 ` [PATCH net-next 09/12] nfp: add support for tx/rx with metadata portid Simon Horman
2017-06-20  5:51 ` [PATCH net-next 10/12] nfp: add support for control messages for flower app Simon Horman
2017-06-20  5:51 ` [PATCH net-next 11/12] nfp: add " Simon Horman
2017-06-20  5:51 ` [PATCH net-next 12/12] nfp: add VF and PF representors to " Simon Horman
2017-06-20 16:13 ` [PATCH net-next 00/12] nfp: add flower app with representors Or Gerlitz
2017-06-20 19:19   ` Simon Horman
2017-06-20 19:24   ` [oss-drivers] " Jakub Kicinski
2017-06-21  9:00     ` Or Gerlitz
2017-06-21  9:32       ` Simon Horman [this message]
2017-06-22 14:39         ` Or Gerlitz
2017-06-22 19:09           ` Simon Horman
2017-06-21  9:42       ` Jakub Kicinski
2017-06-22 14:28         ` Or Gerlitz
2017-06-23  5:50           ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170621093212.GA3656@vergenet.net \
    --to=simon.horman@netronome.com \
    --cc=davem@davemloft.net \
    --cc=gerlitz.or@gmail.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.