There is an error with 32-bit build:
lib/librte_eal/common/malloc_heap.c:83:2: error: large integer implicitly
truncated to unsigned type [-Werror=overflow]
case RTE_PGSIZE_4G:
^
lib/librte_eal/common/malloc_heap.c:86:2: error: large integer implicitly
truncated to unsigned type
2015-07-14 09:11, Liang-Min Larry Wang:
> v16 changes:
> - Re-do patch v15 and separate changes between v15 and v14 into patch files
> 005 and 006
No, you misunderstood the need.
You must merge your fixes in appropriate patches.
But you must separate the mac_addr_set feature in another patch as
2015-07-14 18:36, Zhe Tao:
> Linux kernel uses the writel and readl related functions to perform the PCI
> memory access via ioremap region,
> those functions will handle the big little endian properly by doing the
> conversion between little and big endian if necessary,
> so Add this conversion
Thomas,
The mac_addr_set is needed for ethtool net-op as described in
examples/ethtool-ethtool/lib/rte_ethtool.c (rte_ethtool_net_set/get_mac_addr).
Could you use the v15 for the release?
Larry
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
Add hotplug support for fm10k.
Signed-off-by: Michael Qiu
Acked-by: Jing Chen
---
drivers/net/fm10k/fm10k_ethdev.c | 97 +++-
1 file changed, 96 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
When close a port, lots of memory should be released,
such as software rings, queues, etc.
Signed-off-by: Michael Qiu
---
drivers/net/fm10k/fm10k_ethdev.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c
Hotplug feature is supported in EAL, this patch set is to enable
this feature in driver side.
change log:
v5 --> v4:
remove rte queue memory release in PMD level
v4 --> v3:
rebase code.
v3 --> v2:
reset queue numbers to zero.
v2 --> v1:
Linux kernel uses the writel and readl related functions to perform the PCI
memory access via ioremap region,
those functions will handle the big little endian properly by doing the
conversion between little and big endian if necessary,
so Add this conversion in the read registers functions for
Hi,
We are developing an application that uses DPDK PMD functionality .
We are using a linux shared library which contains the network packets
processing code and it is statically linked with all the necessary DPDK libs.
The .so is loaded by the main program.
For the DPDK compilation we have
> -Original Message-
> From: Wu, Jingjing
> Sent: Sunday, July 12, 2015 6:22 PM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; Xu, Qian Q; Zhang, Helin
> Subject: [PATCH] i40e: fix the VF rss issue when nb_rx_queue is less than
> nb_tx_queue
>
> From: "jingjing.wu"
>
> I40e VF driver uses
On 2015/07/14 14:03, Qiu, Michael wrote:
> Hi, Tetsuya
>
> So this patch make linux app back to original?
For linux code, it is yes.
For bsd code, it's slight different, because original bsd code doesn't
have pci_map/unmap_device().
When I implement "Commit 35b3313e322b", I should have just
Because VF multi-queues can be supported, l3fwd can run on vf.
Suggest to remove the l3fwd-vf example.
Signed-off-by: jingjing.wu
---
doc/guides/sample_app_ug/index.rst |1 -
doc/guides/sample_app_ug/l3_forward_virtual.rst | 158
examples/l3fwd-vf/Makefile
> -Original Message-
> From: Wu, Jingjing
> Sent: Tuesday, July 14, 2015 12:57 AM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin; Xu, Qian Q
> Subject: [RFC] examples: remove l3fwd-vf example
>
> Because VF multi-queues can be supported, l3fwd can run on vf.
> Suggest to remove
Hey guys,
I'm currently using dpdk 1.8.0 and want to port into it the support for TCP
segmentation for i40e only.
Is it possible to do that without upgrade to 2.0.0? If so, can you please refer
me to a patch file?
Thanks,
Shaham
At this point the stop() and close() functions have already been called.
The rte_eth_promiscuous_disable() function does not return on the VM.
Signed-off-by: Bernard Iremonger
---
app/test-pmd/testpmd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
Add function virtio_free_queues() and call from virtio_dev_close()
Use virtio_dev_rx_queue_release() and virtio_dev_tx_queue_release()
Signed-off-by: Bernard Iremonger
---
drivers/net/virtio/virtio_ethdev.c | 19 +++
1 file changed, 19 insertions(+)
diff --git
Add functions virtio_dev_queue_release(), virtio_dev_rx_queue_release() and
virtio_dev_tx_queue_release().
Signed-off-by: Stephen Hemminger
Signed-off-by: Bernard Iremonger
---
drivers/net/virtio/virtio_ethdev.c | 31 +--
drivers/net/virtio/virtio_ethdev.h | 8
If vq is NULL, there is a segmentation fault.
Signed-off-by: Bernard Iremonger
---
drivers/net/virtio/virtqueue.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/virtio/virtqueue.c b/drivers/net/virtio/virtqueue.c
index 8a3005f..7f60e3e 100644
---
This patch depends on the Port Hotplug Framework.
It implements the eth_dev_uninit_t() function for virtio pmd.
Signed-off-by: Bernard Iremonger
---
drivers/net/virtio/virtio_ethdev.c | 72 ++
1 file changed, 65 insertions(+), 7 deletions(-)
diff --git
Changes in V5:
Rebase.
Add proper queue release patch (patch 3).
Reorder patches, moved previous patch 3 to patch 4,
moved previous patch 4 to patch 5.
Changes in V4:
Rebase to latest code.
Move freeing of queue memory from uninit() function to close() function.
Change to testpmd to facilate
On Tue, 14 Jul 2015 14:10:58 +0100
Bernard Iremonger wrote:
> static void
> +virtio_free_queues(struct rte_eth_dev *dev)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < dev->data->nb_rx_queues; i++) {
> + virtio_dev_rx_queue_release(dev->data->rx_queues[i]);
> +
Hi All,
I am trying to understand if there is support for hotplugging of IVSHMEM
devices in dpdk. I set up a simple experiment where I hotplugged an ivshmem
device into a VM using the device_add command plus the command line
generated by rte_ivshmem_metadata_cmdline_generate in QEMU monitor. It
Hi, all
While I check the maillist, I found a patch:
[dpdk-dev] [PATCH v3] vfio: Fix overflow while assigning vfio BAR region
offset and size
This patch has fixed this issue :), and will be merged.
This patch is same with mine.
So I will not post the patch again.
Thanks,
Michael
On
2015-07-13 14:21, Rahul Lakkireddy:
> When using vfio, the probe fails for BAR > 0 after the
> commit-id 90a1633b2 (eal/linux: allow to map BARs with MSI-X tables).
>
> While debugging further, found that the BAR region offset and size read from
> vfio are u64, but are assigned to uint32_t
Hi, Stephen
I have found out the root cause of this bug, and generate a patch.
Will send out later after :)
Thanks,
Michael
On 7/11/2015 1:24 AM, Stephen Hemminger wrote:
> On Fri, 10 Jul 2015 07:54:10 +
> "Qiu, Michael" wrote:
>
>> Hi, Stephen
>>
>> This patch does not work for fm10k
2015-07-11 15:29, Tetsuya Mukawa:
> The patch fixes vfio initialization issue introduced by below patch.
> - Commit 35b3313e322b ("pci: merge mapping functions for linux and bsd")
>
> Root cause is that VFIO_PRESENT is inaccessible in eal common level.
> To fix it, remove pci_map/unmap_device
2015-07-14 08:20, Jayakumar, Muthurajan:
> Can you please share as what is the benefit of removing l3fwd-vf example?
> Customers have been using this very much.
> Please let me know what is the disadvantage of keeping l3fwd-vf.
What is the benefit of keeping an example which can be replaced?
Update malloc documentation to reflect new implementation details.
Signed-off-by: Sergio Gonzalez Monroy
---
doc/guides/prog_guide/env_abstraction_layer.rst | 220 +-
doc/guides/prog_guide/img/malloc_heap.png | Bin 81329 -> 80952 bytes
doc/guides/prog_guide/index.rst
Announce the creation of dummy malloc library for 2.1 and removal of
such library, now integrated in librte_eal, for 2.2 release.
Signed-off-by: Sergio Gonzalez Monroy
---
doc/guides/rel_notes/abi.rst | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Add new unit test for rte_memzone_free API.
Signed-off-by: Sergio Gonzalez Monroy
---
app/test/test_memzone.c | 82 +++--
1 file changed, 80 insertions(+), 2 deletions(-)
diff --git a/app/test/test_memzone.c b/app/test/test_memzone.c
index
Implement rte_memzone_free which, as its name implies, would free a
memzone.
Currently memzone are tracked in an array and cannot be free.
To be able to reuse the same array to track memzones, we have to
change how we keep track of reserved memzones.
With this patch, any memzone with addr NULL
Remove free_memseg field from internal mem config structure as it is
not used anymore.
Also remove code in ivshmem that was setting up free_memseg on init.
Signed-off-by: Sergio Gonzalez Monroy
---
lib/librte_eal/common/include/rte_eal_memconfig.h | 3 ---
During initializaio malloc sets all available memory as part of the heaps.
CONFIG_RTE_MALLOC_MEMZONE_SIZE was used to specify the default memory
block size to expand the heap. The option is not used/relevant anymore,
so we remove it.
Signed-off-by: Sergio Gonzalez Monroy
---
Some unit test are not relevant anymore. It is the case of those malloc
UTs that checked corner cases when allocating MALLOC_MEMZONE_SIZE
chunks, and the case of those memzone UTs relaying of specific free
memsegs of rhte reserved memzone.
Other UTs just need to be update, for example, to
In the current memory hierarchy, memsegs are groups of physically
contiguous hugepages, memzones are slices of memsegs and malloc further
slices memzones into smaller memory chunks.
This patch modifies malloc so it partitions memsegs instead of memzones.
Thus memzones would call malloc internally
Move malloc inside eal and create a new section in MAINTAINERS file for
Memory Allocation in EAL.
Create a dummy malloc library to avoid breaking applications that have
librte_malloc in their DT_NEEDED entries.
This is the first step towards using malloc to allocate memory directly
from memsegs.
Current implemetation allows reserving/creating memzones but not the opposite
(unreserve/free). This affects mempools and other memzone based objects.
>From my point of view, implementing free functionality for memzones would look
like malloc over memsegs.
Thus, this approach moves malloc inside
I. Change lib/rte_ethtool.c with new API name (rte_eth_dev_get_reg_length,
rte_eth_dev_get_reg_info and rte_eth_dev_get_eeprom_length)
II. Change l2fwd-app/Makefile to adapt build directory change
Signed-off-by: Liang-Min Larry Wang
---
examples/l2fwd-ethtool/l2fwd-app/Makefile | 3 +--
I. change api name with "get"
- rte_eth_dev_get_reg_length
- rte_eth_dev_get_reg_info
- rte_eth_dev_get_eeprom_length
II. fix unused variable in VALID_PORTID_OR_ERR_RET
III. use VALID_PORTID_OR_ERR_RET instead of rte_eth_dev_is_valid_port and
III. move new api name to version 2.1 list
The example includes an ethtool library and two applications:
one application is a non- DPDK process (nic-control)
and the other is a DPDK l2fwd applicaiton (l2fwd-app).
The nic-control process sends ethtool alike device management
requests to l2fwd-app through a named pipe IPC. This example
is
add function to support ethtool ops:
- set_mac_addr
- get_reg_length
- get_regs
- get_eeprom_length
- get_eeprom
- set_eeprom
Signed-off-by: Liang-Min Larry Wang
---
drivers/net/e1000/igb_ethdev.c | 175
drivers/net/e1000/igb_regs.h | 223
add function to support ethtool ops:
- set_mac_addr
- get_reg_length
- get_regs
- get_eeprom_length
- get_eeprom
- set_eeprom
Signed-off-by: Liang-Min Larry Wang
---
drivers/net/ixgbe/ixgbe_ethdev.c | 178 +-
drivers/net/ixgbe/ixgbe_regs.h | 376
add two new apis: rte_eth_dev_default_mac_addr_set
and rte_eth_ethtool_dev_info to enable
reading device parameters (mac, register, eeprom,
pause, ring) based upon ethtool alike
data parameter sepcification.
Signed-off-by: Liang-Min Larry Wang
---
lib/librte_ether/Makefile | 1 +
This implementation is designed to provide a familar interface for applications
that rely on kernel-space driver to support ethtool_op and net_device_op for
device management. The initial implementation focuses on ops that can be
implemented through existing netdev APIs. More ops will be
Can you please share as what is the benefit of removing l3fwd-vf example?
Customers have been using this very much.
Please let me know what is the disadvantage of keeping l3fwd-vf.
Thanks
M Jay
http://dpdk.readthedocs.org/en/latest/
-Original Message-
From: dev
On 7/9/2015 11:32 AM, Tetsuya Mukawa wrote:
> On 2015/07/08 18:59, Thomas Monjalon wrote:
>> 2015-07-08 09:49, Iremonger, Bernard:
>>> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
On 2015/07/07 19:53, Iremonger, Bernard wrote:
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
Hi, Tetsuya
So this patch make linux app back to original?
Thanks,
Michael
On 7/11/2015 2:30 PM, Tetsuya Mukawa wrote:
> The patch fixes vfio initialization issue introduced by below patch.
> - Commit 35b3313e322b ("pci: merge mapping functions for linux and bsd")
>
> Root cause is that
Hi Yury,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yury Kylulin
> Sent: Thursday, May 28, 2015 10:47 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] e1000: enable allmulticast support for VF
>
> Add support to enable and disable reception of
2015-07-12 17:22, Liang-Min Larry Wang:
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -2542,6 +2542,30 @@ rte_eth_dev_mac_addr_remove(uint8_t port_id, struct
> ether_addr *addr)
> }
>
> int
> +rte_eth_dev_default_mac_addr_set(uint8_t port_id, struct
Hey,
I'm having some trouble calculating the right mempool & ring sizes for my
application. I'm getting mempool full errors even though that shouldn't be
possible, so I'm missing something. Can you help me figure out if my math is
correct?
My application is using a nic -> rx_core ->
50 matches
Mail list logo
