From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Marchand Subject: Re: Proposal for a big eal / ethdev cleanup Date: Mon, 18 Jan 2016 16:45:34 +0100 Message-ID: References: <569CFCA8.7010208@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: "dev@dpdk.org" , Jan Viktorin To: Declan Doherty Return-path: Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by dpdk.org (Postfix) with ESMTP id 38A1B8D3A for ; Mon, 18 Jan 2016 16:45:55 +0100 (CET) Received: by mail-oi0-f53.google.com with SMTP id k206so177764645oia.1 for ; Mon, 18 Jan 2016 07:45:55 -0800 (PST) In-Reply-To: <569CFCA8.7010208@intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hello Declan, On Mon, Jan 18, 2016 at 3:54 PM, Declan Doherty 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