[dpdk-dev] [PATCH 3/7] eal: move virtual device probing into a bus
Wiles, Keith
keith.wiles at intel.com
Wed Feb 15 18:22:05 CET 2017
> On Feb 15, 2017, at 11:10 AM, Wiles, Keith <keith.wiles at intel.com> wrote:
>
>
>> On Feb 15, 2017, at 11:06 AM, Jan Blunck <jblunck at infradead.org> wrote:
>>
>> On Wed, Feb 15, 2017 at 3:22 PM, Wiles, Keith <keith.wiles at intel.com> wrote:
>>>
>>>> On Feb 15, 2017, at 8:15 AM, Shreyansh Jain <shreyansh.jain at nxp.com> wrote:
>>>>
>>>>
>>>> Just ignore this comment - I am misunderstood something.
>>>>
>>>> But another question: Is there specific reason VDEV should be registered/scanned *after* other devices? Is there some specific problem if we do otherwise? (I think this is should be done, but I don't have a specific reason).
>>>
>>
>> Just for context: the vdev's are probed after the physical devices
>> because of commit f4ce209a ("eal: postpone vdev initialization").
>>
>>> Does the bonding driver which uses physical devices need to be registered after physical ones? In Pktgen I noticed the vdev after the physical ports and I could not blacklist them as the bonding driver needed them, which caused the bonding ports to have a greater port number. In the case of pktgen the bonding ports were up around 8 or 10 and caused the display to not show the bonding ports. This is really just a usability problem for the developer using Pktgen. I would like to see the vdev devices first, but as long as the drivers (like bonding) are fine with them being first.
>>>
>>
>> The bonding devargs might specify slaves that get attached during
>> device probe. If the referenced devices are physical interfaces we
>> need to probe them first. This is really a chicken-egg-problem.
>>
>> Maybe you could improve the usability in your case and sort the
>> virtual devices first or even hide enslaved ports?
>
> The port numbering comes from DPDK and I use that directly, was trying to avoid a translation of real port to Pktgen port :-(
>
> Regards,
> Keith
>
Looking at the bonding driver it does not attempt to access the physical ports until bond_ethdev_configure call (I believe). This means the vdev devices should be following the same flow and moving them to before the physical probes would be fine, right?
Regards,
Keith
More information about the dev
mailing list