[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