[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
Jan Viktorin
viktorin at rehivetech.com
Fri May 6 13:46:49 CEST 2016
Hello,
On Fri, 6 May 2016 10:26:45 +0100
Declan Doherty <declan.doherty at intel.com> wrote:
> On 20/04/16 13:41, Jan Viktorin wrote:
> > On Wed, 20 Apr 2016 13:05:24 +0100
> > Bruce Richardson <bruce.richardson at intel.com> wrote:
> >
> >> On Wed, Apr 20, 2016 at 01:44:00PM +0200, David Marchand wrote:
> >>> Following discussions with Jan [1] and some cleanup I started on pci code,
> >>> here is a patchset that reworks pdev drivers registration and hotplug api.
> >>>
[...]
>
> The changes look good to me, nice to remove some of the duplication
> ethdev/cryptodev.
Yes, I like them too.
>
> Regarding enabling hot-plugging for crypto devices it looks like it
> should be possible now to implement a mostly generic device
> attach/detach functions, just with a simple wrapper to identify a
> specific crypto or ethdev device structure. Do you have plans to do
> this? If not, I can have a look as I would like to enable hot-plugging
Yes. But, first I focused on the new SoC infra to find out what can be
shared by the generic layer. I've got almost ready patch series, I will
post it soon to the mailing list. It does not introduce the generic
rte_driver/device yet, however, it shows that with
[PATCH v2 00/17] prepare for rte_device / rte_driver
it is now possible to do it quite easily.
However, what I am not very sure about is whether we separate
management of the PCI devices and SoC devices and any other such
devices. Or whether we should have a single list for all.
Second, the rte_driver must be removed from DPDK as it conflicts
with the new rte_driver structure to be introduced. This should include
removing of pmd_type, I think. I've expected that David M. will continue
with v3 to move on (otherwise we'll get some merge conflicts I'd like to
avoid).
Another thing, there are structs like rte_pci_addr (etc.) which must
(but I am not so sure) be probably generalized as well.
And, devargs...
Regards
Jan
> for crypto devices, without duplicating things that still reside in the
> ethdev library at the moment.
>
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
More information about the dev
mailing list