DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Trahe, Fiona" <fiona.trahe@intel.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Cc: "Trahe, Fiona" <fiona.trahe@intel.com>
Subject: [dpdk-dev] Sharing a PCI device between multiple PMDs
Date: Thu, 28 Sep 2017 13:50:34 +0000	[thread overview]
Message-ID: <348A99DA5F5B7549AA880327E580B4358929C850@IRSMSX101.ger.corp.intel.com> (raw)

Thanks to all for your feedback on above topic at the DPDK userspace summit.

I've summarised the feedback below - left out names as I'm paraphrasing and don't want to misrepresent anyone.


*       One vendor has tried same approach, ran into similar problems with knock-on impacts to eth-dev, has instead worked around by not sharing the device, instead allocating different VFs to different PMDs. Needs a modification of whitelist functionality, maybe extra cmdline parameters to do this.

*       Another vendor also tried similar, wanting to create a device per port. Had limitations with interrupts. Worked around by handling within one PMD instead of a generic solution within EAL.

*       Several suggestions related to resolving in other ways within EAL, e.g.

o   any driver which can share a device could append a new device to the end of the bus device-list during its probe, in effect it takes the resources it needs, the remainder of the device is appended to the device-list where it can be found by another driver. Questions re where the shared data could be stored and how attach/detach would work.

o   a variant of this could be a master driver claims the PCI device - spawning multiple slave devices which are then claimed by service-specific drivers. Probably easier to manage the attach/detach and shared data with this approach.

o   create a new bus type, one PCI device driver could create sub-devices on a sub-bus - these devices could be shared as the bus would have its own probe/remove fns and type-specific structs.

*       Stick with one PMD per device and hide the sharing of multiple functions within this PMD.

Next steps:
Though this does seem to be a generic problem, I'm not now planning to push a patch relating to this.
Instead to work on one PMD claiming one device, but being able to implement multiple APIs. So an application could see 2 independent devices each servicing a different API while only one PMD implements them both using the same underlying hardware. I have ideas now for how this can work, if it does, then there's no need for separate drivers for the same PCI device.


Regards,
Fiona

                 reply	other threads:[~2017-09-28 13:50 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=348A99DA5F5B7549AA880327E580B4358929C850@IRSMSX101.ger.corp.intel.com \
    --to=fiona.trahe@intel.com \
    --cc=dev@dpdk.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).