2016-05-13 09:38, Alejandro Lucero:
> On Thu, May 12, 2016 at 4:41 PM, Jan Viktorin <viktorin at rehivetech.com>
> > Alejandro Lucero <alejandro.lucero at netronome.com> wrote:
> > > On Thu, May 12, 2016 at 3:52 PM, Jan Viktorin <viktorin at rehivetech.com>
> > > > "Alejandro.Lucero" <alejandro.lucero at netronome.com> wrote:
> > > > > - New dma_mask field in rte_eth_dev_data.
> > > > > - If PMD sets device dma_mask, call to check hugepages within
> > > >
> > > > I think that one of the purposes of DPDK is to support DMA transfers
> > > > in userspace. In other words, I can see no reason to support dma_mask
> > > > at the ethdev level only.
> > > >
> > > > The limitation is a device limitation so I can not see a better place
> > for
> > > adding the device dma mask.
> >
> > That's what I've meant. It is a _device_ limitation. The ethdev is a
> > wrapper
> > around the rte_pci_device. The ethdev just extends semantics of the
> > generic device.
> > However, all DPDK devices are expected to be DMA-capable.
> >
> > If you get a pointer to the ethdev, you get a pointer to the
> > rte_pci_device as well
> > (1 more level of dereference but we are not on the fast path here, so it's
> > unimportant).
> >
> > Consider the cryptodev. If cryptodev has some DMA mask requirements we can
> > support it
> > in the generic place, i.e. rte_pci_device and not rte_ethdev because the
> > cryptodev
> > is not an ethdev.
> >
> Ok. I was wrongly assuming we had just ethdevs, with the ethdev being the
> generic and rte_pci_device being a type of ethdev.
>
> I can add the dma mask to the rte_pci_dev. The extra level of dereference
> is not a problem as long as we do not use that dma mask for a more complex
> allocation API (more about this later).
>
> If I understand it right, work is in progress for adding a rte_device. I
> can not see a problem with adding dma mask to the rte_device struct either.
>
> > > > We should consider adding this to the generic struct rte_device
> > > > (currently rte_pci_device). Thomas?
Yes
This patchset could be split in 2 discussions:
- ability to restrict the physical address range of requested memory,
see the memory allocation rework discussion:
http://dpdk.org/ml/archives/dev/2016-April/037444.html
- DMA range capability in a device, to be done on top of the EAL/device
rework in progress.
This feature is a good candidate for the roadmap of 16.11.
