On Sun, 18 Sep 2016 16:56:54 +0800
Jianbo Liu [off-list ref] wrote:

On 18 September 2016 at 15:22, Jan Viktorin [off-list ref] wrote:

quoted

On Sun, 18 Sep 2016 13:58:50 +0800
Jianbo Liu [off-list ref] wrote:
 

quoted

On 9 September 2016 at 16:43, Shreyansh Jain [off-list ref] wrote:  

quoted

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.  

[...]
 

quoted

quoted

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....

quoted

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.
 

quoted

quoted

   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"?
 

quoted

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?

First, this is not an ARM-specific feature. Consider any MAC connected to
the processor via some on-chip bus. In the world of ARM, it is usually
a kind of AMBA bus. I think, the Intel Xeon with FPGA would be a
good non-ARM example. Here they provide the Quick Path bus (but I don't
know the details). So, you cannot access such device as PCI. It is
usually not possible to distinguish the bus type easily (Linux calls
this a platform device).

So, an rte_soc_device denotes a device integrated on the chip
(SoC, System-on-Chip). Such devices can have a lower access latency
because they are closer to the processor.

So, if you have a server system driver by a SoC with integrated MACs
(no PCI-E involved), there is no way how to access them from DPDK. An
rte_soc_device represents such devices and provides a way how to access
them from DPDK. That is the goal...

You can have an embedded device (router, switch, monitoring device,
NAT, firewall, anything in a "small box" with high throughput demands)
that perfectly fits into this SoC framework because it would be usually
based on some SoC (ARM, ARM64, ...).

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. :)

No, you cannot use it for PCI devices, don't worry. There should be no
PCI facilities like access to BARs :). But, I think I got your point.

It seems to be generalized because there is no real standard in this
area. Any vendor of SoC can provide her custom on-chip bus. The
original idea was to build on top of the platform_device from Linux
which hides this information from you (unless there is some bus-specific
DMA which we must handle in the DPDK PMD).

We could provide an rte_amba_device instead but there is no advantage in
this. The amba bus is defined on the RTL level and not on the software
level (no BARs, no device discovery). And there are other buses working
in a similar way.

Thanks!
Jianbo

-- 
  Jan Viktorin                E-mail: Viktorin@RehiveTech.com
  System Architect            Web:    www.RehiveTech.com
  RehiveTech
  Brno, Czech Republic