From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iULRx0s5kYG0fncSoXSVqlEFHWSWMwx9a7YE6AYByQs=; b=qKjvPCd6rNNTCsci4czqQItIUIQceFibn6vxHhWqw4wmDGdHH0uW/OTuezVcNA3Rdw kTvRlU+GYGnGYth1p9AlR/uNIGzwI5k7yei1lKX8iUeiH15fW/HdYf9QD5Uc8dmGV/iD tH9PlAifdb58lT9SKT/zgFhqzPi1O3SY2WqjINxfZKuYd9mVa0kdtMD/xoIcesblmora KO6ppRo1ovIrJH5yUdfWGdgbPsuSkGA2P2/RwBWRM21m1vk0TpsXgzsxqQsLlplBVoh5 4poGK0Nv5MJK4SO3gffgDLKB4BoaNNQXqWFn4yPnjiI+LJaOs4xut73fJ7tHIfpcfw61 4poA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iULRx0s5kYG0fncSoXSVqlEFHWSWMwx9a7YE6AYByQs=; b=UDjlVkfJ/S667pGBmiYEPyZDFs33F38WnA5EFGvJeqOd+HOGcIKbGjLEFWwEtuVq1v HPNdqx1Teq4/rX577A0jHhzTS4IJbPLvTCUssO/aXZ1YwcgfFJN2KyeJ2wTuJZxuQ92y 0gKOCUdQl+cJqPVyvkB0MPjdHjPK9GNcX+px4lZCX4UM4Q7bHTYf4mSsVLewRJLfbO1P YhDMp6BYEnOMvW2ONv5E7Li9i7NMNlFQyFzTdnNsSzPrLIAf01qgoHk+YWK2NC0KOZxu OPe8z7pvtoWe5Li7aoYkA5AvbAX+BwBYf1YmdD0k0PbJLzZfL0XL5+zoKaN99orqw67W KniQ== X-Gm-Message-State: ALoCoQnWjBOt/7pcHoi/ROZ1m9b80HsTL1zVcKqlyS0IYBtRKa0mNzJifCK9vzlhwgJMH8b4fQJfKzJ78oq+M7d7KzZhaRreJtUnR4V/B0zRTFr+ZR9EGlY= X-Received: by 10.202.175.22 with SMTP id y22mr17507785oie.22.1453131954557; Mon, 18 Jan 2016 07:45:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.180.72 with HTTP; Mon, 18 Jan 2016 07:45:34 -0800 (PST) In-Reply-To: <569CFCA8.7010208@intel.com> References: <569CFCA8.7010208@intel.com> From: David Marchand Date: Mon, 18 Jan 2016 16:45:34 +0100 Message-ID: To: Declan Doherty Content-Type: text/plain; charset=UTF-8 Cc: "dev@dpdk.org" , Jan Viktorin Subject: Re: [dpdk-dev] Proposal for a big eal / ethdev cleanup X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 15:45:55 -0000 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