All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>, <jic23@kernel.org>,
	"Liguozhu (Kenneth)" <liguozhu@hisilicon.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	<francois.ozog@linaro.org>, <Prasad.Athreya@cavium.com>,
	<arndbergmann@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Frederic Barrat <fbarrat@linux.vnet.ibm.com>,
	Mark Brown <broonie@kernel.org>,
	<Tirumalesh.Chalamarla@cavium.com>, <jcm@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"Jean-Philippe Brucker" <jean-philippe.brucker@arm.com>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Eric Auger <eric.auger@redhat.com>, <kvm@vger.kernel.org>,
	<linux-crypto@vger.kernel.org>, <linuxarm@huawei.com>,
	Balbir Singh <bsingharora@gmail.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Alistair Po
Subject: Re: New Linux accelerators discussion list [was: Re: Fostering linux community collaboration on hardware accelerators]
Date: Tue, 17 Oct 2017 13:48:10 +0100	[thread overview]
Message-ID: <20171017134810.000049a9@huawei.com> (raw)
In-Reply-To: <a2031056-9ab4-cd03-1a18-f60d338ce090@au1.ibm.com>

On Tue, 17 Oct 2017 11:00:40 +1100
Andrew Donnellan <andrew.donnellan@au1.ibm.com> wrote:

> On 17/10/17 01:07, Jonathan Cameron wrote:
> > <snip>
> >   
> >>> So as ever with a linux community focusing on a particular topic, the
> >>> obvious solution is a mailing list. There are a number of options on how
> >>> do this.
> >>>
> >>> 1) Ask one of the industry bodies to host? Who?
> >>>
> >>> 2) Put together a compelling argument for linux-accelerators@vger.kernel.org
> >>> as probably the most generic location for such a list.  
> >>
> >> Happy to offer linux-accelerators@lists.ozlabs.org, which I can get set
> >> up immediately (and if we want patchwork, patchwork.ozlabs.org is
> >> available as always, no matter where the list is hosted).
> >>  
> > 
> > That would be great! Thanks for doing this. Much easier to find out what
> > such a list is useful for by the practical option of having a list and
> > see what people do with it.  
> 
> [+ LKML]
> 
> We now have a mailing list:
> 
>    List:      linux-accelerators@lists.ozlabs.org
>    Info:      https://lists.ozlabs.org/listinfo/linux-accelerators
>    Archives:  https://lists.ozlabs.org/pipermail/linux-accelerators
> 
> I haven't set up Patchwork as yet, but if people think that's a good 
> idea I can get that done too.
> 
> 
> Andrew
> 

Thanks Andrew.

A quick summary of initial thoughts on scope of this list for anyone
entering the discussion at this point.
Note it will hopefully evolve in whatever direction people find helpful.
This contains some suggestions not a barrier to wider scope!

There are a number of projects / applications involving what are
termed hardware accelerators.  These include:
* Traditional offload engines
	- Crypto, compression, media transcoding and similar accelerators
	- usecases including kTLS, Storage Encryption etc.
* Dynamic FPGA type accelerators
* ODP, DPDK and similar networking data plane - particularly dual stack
  solutions where the kernel 'plays nicely' with userspace drivers.
* AI Accelerators
* Shared Virtual Memory (SVM) bus systems including Open-CAPI, CCIX etc
* Fast data flow to/from userspace applications.

A number of existing project focus on these:
* Mainline kernel drivers
	- Numerous crypto drivers etc
	- Open-CAPI
* Various networking data plane activities
* VFIO based and similar userspace drivers
Hopefully this list can provide a broader forum where more general
questions are being considered.

The discussion that lead to this list was that a number of people would
like a general open forum on which to discuss ideas with scope beyond
simply one kernel subsystem or one particular userspace framework.

Topics might include
* RFCs and early reviews of new approaches.
* Similar hardware - who is trying to solve the same problems?
* What would we ideally want from new hardware iterations?
* Hardware description - the question of how to chose a particular
  crypto engine is very dependent on the particular data flows.
  Sometimes hardware accelerators don't actually help due to overheads.
  Understanding those barriers would be very useful.
* Upstream paths - blockers and how to work with the communities to
  overcome them.
* Fostering stronger userspace communities to allow these accelerators to 
  be easily harnessed.
	- A number of projects have been highlighted in this thread
	  OpenStack (cyborg project), openMP accelerator support 
* Robustness / security of userspace frameworks.
* Virtualisation of accelerators

Anyhow, this email was just meant to draw together some thoughts.
It will be interesting to see what the list actually gets used for :)

Jonathan

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>, <jic23@kernel.org>,
	"Liguozhu (Kenneth)" <liguozhu@hisilicon.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	<francois.ozog@linaro.org>, <Prasad.Athreya@cavium.com>,
	<arndbergmann@gmail.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Frederic Barrat <fbarrat@linux.vnet.ibm.com>,
	Mark Brown <broonie@kernel.org>,
	<Tirumalesh.Chalamarla@cavium.com>, <jcm@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"Jean-Philippe Brucker" <jean-philippe.brucker@arm.com>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Eric Auger <eric.auger@redhat.com>, <kvm@vger.kernel.org>,
	<linux-crypto@vger.kernel.org>, <linuxarm@huawei.com>,
	Balbir Singh <bsingharora@gmail.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Alistair Popple <alistair@popple.id.au>,
	"Alastair D'Silva" <alastair@d-silva.org>,
	Gery Schneider <gery.schneider@fr.ibm.com>,
	Francois Richard <Francois.Richard@fr.ibm.com>,
	Jonathan Corbet <corbet@lwn.net>
