[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170622190957.GB29904@vergenet.net>
Date: Thu, 22 Jun 2017 21:09:59 +0200
From: Simon Horman <simon.horman@...ronome.com>
To: Or Gerlitz <gerlitz.or@...il.com>
Cc: Jakub Kicinski <jakub.kicinski@...ronome.com>,
David Miller <davem@...emloft.net>,
Linux Netdev List <netdev@...r.kernel.org>,
oss-drivers@...ronome.com
Subject: Re: [oss-drivers] Re: [PATCH net-next 00/12] nfp: add flower app
with representors
On Thu, Jun 22, 2017 at 05:39:09PM +0300, Or Gerlitz wrote:
> On Wed, Jun 21, 2017 at 12:32 PM, Simon Horman
> <simon.horman@...ronome.com> 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.
Powered by blists - more mailing lists