From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by dpdk.org (Postfix) with ESMTP id 50026378E for ; Sun, 18 Sep 2016 10:56:55 +0200 (CEST) Received: by mail-yw0-f179.google.com with SMTP id i129so115129103ywb.0 for ; Sun, 18 Sep 2016 01:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U8rDU6g6VsnjPhgxUxw16GJyO5NIgVZ9xZSvyhuiYFc=; b=bz0K9r4oOOfRMx9CU7X6mcoqjou7IMY9YIH4iMVX0fEZnMFJ5ju1q52EFlM8q0ZPMQ FQVjRMdD3p7A/To8auZJih0j5Ip23JQw5PDyF4zt2JmP2czpi0l86JEx6tqD6e6WX9PB Aqwr/ip3O52JHVkJAnRLGCPaZSUO+4UbcBdGU= 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; bh=U8rDU6g6VsnjPhgxUxw16GJyO5NIgVZ9xZSvyhuiYFc=; b=AppXJfzhN7QzlIIjxPx47IMKWEpNAciXxYLTEybmtP4FZ8q3uxYDcqrJrXHEvm0FaS FP6kLeRHdBJV1SspDEI6OsMHE1pY1UIihs+HlcobNVtxRRcRpKcZLslm+7fv32EPwzLl w4Fc+LF/W37Ht5O63G5N1ONP4p3QnKJvlW1juwS4DuY65aByAeBfxUUHD/k2ASaKQwuH uaO1DKq6hUdDSDKT+fWNQkipzJCSLM0Pl3PxeeoHHTKXFFh8KB51yhaVPOy/GYg8unS+ BEUfOiIsnGSvQ4EmONIhUHyzCcmx7MAeg15CAxV/ZdueguMXosbyS/6U63nBUpzOC5v3 QOTg== X-Gm-Message-State: AE9vXwMdZcs75tOxwwv5dOd2QbfCk5IlN5d9+78zCiUXlnTgyEGDjOefyJ2s5ELTaHy2nQUVxy9Y1I3B/oc+cbWj X-Received: by 10.129.128.3 with SMTP id q3mr20113113ywf.290.1474189014750; Sun, 18 Sep 2016 01:56:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.25.6 with HTTP; Sun, 18 Sep 2016 01:56:54 -0700 (PDT) In-Reply-To: <20160918092220.062b95bf@jvn> References: <1451682326-5834-1-git-send-email-viktorin@rehivetech.com> <1473410639-10367-1-git-send-email-shreyansh.jain@nxp.com> <20160918092220.062b95bf@jvn> From: Jianbo Liu Date: Sun, 18 Sep 2016 16:56:54 +0800 Message-ID: To: Jan Viktorin Cc: Shreyansh Jain , dev@dpdk.org, Hemant Agrawal Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL 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: Sun, 18 Sep 2016 08:56:55 -0000 On 18 September 2016 at 15:22, Jan Viktorin wrote: > On Sun, 18 Sep 2016 13:58:50 +0800 > Jianbo Liu wrote: > >> On 9 September 2016 at 16:43, Shreyansh Jain wrote: >> > Introduction: >> > ============= >> > >> > This patch set is direct derivative of Jan's original series [1],[2]. >> > >> > - As this deviates substantially from original series, if need be I can >> > post it as a separate patch rather than v2. Please suggest. >> > - Also, there are comments on original v1 ([4]) which are _not_ >> > incorporated in this series as they refer to section no more in new >> > version. >> > - This v3 version is based on the rte_driver/device patchset v9 [10]. >> > That series introduced device structures (rte_driver/rte_device) >> > generalizing devices into PCI, VDEV, XXX. For the purpose of this >> > patchset, XXX=>SOC. > > [...] > >> > >> > 5) Design considerations that are different from PCI: >> > - Each driver implements its own scan and match function. PCI uses the BDF >> > format to read the device from sysfs, but this _may_not_ be a case for a >> > SoC ethernet device. >> > = This is an important change from initial proposal by Jan in [2]. Unlike >> > his attempt to use /sys/bus/platform, this patch relies on the PMD to >> >> It could be many redundant code if Each PMD driver has the scan >> function if its own. >> I think Jan's implementation is common to many platform drivers. > > I personally can find a use case for having a custom scan function. > However, we should at least provide a default implementation. Probably, > both the scan and match functions should be used to _override_ a default > behaviour. So, only drivers that require to scan devices in a specific > way would provide a custom function for this. > And for each platform/product.... > I agree, that this can sometimes lead to code duplication. Moreover, it > opens door for a very non-standard, unsecure and wrong-by-design > approaches. I'd like more to provide one or more scan implementations > in EAL and do not put this responsibility on PMDs. > >> >> > detect the devices. This is because SoC may require specific or >> > additional info for device detection. Further, SoC may have embedded > > Can you provide an example for "additional info for device detection"? > >> >> Can you give us more precise definition about SoC driver? Does it >> include the driver in ARM server? > > I am sorry but I don't understand this question. > > What you mean by a "driver in ARM server"? Do you mean a kernel driver? > > There is no "SoC driver" in the text so what definition are asking for? > This patchset introduces rte_soc_driver, which is inheriting from rte_driver. I want to know what devices can use this SoC driver/device framework. Is it for the devices from ARM servers, or embedded systems of different vendors? And this framework is too generalized, if we don't try to understand "soc" in rte_soc_driver, we can use it for PCI devices. :) Thanks! Jianbo