[dpdk-dev] Any sample on VMDq?
Dear all, I would like to use VMDq to select traffic based on "arbitrary" parameters (such as IP addresses) and send it directly to a specific virtual machine. However, this apparently doesn't work or (more likely) I'm making some mistake in the code. Is there anybody that succeeded in doing that? Any sample I can use to see where I am wrong? Thank you very much for your support, fulvio
[dpdk-dev] Is Flow Director supported on the x540 chipset?
Dear all, by digging into the DPDK code it seems to me that FDIR is not supported on the x540 chipset, while it is supported on 82599. Another message seems to mention the same problem here: http://dpdk.org/ml/archives/dev/2013-November/000806.html Is there any plan to support FDIR to the x540 chipset? fulvio
[dpdk-dev] Does PCI hotplug work with IVSHMEM?
Dear all, we're adding dynamically an IVSHMEM device on a VM that is already running, but apparently this is not visible in DPDK, while it is correctly recognized by the Guest OS. This is the list of steps we execute: 1) Launch a new Guest VM with Qemu 2) Create a new IVSHMEM metadata file in the Host 3) Map that file as a new IVSHMEM device in the Guest For this step, we use the "device_add" command from Qemu: (qemu) device_add ivshmem,size=2048M,shm=fd:/dev/hugepages /rtemap_0:0x0:0x4000:/dev/zero:0x0:0x3fffc000:/var/run /.dpdk_ivshmem_metadata_vm_1:0x0:0x4000 4) List the available PCI devices in the Guest with "lspci": $ sudo lspci 00:04.0 RAM memory: Red Hat, Inc Virtio Inter-VM shared memory ==> hence, the Guest OS correctly recognizes the new device 5) Lauch a DPDK simple application such as 'helloworld' in the Guest: $ sudo ./build/helloworld -c 0x1 -n 4 EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 0 on socket 0 EAL: Support maximum 128 logical core(s) by configuration. EAL: Detected 2 lcore(s) EAL: VFIO modules not all loaded, skip VFIO support... EAL: Searching for IVSHMEM devices... EAL: No IVSHMEM configuration found! EAL: Setting up memory... ==> Hence, the DPDK app in the Guest OS doesn't recognize the new device. An additional observations that may be important here. If we reboot the Guest and re-lauch the same DPDK as before, the IVSHMEM is correclty detected by the DPDK app: $ sudo reboot $ sudo ./build/helloworld -c 0x1 -n 4 EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 0 on socket 0 EAL: Support maximum 128 logical core(s) by configuration. EAL: Detected 2 lcore(s) EAL: VFIO modules not all loaded, skip VFIO support... EAL: Searching for IVSHMEM devices... EAL: Parsing metadata for "vm_1" EAL: Found IVSHMEM device 00:04.0 EAL: Memory segment mapped: 0x7f8b40d8c000 (len 3937000) at offset 0xd8c000 EAL: IVSHMEM segment found, size: 0x3936ec0 EAL: Setting up memory... Finally, this is what the DPDK programming guide says about IVSHMEM: --- http://dpdk.org/doc/guides/prog_guide/ivshmem_lib.html Currently, there is no hot plug support for QEMU IVSHMEM devices, so one cannot add additional memory to an IVSHMEM device once it has been created. Therefore, the correct sequence to run an IVSHMEM application is to run host application first, obtain the command lines for each IVSHMEM device and then run all QEMU instances with guest applications afterwards. --- To our understanding, IVSHMEM HotPlug is supported, but we cannot resize dynamically the memory. Is that correct? fulvio
[dpdk-dev] [PATCH v2] net/ring: remove unnecessary NULL check
Dear Ferruh,
Maybe I'm wrong, but I cannot see your point.
The code is absolutely the same, only the following line
if (eth_dev->data) {
is actually removed.
fulvio
On 02/11/2016 12:38, Ferruh Yigit wrote:
> Hi Mauricio,
>
> On 11/1/2016 7:55 PM, Mauricio Vasquez B wrote:
>> Coverity detected this as an issue because internals->data will never be
>> NULL,
>> then the check is not necessary.
>>
>> Fixes: d082c0395bf6 ("ring: fix memory leak when detaching")
>> Coverity issue: 137873
>>
>> Signed-off-by: Mauricio Vasquez B
>> ---
>> drivers/net/ring/rte_eth_ring.c | 20 +---
>> 1 file changed, 9 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/net/ring/rte_eth_ring.c
>> b/drivers/net/ring/rte_eth_ring.c
>> index 6d2a8c1..5ca00ed 100644
>> --- a/drivers/net/ring/rte_eth_ring.c
>> +++ b/drivers/net/ring/rte_eth_ring.c
>> @@ -599,17 +599,15 @@ rte_pmd_ring_remove(const char *name)
>>
>> eth_dev_stop(eth_dev);
>>
>> -if (eth_dev->data) {
>> -internals = eth_dev->data->dev_private;
>> -if (internals->action == DEV_CREATE) {
>> -/*
>> - * it is only necessary to delete the rings in
>> rx_queues because
>> - * they are the same used in tx_queues
>> - */
>> -for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
>> -r = eth_dev->data->rx_queues[i];
>> -rte_ring_free(r->rng);
>> -}
>> +internals = eth_dev->data->dev_private;
>> +if (internals->action == DEV_CREATE) {
>> +/*
>> + * it is only necessary to delete the rings in rx_queues because
>> + * they are the same used in tx_queues
>> + */
>> +for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
>> +r = eth_dev->data->rx_queues[i];
>> +rte_ring_free(r->rng);
>> }
>>
>> rte_free(eth_dev->data->rx_queues);
>
> This patch not only removes the NULL check but also changes the logic.
> after patch rx_queues, tx_queues and dev_private only freed if action is
> DEV_CREATE which is wrong.
>
>>
>
