> Just to confirm, should I do anything before it gets merged?
No. Looks good to me. Now you just need to wait. :-)
John.
"Ananyev, Konstantin" writes:
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Aaron Conole
>> Sent: Thursday, June 09, 2016 4:59 PM
>> To: Pattan, Reshma
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v6 5/8] lib/librte_pdump: add new
> library f
On Wed, Jun 08, 2016 at 05:14:05PM +, Mcnamara, John wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > Sent: Tuesday, May 31, 2016 2:58 PM
> > To: dev at dpdk.org
> > Cc: Neil Horman ; Richardson, Bruce
> > ; Thomas Monjalon > 6wi
>
> This patch set include below changes
>
> 1)Changes to librte_ether.
> 2)A new library librte_pdump added for packet capture framework.
> 3)A new app/pdump tool added for packet capturing.
> 4)Test pmd changes done to initialize packet capture framework.
> 5)Documentation update.
>
> 1)librte
Hey all-
So heres attempt number 2 at a method for exporting PMD hardware support
information. As we discussed previously, the consensus seems to be that pmd
information should be:
1) Able to be interrogated on any ELF binary (application binary or individual
DSO)
2) Equally functional on
pmdinfogen is a tool used to parse object files and build json strings for
use in later determining hardware support in a dso or application binary.
pmdinfo looks for the non-exported symbol names this_pmd_name and
this_pmd_tbl (where n is a integer counter). It records the name of
each of these t
Modify the PMD_REGISTER_DRIVER macro, adding a name argument to it. The
addition of a name argument creates a token that can be used for subsequent
macros in the creation of unique symbol names to export additional bits of
information for use by the pmdinfogen tool. For example:
PMD_REGISTER_DRI
Export a symbol containing the string:
DPDK_PLUGIN_PATH="$(CONFIG_RTE_EAL_PMD_PATH)"
Where the latter half of the string is set at build time to a location from
which autoloaded DSO's will be found. This string is used by pmdinfo in
'plugin' mode, whereby a user can specify a dpdk installation di
This tool searches for the primer sting PMD_DRIVER_INFO= in any ELF binary,
and, if found parses the remainder of the string as a json encoded string,
outputting the results in either a human readable or raw, script parseable
format
Note that, in the case of dynamically linked applications, pmdinf
Modify the compilation makefile to identify C files that export PMD
information, and use that to trigger execution of the pmdinfo binary. If
the execution of pmdinfo is successful, compile the output C file to an
object, and use the linker to do relocatable linking on the resultant
object file int
Information on pmdinfogen may be useful to 3rd party driver developers.
Include documentation on what it does
Signed-off-by: Neil Horman
CC: Bruce Richardson
CC: Thomas Monjalon
CC: Stephen Hemminger
CC: Panu Matilainen
---
doc/guides/prog_guide/dev_kit_build_system.rst | 43
> -Original Message-
> From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com]
> Sent: Thursday, June 09, 2016 8:45 AM
> To: Thomas Monjalon
> Cc: dev at dpdk.org; Olivier Matz ; Adrien
> Mazarguil ; Zhang, Helin intel.com>
> Subject: Re: [dpdk-dev] [PATCH] mbuf: remove incon
Patch broken into separate patches for fixing seg fault and improving
log messages.
John Daley (2):
enic: fix seg fault when releasing queues
enic: more specific out of resources error messages
drivers/net/enic/enic_main.c | 24 +---
1 file changed, 17 insertions(+), 7 de
If device configuration failed due to a lack of resources, such as
if more queues are requested than are available, the queue release
function is called with NULL pointers which were being dereferenced.
Skip releasing queues if they are NULL pointers.
Fixes: fefed3d1e62c ("enic: new driver")
Sign
If configuration fails due to lack of resources, be more specific
about which resources are lacking - work queues, read queues or
completion queues.
Fixes: fefed3d1e62c ("enic: new driver")
Signed-off-by: John Daley
---
v3: Log messages fix in separate patch. Log errors
for all lacking resources,
> -Original Message-
> From: Aaron Conole [mailto:aconole at redhat.com]
> Sent: Thursday, June 09, 2016 6:24 PM
> To: Ananyev, Konstantin
> Cc: Pattan, Reshma; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 5/8] lib/librte_pdump: add new library for
> packet capturing support
>
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> Sent: Thursday, June 9, 2016 6:47 PM
> To: dev at dpdk.org
> Cc: Neil Horman ; Richardson, Bruce
> ; Thomas Monjalon 6wind.com>;
> Stephen Hemminger ; Panu Matilainen
>
> Subject: [dpdk-dev] [PATC
"Ananyev, Konstantin" writes:
>> -Original Message-
>> From: Aaron Conole [mailto:aconole at redhat.com]
>> Sent: Thursday, June 09, 2016 6:24 PM
>> To: Ananyev, Konstantin
>> Cc: Pattan, Reshma; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v6 5/8] lib/librte_pdump: add new
>> librar
Looking a bit more into librte_ivshmem, the documentation says we need
a Qemu patch but the URL doesn't exist anymore:
https://01.org/packet-processing/intel%C2%AE-ovdk
-> 404 Oops, we couldn't find that page
I've never understood why we should keep this wart and now I'm going
to b
Just to confirm, should I do anything before it gets merged?
On Thu, Jun 9, 2016 at 5:03 AM, Mcnamara, John
wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex Wang
> > Sent: Saturday, May 21, 2016 8:59 AM
> > To: dev at dpdk.org
> > Cc: Yigit,
Hi Ethan,
Great work! There are still several comments below that need to be addressed,
but I am confident we can close on them quickly. Thank you!
Please rebase the next version on top of the latest code on master branch.
Please also update librte_port/rte_port_version.map file.
> -Origi
101 - 121 of 121 matches
Mail list logo
