[dpdk-dev] standardize device identification

Finn Christensen fc at napatech.com
Fri Jan 5 21:32:47 CET 2018


>-----Original Message-----
>From: Thomas Monjalon [mailto:thomas at monjalon.net]
>Sent: 5. januar 2018 16:34
>To: Finn Christensen <fc at napatech.com>
>Cc: dev at dpdk.org; Yuanhan Liu <yliu at fridaylinux.org>; Adrien Mazarguil
><adrien.mazarguil at 6wind.com>; Ciara Loftus <ciara.loftus at intel.com>; Kevin
>Traynor <ktraynor at redhat.com>; stephen at networkplumber.org;
>ferruh.yigit at intel.com
>Subject: Re: [dpdk-dev] standardize device identification
>
>05/01/2018 15:14, Finn Christensen:
>> From: Thomas Monjalon [mailto:thomas at monjalon.net]
>> >05/01/2018 12:09, Finn Christensen:
>> >> From: Thomas Monjalon
>> >>     Which property can help to distinguish Napatech ports?
>> >>     Can you use class=eth,dev_port=X ?
>> >>     The dev_port property will use /sys/class/net/DEV/dev_port on Linux.
>Is it
>> >>     OK for you?
>> >>
>> >> Actually, what we were thinking of was using the mac property in
>> >> the class category to distinguish our ports.
>> >> For instance:
>> >> -w bus=pci,id=0000:01:00.0/class=eth,mac=00:11:22:33:44:55
>> >> or simply:
>> >> -w class=eth,mac=00:11:22:33:44:55
>> >
>> >The problem with the mac property is that it cannot be used for
>> >white/blacklisting in DPDK because the MAC is not known before port
>> >initialization.
>> >
>>
>> Sure, that makes sense. I just for a minute thought that we could use
>> that mechanism to enable individual ports at startup also. We will
>> continue to use proprietary devargs passed by whiterlist to the PMD probe
>function.
>> What we needed was a way to select the individual ports, by using
>> rte_eth_dev_get_port_by_name().
>
>The whitelist will be replaced by this new syntax.
>And yes, you can have your own driver-specific property with this syntax.

That's fine.

>
>> >> We will not be able to support the dev_port property, that will not
>> >> work for
>> >us.
>> >> At least not for now.
>
>It leads to a totally different question:
>Can we discuss again how to integrate your driver in DPDK upstream?
>Please explain again your situation in a new thread.

Sure, I'll get back to you in a new thread. Thanks!



More information about the dev mailing list