[dpdk-dev] usertools/dpdk-devbind.py: add support for wind river avp device
Checks
Commit Message
Signed-off-by: Xiaohua Zhang <xiaohua.zhang@windriver.com>
---
usertools/dpdk-devbind.py | 8 ++++++++
1 file changed, 8 insertions(+)
Comments
On 11-Feb-18 9:52 AM, Xiaohua Zhang wrote:
> Signed-off-by: Xiaohua Zhang <xiaohua.zhang@windriver.com>
> ---
> usertools/dpdk-devbind.py | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
> index 18d9386..f488318 100755
> --- a/usertools/dpdk-devbind.py
> +++ b/usertools/dpdk-devbind.py
> @@ -22,11 +22,14 @@
> 'SVendor': None, 'SDevice': None}
> cavium_pkx = {'Class': '08', 'Vendor': '177d', 'Device': 'a0dd,a049',
> 'SVendor': None, 'SDevice': None}
> +avp_vnic = {'Class': '05', 'Vendor': '1af4', 'Device': '1110',
> + 'SVendor': None, 'SDevice': None}
>
> network_devices = [network_class, cavium_pkx]
> crypto_devices = [encryption_class, intel_processor_class]
> eventdev_devices = [cavium_sso]
> mempool_devices = [cavium_fpa]
> +avp_devices = [avp_vnic]
>
> # global dict ethernet devices present. Dictionary indexed by PCI address.
> # Each device within this is itself a dictionary of device properties
> @@ -565,6 +568,9 @@ def show_status():
> if status_dev == "mempool" or status_dev == "all":
> show_device_status(mempool_devices, "Mempool")
>
> + if status_dev == "avp" or status_dev == "all":
> + show_device_status(avp_devices, "AVP")
> +
> def parse_args():
> '''Parses the command-line arguments given by the user and takes the
> appropriate action for each'''
> @@ -638,6 +644,7 @@ def do_arg_actions():
> get_device_details(crypto_devices)
> get_device_details(eventdev_devices)
> get_device_details(mempool_devices)
> + get_device_details(avp_devices)
> show_status()
>
>
> @@ -650,6 +657,7 @@ def main():
> get_device_details(crypto_devices)
> get_device_details(eventdev_devices)
> get_device_details(mempool_devices)
> + get_device_details(avp_devices)
> do_arg_actions()
>
> if __name__ == "__main__":
>
Is there any particular reason why this device appears in its own
category, rather than being added to one of the existing device classes?
I'm not familiar with AVP but it looks like it's a NIC, so shouldn't it
be in network_devices category?
Hi Anatoly,
AVP is a virtual NIC type, so you are right.
When using the AVP device, you will see the following information from lspci (example).
Slot: 0000:00:05.0
Class: Unclassified device [00ff]
Vendor: Red Hat, Inc [1af4]
Device: Virtio memory balloon [1002]
SVendor: Red Hat, Inc [1af4]
SDevice: Device [0005]
PhySlot: 5
Driver: virtio-pci
It is a little different with the standard "Ethernet" controller, such as "Class: Ethernet controller [0200]".
Theoretically, the AVP is a memory based device. That's the reason, I put it as separate catalog.
BR.
Xiaohua Zhang
-----Original Message-----
From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
Sent: Monday, February 12, 2018 6:13 PM
To: Zhang, Xiaohua; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] usertools/dpdk-devbind.py: add support for wind river avp device
On 11-Feb-18 9:52 AM, Xiaohua Zhang wrote:
> Signed-off-by: Xiaohua Zhang <xiaohua.zhang@windriver.com>
> ---
> usertools/dpdk-devbind.py | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
> index 18d9386..f488318 100755
> --- a/usertools/dpdk-devbind.py
> +++ b/usertools/dpdk-devbind.py
> @@ -22,11 +22,14 @@
> 'SVendor': None, 'SDevice': None}
> cavium_pkx = {'Class': '08', 'Vendor': '177d', 'Device': 'a0dd,a049',
> 'SVendor': None, 'SDevice': None}
> +avp_vnic = {'Class': '05', 'Vendor': '1af4', 'Device': '1110',
> + 'SVendor': None, 'SDevice': None}
>
> network_devices = [network_class, cavium_pkx]
> crypto_devices = [encryption_class, intel_processor_class]
> eventdev_devices = [cavium_sso]
> mempool_devices = [cavium_fpa]
> +avp_devices = [avp_vnic]
>
> # global dict ethernet devices present. Dictionary indexed by PCI address.
> # Each device within this is itself a dictionary of device
> properties @@ -565,6 +568,9 @@ def show_status():
> if status_dev == "mempool" or status_dev == "all":
> show_device_status(mempool_devices, "Mempool")
>
> + if status_dev == "avp" or status_dev == "all":
> + show_device_status(avp_devices, "AVP")
> +
> def parse_args():
> '''Parses the command-line arguments given by the user and takes the
> appropriate action for each'''
> @@ -638,6 +644,7 @@ def do_arg_actions():
> get_device_details(crypto_devices)
> get_device_details(eventdev_devices)
> get_device_details(mempool_devices)
> + get_device_details(avp_devices)
> show_status()
>
>
> @@ -650,6 +657,7 @@ def main():
> get_device_details(crypto_devices)
> get_device_details(eventdev_devices)
> get_device_details(mempool_devices)
> + get_device_details(avp_devices)
> do_arg_actions()
>
> if __name__ == "__main__":
>
Is there any particular reason why this device appears in its own category, rather than being added to one of the existing device classes?
I'm not familiar with AVP but it looks like it's a NIC, so shouldn't it be in network_devices category?
--
Thanks,
Anatoly
On 13-Feb-18 1:43 AM, Zhang, Xiaohua wrote:
> Hi Anatoly,
> AVP is a virtual NIC type, so you are right.
>
> When using the AVP device, you will see the following information from lspci (example).
> Slot: 0000:00:05.0
> Class: Unclassified device [00ff]
> Vendor: Red Hat, Inc [1af4]
> Device: Virtio memory balloon [1002]
> SVendor: Red Hat, Inc [1af4]
> SDevice: Device [0005]
> PhySlot: 5
> Driver: virtio-pci
>
> It is a little different with the standard "Ethernet" controller, such as "Class: Ethernet controller [0200]".
> Theoretically, the AVP is a memory based device. That's the reason, I put it as separate catalog.
>
OK, fair enough. Is there any way we can make this category
not-WindRiver AVP specific? Are there other similar devices out there
that could potentially fit into this category?
>
> BR.
> Xiaohua Zhang
>
> -----Original Message-----
<snip>
>
> Is there any particular reason why this device appears in its own category, rather than being added to one of the existing device classes?
> I'm not familiar with AVP but it looks like it's a NIC, so shouldn't it be in network_devices category?
>
> --
> Thanks,
> Anatoly
>
On 2/13/2018 10:06 AM, Burakov, Anatoly wrote:
> On 13-Feb-18 1:43 AM, Zhang, Xiaohua wrote:
>> Hi Anatoly,
>> AVP is a virtual NIC type, so you are right.
>>
>> When using the AVP device, you will see the following information from lspci (example).
>> Slot: 0000:00:05.0
>> Class: Unclassified device [00ff]
>> Vendor: Red Hat, Inc [1af4]
>> Device: Virtio memory balloon [1002]
>> SVendor: Red Hat, Inc [1af4]
>> SDevice: Device [0005]
>> PhySlot: 5
>> Driver: virtio-pci
>>
>> It is a little different with the standard "Ethernet" controller, such as "Class: Ethernet controller [0200]".
>> Theoretically, the AVP is a memory based device. That's the reason, I put it as separate catalog.
>>
>
> OK, fair enough. Is there any way we can make this category
> not-WindRiver AVP specific? Are there other similar devices out there
> that could potentially fit into this category?
Can we call it "memory_devices" instead of "avp_devices" ?
>
>>
>> BR.
>> Xiaohua Zhang
>>
>> -----Original Message-----
>
> <snip>
>
>>
>> Is there any particular reason why this device appears in its own category, rather than being added to one of the existing device classes?
>> I'm not familiar with AVP but it looks like it's a NIC, so shouldn't it be in network_devices category?
>>
>> --
>> Thanks,
>> Anatoly
>>
>
>
Hi Yigit and Anantoly,
I checked the nics-17.11.pdf, the following is description:
"The Accelerated Virtual Port (AVP) device is a shared memory based device only available
on virtualization platforms from Wind River Systems. The Wind River Systems virtualization
platform currently uses QEMU/KVM as its hypervisor and as such provides support for all of
the QEMU supported virtual and/or emulated devices (e.g., virtio, e1000, etc.). The platform
offers the virtio device type as the default device when launching a virtual machine or creating
a virtual machine port. The AVP device is a specialized device available to customers that
require increased throughput and decreased latency to meet the demands of their performance
focused applications."
I am afraid just "memory_device" will have some misunderstanding.
Could we put it as "avp device (shared memory based)"?
BR.
Xiaohua Zhang
-----Original Message-----
From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
Sent: Tuesday, February 13, 2018 7:07 PM
To: BURAKOV, ANATOLY; Zhang, Xiaohua; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] usertools/dpdk-devbind.py: add support for wind river avp device
On 2/13/2018 10:06 AM, Burakov, Anatoly wrote:
> On 13-Feb-18 1:43 AM, Zhang, Xiaohua wrote:
>> Hi Anatoly,
>> AVP is a virtual NIC type, so you are right.
>>
>> When using the AVP device, you will see the following information from lspci (example).
>> Slot: 0000:00:05.0
>> Class: Unclassified device [00ff]
>> Vendor: Red Hat, Inc [1af4]
>> Device: Virtio memory balloon [1002]
>> SVendor: Red Hat, Inc [1af4]
>> SDevice: Device [0005]
>> PhySlot: 5
>> Driver: virtio-pci
>>
>> It is a little different with the standard "Ethernet" controller, such as "Class: Ethernet controller [0200]".
>> Theoretically, the AVP is a memory based device. That's the reason, I put it as separate catalog.
>>
>
> OK, fair enough. Is there any way we can make this category
> not-WindRiver AVP specific? Are there other similar devices out there
> that could potentially fit into this category?
Can we call it "memory_devices" instead of "avp_devices" ?
>
>>
>> BR.
>> Xiaohua Zhang
>>
>> -----Original Message-----
>
> <snip>
>
>>
>> Is there any particular reason why this device appears in its own category, rather than being added to one of the existing device classes?
>> I'm not familiar with AVP but it looks like it's a NIC, so shouldn't it be in network_devices category?
>>
>> --
>> Thanks,
>> Anatoly
>>
>
>
On 14-Feb-18 12:48 AM, Zhang, Xiaohua wrote:
> Hi Yigit and Anantoly,
> I checked the nics-17.11.pdf, the following is description:
> "The Accelerated Virtual Port (AVP) device is a shared memory based device only available
> on virtualization platforms from Wind River Systems. The Wind River Systems virtualization
> platform currently uses QEMU/KVM as its hypervisor and as such provides support for all of
> the QEMU supported virtual and/or emulated devices (e.g., virtio, e1000, etc.). The platform
> offers the virtio device type as the default device when launching a virtual machine or creating
> a virtual machine port. The AVP device is a specialized device available to customers that
> require increased throughput and decreased latency to meet the demands of their performance
> focused applications."
>
> I am afraid just "memory_device" will have some misunderstanding.
> Could we put it as "avp device (shared memory based)"?
>
>
Hi,
Well, from AVP PMD documentation, it seems that AVP is classified as a
NIC. Can't we just add it to the list of NICs, even if it's not Ethernet
class 0x20xx? Pattern-matching in devbind should work either way. For
example, you can see there's "cavium_pkx" already classified as a NIC,
even though its class is 08xx, not 02xx. So why not this one?
Alternatively, if you think that would be confusing, how about instead
of "memory devices" call it "other devices", for cases which don't fit
into one of the DPDK categories?
>
> BR.
> Xiaohua Zhang
>
> -----Original Message-----
> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
> Sent: Tuesday, February 13, 2018 7:07 PM
> To: BURAKOV, ANATOLY; Zhang, Xiaohua; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] usertools/dpdk-devbind.py: add support for wind river avp device
>
> On 2/13/2018 10:06 AM, Burakov, Anatoly wrote:
>> On 13-Feb-18 1:43 AM, Zhang, Xiaohua wrote:
>>> Hi Anatoly,
>>> AVP is a virtual NIC type, so you are right.
>>>
>>> When using the AVP device, you will see the following information from lspci (example).
>>> Slot: 0000:00:05.0
>>> Class: Unclassified device [00ff]
>>> Vendor: Red Hat, Inc [1af4]
>>> Device: Virtio memory balloon [1002]
>>> SVendor: Red Hat, Inc [1af4]
>>> SDevice: Device [0005]
>>> PhySlot: 5
>>> Driver: virtio-pci
>>>
>>> It is a little different with the standard "Ethernet" controller, such as "Class: Ethernet controller [0200]".
>>> Theoretically, the AVP is a memory based device. That's the reason, I put it as separate catalog.
>>>
>>
>> OK, fair enough. Is there any way we can make this category
>> not-WindRiver AVP specific? Are there other similar devices out there
>> that could potentially fit into this category?
>
> Can we call it "memory_devices" instead of "avp_devices" ?
>
>>
>>>
>>> BR.
>>> Xiaohua Zhang
>>>
>>> -----Original Message-----
>>
>> <snip>
>>
>>>
>>> Is there any particular reason why this device appears in its own category, rather than being added to one of the existing device classes?
>>> I'm not familiar with AVP but it looks like it's a NIC, so shouldn't it be in network_devices category?
>>>
>>> --
>>> Thanks,
>>> Anatoly
>>>
>>
>>
>
On Wed, Feb 14, 2018 at 09:57:25AM +0000, Burakov, Anatoly wrote:
> On 14-Feb-18 12:48 AM, Zhang, Xiaohua wrote:
> > Hi Yigit and Anantoly,
> > I checked the nics-17.11.pdf, the following is description:
> > "The Accelerated Virtual Port (AVP) device is a shared memory based device only available
> > on virtualization platforms from Wind River Systems. The Wind River Systems virtualization
> > platform currently uses QEMU/KVM as its hypervisor and as such provides support for all of
> > the QEMU supported virtual and/or emulated devices (e.g., virtio, e1000, etc.). The platform
> > offers the virtio device type as the default device when launching a virtual machine or creating
> > a virtual machine port. The AVP device is a specialized device available to customers that
> > require increased throughput and decreased latency to meet the demands of their performance
> > focused applications."
> >
> > I am afraid just "memory_device" will have some misunderstanding.
> > Could we put it as "avp device (shared memory based)"?
> >
> >
>
> Hi,
>
> Well, from AVP PMD documentation, it seems that AVP is classified as a NIC.
> Can't we just add it to the list of NICs, even if it's not Ethernet class
> 0x20xx? Pattern-matching in devbind should work either way. For example, you
> can see there's "cavium_pkx" already classified as a NIC, even though its
> class is 08xx, not 02xx. So why not this one?
>
Definite +1.
It's used for packet IO into a vm, like virtio, and it's driver is in
drivers/net.
"If it looks like a NIC, and quacks like a NIC, then it probably is a
NIC". [Alternatively if it looks and quacks like a duck, I'm not sure
what it's doing in DPDK!]
/Bruce
That's no problem for me to move it to the "network" catalog.
Should I generate a new patch?
BR.
Xiaohua Zhang
-----Original Message-----
From: Bruce Richardson [mailto:bruce.richardson@intel.com]
Sent: Wednesday, February 14, 2018 6:32 PM
To: BURAKOV, ANATOLY
Cc: Zhang, Xiaohua; YIGIT, FERRUH; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] usertools/dpdk-devbind.py: add support for wind river avp device
On Wed, Feb 14, 2018 at 09:57:25AM +0000, Burakov, Anatoly wrote:
> On 14-Feb-18 12:48 AM, Zhang, Xiaohua wrote:
> > Hi Yigit and Anantoly,
> > I checked the nics-17.11.pdf, the following is description:
> > "The Accelerated Virtual Port (AVP) device is a shared memory based
> > device only available on virtualization platforms from Wind River
> > Systems. The Wind River Systems virtualization platform currently
> > uses QEMU/KVM as its hypervisor and as such provides support for all
> > of the QEMU supported virtual and/or emulated devices (e.g., virtio,
> > e1000, etc.). The platform offers the virtio device type as the
> > default device when launching a virtual machine or creating a
> > virtual machine port. The AVP device is a specialized device available to customers that require increased throughput and decreased latency to meet the demands of their performance focused applications."
> >
> > I am afraid just "memory_device" will have some misunderstanding.
> > Could we put it as "avp device (shared memory based)"?
> >
> >
>
> Hi,
>
> Well, from AVP PMD documentation, it seems that AVP is classified as a NIC.
> Can't we just add it to the list of NICs, even if it's not Ethernet
> class 0x20xx? Pattern-matching in devbind should work either way. For
> example, you can see there's "cavium_pkx" already classified as a NIC,
> even though its class is 08xx, not 02xx. So why not this one?
>
Definite +1.
It's used for packet IO into a vm, like virtio, and it's driver is in drivers/net.
"If it looks like a NIC, and quacks like a NIC, then it probably is a NIC". [Alternatively if it looks and quacks like a duck, I'm not sure what it's doing in DPDK!]
/Bruce
On 14-Feb-18 11:17 PM, Zhang, Xiaohua wrote:
> That's no problem for me to move it to the "network" catalog.
> Should I generate a new patch?
>
Yes, please.
@@ -22,11 +22,14 @@
'SVendor': None, 'SDevice': None}
cavium_pkx = {'Class': '08', 'Vendor': '177d', 'Device': 'a0dd,a049',
'SVendor': None, 'SDevice': None}
+avp_vnic = {'Class': '05', 'Vendor': '1af4', 'Device': '1110',
+ 'SVendor': None, 'SDevice': None}
network_devices = [network_class, cavium_pkx]
crypto_devices = [encryption_class, intel_processor_class]
eventdev_devices = [cavium_sso]
mempool_devices = [cavium_fpa]
+avp_devices = [avp_vnic]
# global dict ethernet devices present. Dictionary indexed by PCI address.
# Each device within this is itself a dictionary of device properties
@@ -565,6 +568,9 @@ def show_status():
if status_dev == "mempool" or status_dev == "all":
show_device_status(mempool_devices, "Mempool")
+ if status_dev == "avp" or status_dev == "all":
+ show_device_status(avp_devices, "AVP")
+
def parse_args():
'''Parses the command-line arguments given by the user and takes the
appropriate action for each'''
@@ -638,6 +644,7 @@ def do_arg_actions():
get_device_details(crypto_devices)
get_device_details(eventdev_devices)
get_device_details(mempool_devices)
+ get_device_details(avp_devices)
show_status()
@@ -650,6 +657,7 @@ def main():
get_device_details(crypto_devices)
get_device_details(eventdev_devices)
get_device_details(mempool_devices)
+ get_device_details(avp_devices)
do_arg_actions()
if __name__ == "__main__":