[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL

Jianbo Liu jianbo.liu at linaro.org
Sun Sep 18 10:56:54 CEST 2016


On 18 September 2016 at 15:22, Jan Viktorin <viktorin at rehivetech.com> wrote:
> On Sun, 18 Sep 2016 13:58:50 +0800
> Jianbo Liu <jianbo.liu at linaro.org> wrote:
>
>> On 9 September 2016 at 16:43, Shreyansh Jain <shreyansh.jain at nxp.com> 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


More information about the dev mailing list