From: Liu Xiaofeng
Now socket id is from device's numa_node, if it is invalid, just set it to 0
as default to avoid crash which will be caused by the reference to
port_per_socket[socket_id].
Also one warning is displayed to user that port-numa-config and
ring-numa-config parameters should be use
From: Jean-Mickael Guerin
For RH 6.5:
- always include mdio.h to get the definitions of MDIO_EEE, ETHTOOL_GEEE
- is_link_local_ether_addr(), pcie_capability_clear_and_set_word(), and
ether_addr_equal() have been backported
For RH 6.4:
- same issue with ether_addr_equal()
- here ETH_GEE is def
From: Jean-Mickael Guerin
On RH 6.5:
igb_main.c:2298: error: unknown field ?ndo_fdb_add? specified in
initializer
FDB ops are present in RH 6.5 via the extension of netdev, so add the
ifdef inside the netdev ops definition of igb.
However, FDB functions are not set for RHEL 6.5: the implementat
From: Didier Pallard
initialised field must be checked against INITIALISED value before
allowing malloc to occur, else some core may pass the test and start
malloc while heap is in INITIALISING state and is not fully initialized.
Signed-off-by: Didier Pallard
---
lib/librte_malloc/malloc_heap.
From: Didier Pallard
a write memory barrier is needed before changing heap state
value, else some concurrent core may see state changing before
all initialization values are written to memory, causing
unpredictable results in malloc function.
Signed-off-by: Didier Pallard
---
lib/librte_malloc
lcores that are set in coremask should be checked against lcores detected on
system. This way, we won't need to check them later.
Besides, if specifying an unavailable lcore, we currently panic in
eal_thread_loop() because pthread_setaffinity_np fails.
So this check will return an error with a mor
From: Pascal Mazon
When loading a library "libfoo.so" (depending on "libbar.so", located in an
entirely different folder), with a LD_LIBRARY_PATH=/path/to/libfoo.so", it
returns an error:
EAL: ./libfoo.so: cannot open shared object file: No such file or directory
If the first dlopen() fails (h
Hi,
I have checked that on gcc-4.5, I get a compilation error due to the following
patch:
> > Neil Horman reported that on x86-64 the upper half of %rbx would get
> > clobbered when the code was compiled PIC or PIE, because the
> > i386-specific code to preserve %ebx was incorrectly compiled.
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand
> Sent: Tuesday, April 15, 2014 2:51 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/2] mem: add write memory barrier before
> changing heap state
>
> From: Didier Pallard
>
> a write me
Now that we've converted all the pmds in dpdk to use the driver registration
macro, rte_pmd_init_all has become empty. As theres no reason to keep it around
anymore, just remove it and fix up all the eample callers.
Signed-off-by: Neil Horman
---
app/test-pmd/testpmd.c
convert the vmxnet3 pmd driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the vmxnet3
library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically
convert the virtio pmd driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the virtio
library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
convert the ixgbevf pmd driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the ixgbevf
library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically
convert the ixgbe pmd driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the ixgbe library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Si
convert the e1000 pmd driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the e1000 library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Si
convert the igbvf pmd driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the igbvf library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Si
convert the igb pmd driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the igb library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Signed
Currently, physical device pmds use a separate initalization path
(rte_pmd_init_all) while virtual devices use a constructor registration and
rte_eal_dev_init. Theres no reason to have them be separate. This patch
removes the vdev specific nomenclature from the vdev init path and makes it more
ge
convert the xenvirt driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the xenvirt
library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
A
convert the ring driver to use the PMD_REGISTER_DRIVER macro and fix up the
Makefile so that its linkage is only done if we are building static libraries.
This means that the test applications now have no reference to the ring library
when building DSO's and must specify its use on the command line
convert the pcap driver to use the PMD_REGISTER_DRIVER macro and fix up the
Makefile so that its linkage is only done if we are building static libraries.
This means that the test applications now have no reference to the pcap library
when building DSO's and must specify its use on the command line
Rather than have each driver have to remember to add a constructor to it to make
sure its gets registered properly, wrap that process up in a macro to make
registration a one line affair. This also sets the stage for us to make
registration of vdev pmds and physical pmds a uniform process
Signed-
This happens automatically on dyanmic linking, but when linking an archive we
need to to include the whole archive to make sure we call all the constructors.
Not doing this causes them to be discarded due to the fact theres no symbolic
reference connecting the pmds to the application.
Signed-off-b
The shared libraries built with the current makefile set produce static
libraries rather than actual shared objects. This is due to several missing
options that are required to correctly build shared objects using ld, as well as
a mis-specified -share option (which should be -shared). Switching to
Disconnect compile time linkage between eal library / applications and pmd's
I noticed that, while tinkering with dpdk, building for shared libraries still
resulted in all the test applications linking to all the built pmd's, despite
not actually needing them all. We are able to tell an applicati
Parse args first, to resolve any invalid args and give out the usage string.
E.g './helloworld --invalid', the '--invalid' will be checked before any init.
After the options are checked, take any init actions.
Signed-off-by: Wang Sheng-Hui
---
lib/librte_eal/linuxapp/eal/eal.c | 13 +---
Parse args first, to resolve any invalid args and give out the usage string.
E.g './helloworld --invalid', the '--invalid' will be checked before any init.
After the options are checked, take any init actions.
Signed-off-by: Wang Sheng-Hui
---
lib/librte_eal/linuxapp/eal/eal.c | 13 +---
On Tue, Apr 15, 2014 at 02:09:34PM +, De Lara Guarch, Pablo wrote:
> Hi,
>
> I have checked that on gcc-4.5, I get a compilation error due to the
> following patch:
>
> > > Neil Horman reported that on x86-64 the upper half of %rbx would get
> > > clobbered when the code was compiled PIC or
On Tue, Apr 15, 2014 at 03:50:58PM +0200, David Marchand wrote:
> From: Didier Pallard
>
> a write memory barrier is needed before changing heap state
> value, else some concurrent core may see state changing before
> all initialization values are written to memory, causing
> unpredictable result
2014-04-12 07:04, Neil Horman:
> On Thu, Apr 10, 2014 at 04:47:07PM -0400, Neil Horman wrote:
> > Disconnect compile time linkage between eal library / applications and
> > pmd's
> >
> > I noticed that, while tinkering with dpdk, building for shared libraries
> > still resulted in all the test app
Hi Anatoly,
2014-04-14 14:39, Burakov, Anatoly:
> > This functionality is at least used by virtio-net-pmd.
> > So we cannot remove this without a fix for virtio-net-pmd.
>
> It appears that virtio-net-pmd hasn't been merged in yet? At least I can't
> see it in the git tree for 1.6 release.
Maybe
On Tue, Apr 15, 2014 at 03:50:42PM +0200, David Marchand wrote:
> lcores that are set in coremask should be checked against lcores detected on
> system. This way, we won't need to check them later.
>
> Besides, if specifying an unavailable lcore, we currently panic in
> eal_thread_loop() because p
On Tue, Apr 15, 2014 at 03:50:22PM +0200, David Marchand wrote:
> From: Pascal Mazon
>
> When loading a library "libfoo.so" (depending on "libbar.so", located in an
> entirely different folder), with a LD_LIBRARY_PATH=/path/to/libfoo.so", it
> returns an error:
>
> EAL: ./libfoo.so: cannot open
On Tue, Apr 15, 2014 at 10:31:25AM +0200, Thomas Monjalon wrote:
> 2014-04-12 07:04, Neil Horman:
> > On Thu, Apr 10, 2014 at 04:47:07PM -0400, Neil Horman wrote:
> > > Disconnect compile time linkage between eal library / applications and
> > > pmd's
> > >
> > > I noticed that, while tinkering wi
> RTE_EAL_UNBIND_PORTS was deprecated in DPDK 1.4.0 and removed in
> 1.6.0, but the code was not removed.
>
> The bind/unbind operations should not be handled by the eal.
> These operations should be either done outside of dpdk or inside the PMDs
> themselves as these are their problems.
>
> Sign
> Move RTE_PCI_DRV_FORCE_UNBIND flag handling out of
> RTE_EAL_UNBIND_PORTS section.
> This had nothing to do with RTE_EAL_UNBIND_PORTS anyway.
>
> Signed-off-by: David Marchand
Acked-by: Anatoly Burakov
Best regards,
Anatoly Burakov
DPDK SW Engineer
--
> The pci_switch_module() function should only do what its name tells: unbind
> pci devices and rebind them on the specified kernel driver.
> Hence, it can not call pci_uio_map_resource().
>
> Call to pci_uio_map_resource() should be moved to
> rte_eal_pci_probe_one_driver() so that we can factori
Hi Thomas, David,
Thanks for your detailed explanations and insights, I now have a better
picture. I still have to do a lot of catch up on dpdk.org tree and ecosystem,
so please forgive my ignorance about some dpdk.org-related subjects at times :-)
> Do you agree that the David's version is a g
38 matches
Mail list logo
