Re: Proposal for a big eal / ethdev cleanup

[David Marchand <david.marchand@6wind.com>]

Hello Declan,

On Mon, Jan 18, 2016 at 3:54 PM, Declan Doherty
<declan.doherty@intel.com> wrote:
> In your proposal above, having an bus type enumeration in the rte_device
> which specifies the bus type might be simpler than having to parse a
> specific name formatting.

This is not simpler.
This is useless afaics.

"upper" / "functional" layer should not rely on the "lower" /
"physical" layer information.

Your crypto device should be described through a struct with crypto
ops functions.
When registering the device, the (whatever bus) driver should register
a crypto device with its own crypto ops.

The only place I can think of, where parsing a resource name would
have an interest, is when crossing borders dpdk <-> user application.
This is why I proposed a naming convention to identify the devices.


> One thing that we are working on at the moment and it will affect your
> proposed solution above quite a lot is the ability to support devices with
> share-able buses in DPDK, we will have a RFC for this proposal in the next
> few days but I'll give a quick overview now. The Quick Assist device which
> we currently support a symmetric crypto cryptodev PMD for in DPDK is a
> mufti-function device, in that it supports symmetric and asymmetric crypto
> and compression functionality. These features are supported from a single
> device instance through different hardware queues. We want to provide each
> service through as a separate dpdk device but with and underlying shared bus
> (in our case PCI), this way a device/queue will only provide 1 service type.
> What we are going to propose is to allow a rte_pci_device to be shared my
> multiple pdevs, to do this we would register multiple drivers against the
> same pci_id and with a small modification to the EAL
> rte_eal_pci_probe_all()/ rte_eal_pci_probe() functions we create a device
> instance for each matched driver as long as the diver has a share-able flag.

>From the description you give, it sounds to me you want to expose two
crypto devices that share the same pci device but I can't see where my
proposed solution can not work.
eal finds one pci device, associates it to one pci driver which then
creates two different crypto devices (with their own specific logic).
Those crypto devices references a generic rte_device (which happens to
be a pci device) referencing a generic rte_driver.

So to me, this is pure specific driver/crypto stuff, nothing to do in eal.

What did I miss ?


Regards,
-- 
David Marchand