DPDK patches and discussions
 help / color / mirror / Atom feed
From: Alejandro Lucero <alejandro.lucero@netronome.com>
To: David Marchand <david.marchand@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v3 2/4] nfp-uio: new uio driver for netronome nfp6000 card
Date: Wed, 21 Oct 2015 15:39:55 +0100	[thread overview]
Message-ID: <CAD+H991+yGrX73qtBdBSKZpV2VryrKahVFXnzm6KPcFAMo70hg@mail.gmail.com> (raw)
In-Reply-To: <CALwxeUvXst4mnqYebi9Z-BqBV=rsERqk9kVSra6rVyBBv_gNyA@mail.gmail.com>

Hi David,

On Wed, Oct 21, 2015 at 6:24 AM, David Marchand <david.marchand@6wind.com>
wrote:

> Hello Alejandro,
>
> On Fri, Oct 16, 2015 at 12:45 PM, Alejandro.Lucero <
> alejandro.lucero@netronome.com> wrote:
>
>> From: "Alejandro.Lucero" <alejandro.lucero@netronome.com>
>>
>> This patch adds a new UIO kernel driver for supporting PCI VFs with
>> Netronome
>> nfp6000 card. Future PCI PF support will be based on changes to this
>> module.
>>
>> Signed-off-by: Alejandro.Lucero <alejandro.lucero@netronome.com>
>> Signed-off-by: Rolf.Neugebauer <rolf.neugebauer@netronome.com>
>>
>
> Please, can you elaborate on the need for (yet another) uio driver, rather
> than make igb_uio work with your hardware ?
>
>
We have two different needs not covered by igb_uio:

  - pci mask needs to be 40 bits instead of 64
  - some old kernel have buggy IOMMU with devices with pci masks as those
40 bits. This can be fixed just using kernel DMA API for a harmless dma
memory allocation. We have such a allocation along with the release in our
nfp_uio driver.

I thought to modify igb_uio adding a kernel param for setting another pci
mask than igb default one, but this is to leave to the user the right
initialisation.

But there is another more important reason for having a different driver:
future PF support. Our device is programmable with processing units and
functional units being configured by firmware code. Every part of the chip
is addressable from the host which is possible through a BSP kernel driver.
Device PCI BARs are not the same than network device (PF or VF) PCI BARs:
the latter is a subregion of the former. VFs subregions are easy to get
thanks to SRIOV. But in order to get the right subregions sizes and
addresses for the PF, special firmware symbols are needed. User space
programs can use the BSP through specific libraries but that requires
support from the BSP, or from another driver doing the same. So nfp_uio
will likely add that support.

I have been looking at the possibility of getting rid of nfp_uio. The fact
is our PMD can work without it, both for the PF and VF (not the PMD version
already submitted but one under development).  The PF support requires not
using UIO at all, because the device is attached to the BSP driver. The
only problem with this approach is we do not have support for interrupts,
what is not critical (I can see other PMDs not having support for Link
Status Changes) but we do not like it as programs can register callbacks
for these interrupts which would not work at all.

Interrupt support could be implemented in the BSP, doing the same UIO or
VFIO do, but this will require (minor) changes to DPDK for having another
intr_handle (not UIO, not VFIO). I do not know if other PMDs could also
make use of such a change but I guess that would help to accept those
changes.

Therefore, the easiest thing to do is to implement the PF support in the
nfp_uio by now.

I hope this explanation can help to justify nfp_uio.

Thanks


> Thanks.
>
> --
> David Marchand
>

  reply	other threads:[~2015-10-21 14:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-16 10:45 [dpdk-dev] [PATCH v3 0/4] support for netronome nfp-6xxx card Alejandro.Lucero
2015-10-16 10:45 ` [dpdk-dev] [PATCH v3 1/4] nfp: new poll mode driver for netronome nfp6000 card Alejandro.Lucero
2015-10-16 10:45 ` [dpdk-dev] [PATCH v3 2/4] nfp-uio: new uio " Alejandro.Lucero
2015-10-21  5:24   ` David Marchand
2015-10-21 14:39     ` Alejandro Lucero [this message]
2015-10-21 15:25       ` Thomas Monjalon
2015-10-21 15:57         ` Alejandro Lucero
2015-10-21 16:03           ` Thomas Monjalon
2015-10-21 19:40             ` Alejandro Lucero
2015-10-22 11:46               ` Alejandro Lucero
2015-10-16 10:45 ` [dpdk-dev] [PATCH v3 3/4] doc: add netronome nfp6000 guide Alejandro.Lucero
2015-10-16 10:45 ` [dpdk-dev] [PATCH v3 4/4] tools: add support for nfp_uio Alejandro.Lucero
2015-10-19 19:17 ` [dpdk-dev] [PATCH v3 0/4] support for netronome nfp-6xxx card Mcnamara, John

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=CAD+H991+yGrX73qtBdBSKZpV2VryrKahVFXnzm6KPcFAMo70hg@mail.gmail.com \
    --to=alejandro.lucero@netronome.com \
    --cc=david.marchand@6wind.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).