Subject: Re: New Linux accelerators discussion list [was: Re: Fostering linux community collaboration on hardware accelerators]
Date: Tue, 17 Oct 2017 13:48:10 +0100	[thread overview]
Message-ID: <20171017134810.000049a9@huawei.com> (raw)
In-Reply-To: <a2031056-9ab4-cd03-1a18-f60d338ce090@au1.ibm.com>

On Tue, 17 Oct 2017 11:00:40 +1100
Andrew Donnellan <andrew.donnellan@au1.ibm.com> wrote:

> On 17/10/17 01:07, Jonathan Cameron wrote:
> > <snip>
> >   
> >>> So as ever with a linux community focusing on a particular topic, the
> >>> obvious solution is a mailing list. There are a number of options on how
> >>> do this.
> >>>
> >>> 1) Ask one of the industry bodies to host? Who?
> >>>
> >>> 2) Put together a compelling argument for linux-accelerators@vger.kernel.org
> >>> as probably the most generic location for such a list.  
> >>
> >> Happy to offer linux-accelerators@lists.ozlabs.org, which I can get set
> >> up immediately (and if we want patchwork, patchwork.ozlabs.org is
> >> available as always, no matter where the list is hosted).
> >>  
> > 
> > That would be great! Thanks for doing this. Much easier to find out what
> > such a list is useful for by the practical option of having a list and
> > see what people do with it.  
> 
> [+ LKML]
> 
> We now have a mailing list:
> 
>    List:      linux-accelerators@lists.ozlabs.org
>    Info:      https://lists.ozlabs.org/listinfo/linux-accelerators
>    Archives:  https://lists.ozlabs.org/pipermail/linux-accelerators
> 
> I haven't set up Patchwork as yet, but if people think that's a good 
> idea I can get that done too.
> 
> 
> Andrew
> 

Thanks Andrew.

A quick summary of initial thoughts on scope of this list for anyone
entering the discussion at this point.
Note it will hopefully evolve in whatever direction people find helpful.
This contains some suggestions not a barrier to wider scope!

There are a number of projects / applications involving what are
termed hardware accelerators.  These include:
* Traditional offload engines
	- Crypto, compression, media transcoding and similar accelerators
	- usecases including kTLS, Storage Encryption etc.
* Dynamic FPGA type accelerators
* ODP, DPDK and similar networking data plane - particularly dual stack
  solutions where the kernel 'plays nicely' with userspace drivers.
* AI Accelerators
* Shared Virtual Memory (SVM) bus systems including Open-CAPI, CCIX etc
* Fast data flow to/from userspace applications.

A number of existing project focus on these:
* Mainline kernel drivers
	- Numerous crypto drivers etc
	- Open-CAPI
* Various networking data plane activities
* VFIO based and similar userspace drivers
Hopefully this list can provide a broader forum where more general
questions are being considered.

The discussion that lead to this list was that a number of people would
like a general open forum on which to discuss ideas with scope beyond
simply one kernel subsystem or one particular userspace framework.

Topics might include
* RFCs and early reviews of new approaches.
* Similar hardware - who is trying to solve the same problems?
* What would we ideally want from new hardware iterations?
* Hardware description - the question of how to chose a particular
  crypto engine is very dependent on the particular data flows.
  Sometimes hardware accelerators don't actually help due to overheads.
  Understanding those barriers would be very useful.
* Upstream paths - blockers and how to work with the communities to
  overcome them.
* Fostering stronger userspace communities to allow these accelerators to 
  be easily harnessed.
	- A number of projects have been highlighted in this thread
	  OpenStack (cyborg project), openMP accelerator support 
* Robustness / security of userspace frameworks.
* Virtualisation of accelerators

Anyhow, this email was just meant to draw together some thoughts.
It will be interesting to see what the list actually gets used for :)

Jonathan

  reply	other threads:[~2017-10-17 12:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201710101132.v9ABUs28138304@mx0a-001b2d01.pphosted.com>
2017-10-12  5:22 ` Fostering linux community collaboration on hardware accelerators Andrew Donnellan
2017-10-12 13:31   ` Douglas Miller
2017-10-12 14:57     ` Jonathan Cameron
2017-10-12 15:48       ` Francois Ozog
2017-10-12 17:10         ` Douglas Miller
2017-10-16 14:07   ` Jonathan Cameron
2017-10-17  0:00     ` New Linux accelerators discussion list [was: Re: Fostering linux community collaboration on hardware accelerators] Andrew Donnellan
2017-10-17  0:00       ` Andrew Donnellan
2017-10-17 12:48       ` Jonathan Cameron [this message]
2017-10-17 12:48         ` Jonathan Cameron
2017-10-17 12:53         ` Jonathan Cameron
2017-10-17 12:53           ` Jonathan Cameron

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=20171017134810.000049a9@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Prasad.Athreya@cavium.com \
    --cc=Tirumalesh.Chalamarla@cavium.com \
    --cc=alex.williamson@redhat.com \
    --cc=andrew.donnellan@au1.ibm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arndbergmann@gmail.com \
    --cc=benh@kernel.crashing.org \
    --cc=broonie@kernel.org \
    --cc=bsingharora@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=fbarrat@linux.vnet.ibm.com \
    --cc=francois.ozog@linaro.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jcm@redhat.com \
    --cc=jean-philippe.brucker@arm.com \
    --cc=jic23@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=liguozhu@hisilicon.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.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.