[dpdk-dev] [PATCH v1 28/28] ether: support SoC device/driver

Shreyansh jain shreyansh.jain at nxp.com
Thu Jul 7 12:29:41 CEST 2016


Hi Jan,

Apologies for delay in my response.

On Tuesday 05 July 2016 10:46 AM, Jan Viktorin wrote:
> Hello Shreyansh,
>>> On Monday 04 July 2016 08:06 PM, Jan Viktorin wrote:
>>> On Mon, 4 Jul 2016 19:57:18 +0530
>>> Shreyansh jain <shreyansh.jain at nxp.com> wrote:
>>>
>>> [...]
>>>
>>>>>>> @@ -1431,7 +1524,7 @@ >rte_eth_dev_info_get(uint8_t port_id, struct >rte_eth_dev_info *dev_info)
>>>>>>>
>>>>>>> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->>dev_infos_get);
>>>>>>> (*dev->dev_ops->dev_infos_get)(dev, dev_info);
>>>>>>> -	dev_info->pci_dev = dev->pci_dev;
>>>>>>> +	dev_info->soc_dev = dev->soc_dev; 
>>>>>>
>>>>>> I think both the members, pci_dev and soc_dev, should be updated by this call.
>>>>>> Is there some specific reason why soc_dev is the only one which is getting updated? 
>>>>>
>>>>> Yes, looks like a mistake. Thanks! And sorry for delayed reply. 
>>>>
>>>> No problems - thanks for confirmation.
>>>> I have gone through almost complete series and as and when you rebase it, it would have my ACK.
>>>
>>> OK, thanks. That's what I am playing with right now. I've rebased on v3 of this patch. There will
>>> be some more tests in my v2.
>>>
>>>> rte_driver patchset which I sent last are broken - I will publish an updated version very soon.
>>>
>>> I am surprised that you've changed the args to RTE_EAL_PCI_REGISTER... Are you sure about this step?
>>> I wrote that I'll change it myself for v2 for SoC to accept name and pointer as it was originally for PCI...
>>
>> Really? Then probably I understood it wrong. I don't have any issues with the first one as well but just for slightly cleaner approach I thought of going with your suggest (or, suggestion as understood by me).
> ‎>
>> Anyways the patch is broken and doesn't apply on master. I will push a new version (with revert EAL_PCI_REGISTER arguments) within today.
> 
> Ok. I am away for few days this week but I will continue as soon as possible on the soc patchset and also on the rte_device/driver issue. We have to cut this as soon as possible. I think the best would be to post a small patchset on top of this one introducing the change.

I am anyway working on a driver for NXP's SoC platform which I am basing over rte_device + SoC patchset.
I plan to release a draft of this driver soon. It might help validate both the patchsets in a limited manner.

> 
> I think, there should be a single list of rte_device and a list for rte_driver while preserving lists for each infra, so also rte_pci_device would have a separate list. Then, it's possible to iterate over all PCI devices easily and iterate over all devices generically at the same time.

I have similar understanding. Separate pci/soc lists, and unified rte_driver and rte_device lists. This, in my opinion, would help keep the interfaces clean (free of unnecessary checks).

> 
> What I am not sure about are addr and id things. It's quite difficult to generalize them. The addr needs a conpare function but how to compare pci addr to another type of addr? Do we need this? If so, I'll work on this.

I am not sure why we need to compare the PCI addresses with non-PCI (or any other, SoC) address set? Can you elaborate?

> 
> Another thing - resources. Do we want to have a kind of a generic rte_resource instead of rte_pci_resource? I think this is clearly possible. I am about to do this.

The idea sounds good but I don't know whether it would be feasible or not. My understanding is that resources have special characteristics. Generalizing them would involve creating opaque objects in rte_resource{..} which in turn beats the purpose of generalization.

Probably, I will wait for your next patchset version to understand your approach.

> 
> I am afraid we are unable to change devargs significantly in this release :/ (due to time and lack of a discussion here).‎ What I really like to see is the virtual device conversion and pmd_type removal. Are you able to look at this?

pmd_type removal is my todo as well. This would anyway impact the vdevs.
I haven't given devargs much thought, yet.

> 
> Any other objections?

I was looking at various discussions [1],[2] that have happened in past. From that, the summary I have is:
 1) Generalize devices to rte_device/rte_driver
  `-- Cleaner interfaces/difference for 'bus', 'driver' and 'device'
  `-- Moving the init/deinit functions into rte_device/rte_driver layer
  `-- hierarchical device structure (as explained by David in [1]) 
 2) Do away with device type specific initializations (registrations)
  `-- No more pdev/vdev distinction
  `-- standardizing devargs for accepting device specific strings.
 3) Hotplug support

Most of work of (1) David has already done. What remains is completing (2) and probably (3) which I haven't verified yet.

[1] http://dpdk.org/ml/archives/dev/2016-January/031390.html
[2] http://dpdk.org/ml/archives/dev/2016-January/030975.html

> 
> Jan Viktorin
> RehiveTech
> Sent from a mobile device‎
> 
>>>
>>> Jan
>>>  
>>
>> -
>> Shreyansh
> 

-
Shreyansh
 



More information about the dev mailing list