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