[dpdk-dev] [PATCH] ethdev: additional parameter in RX callback

[Neil Horman]

On Fri, Mar 13, 2015 at 06:28:31PM +, Mcnamara, John wrote:
> 
> 
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Friday, March 13, 2015 5:32 PM
> > To: Mcnamara, John
> > Cc: Richardson, Bruce; dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] ethdev: additional parameter in RX
> > callback
> > 
> > > Is encoding the information in the array really a better solution here?
> > The cb->param already exists for passing in user defined information to
> > the callback. The proposed patch merely transmits the parent function
> > arguments to the enclosed callback.
> > >
> > The cb->param can't be used here, because its opaque to the internals of
> > the DPDK.  rte_eth_rx_burst doesn't (and can't) know where in the cb-
> > >params pointer to store that information.  Thats why you added an
> > additional parameter in the first place, isn't it?
> 
> Yes. That is correct.
> 
Then why did you suggest doing so?

> > My point is that using
> > an array terminator keeps us out of this habbit of just adding parameters
> > to communicate more information (as thats an ABI breaking method, and not
> > particularly scalable if there is more information to be transmitted in
> > the future).  Using a context sensitive API set goes beyond even that, and
> > allows to retrieve arbitrary information form callbacks as needed in an
> > ABI safe manner
> 
> Again I can agree with this in the general case, but it isn't necessary, in 
> this case, to encode the information in the array since it is already local 
> to and available in the function. It seems artificial, at this point, to 
> implement an array terminator solution to protect an API that, effectively, 
> hasn't been published yet.
> 
You indicate that you agree an alternate solution is preferable in the general
case, so as to provide an API that is extensible in a way that isn't subject to
ABI breakage, correct?  If so, why do assert that its not necessecary in this
specific case?  If you feel you need to add information so that callbacks can be
more flexible (in this case specifying the size of a passed in array), why
immediately shoehorn another parmeter in place, and break the consistency
between rx and tx callbacks, when you don't have to?  I don't care if you break
ABI today (although to call it unpublished I think is disingenuous, as lots of
testing and development has already taken place with the ABI as it currently
stands).  I care, as I noted above about not getting into the habbit of just
assuming a change like this requires that you invaliate ABI somehow.  You don't
have to, you can create an API that is fairly invariant to it here if you like.
The question in my mind is, why don't you?

Neil


> John
> 
>  
> 
> 
> 

[dpdk-dev] [PATCH] ethdev: additional parameter in RX callback

[Mcnamara, John]

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Friday, March 13, 2015 5:32 PM
> To: Mcnamara, John
> Cc: Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] ethdev: additional parameter in RX
> callback
> 
> > Is encoding the information in the array really a better solution here?
> The cb->param already exists for passing in user defined information to
> the callback. The proposed patch merely transmits the parent function
> arguments to the enclosed callback.
> >
> The cb->param can't be used here, because its opaque to the internals of
> the DPDK.  rte_eth_rx_burst doesn't (and can't) know where in the cb-
> >params pointer to store that information.  Thats why you added an
> additional parameter in the first place, isn't it?

Yes. That is correct.

> My point is that using
> an array terminator keeps us out of this habbit of just adding parameters
> to communicate more information (as thats an ABI breaking method, and not
> particularly scalable if there is more information to be transmitted in
> the future).  Using a context sensitive API set goes beyond even that, and
> allows to retrieve arbitrary information form callbacks as needed in an
> ABI safe manner

Again I can agree with this in the general case, but it isn't necessary, in 
this case, to encode the information in the array since it is already local to 
and available in the function. It seems artificial, at this point, to implement 
an array terminator solution to protect an API that, effectively, hasn't been 
published yet.

John

[dpdk-dev] [ dpdk-pktgen execution issue ] Error: Didn't find any ports to use

[Ngo Doan Lap]

Hi,
It seems that your NICs are not supported by DPDK.
Here are list of supproted NICs cards
http://dpdk.org/doc/nics

On Fri, Mar 13, 2015 at 5:03 PM, Arkajit Ghosh 
wrote:

>  Hi,
>
> Can you please guide me as I am facing the below issue during execution of
> DPDK-Pktgen.
>
> Thanks & Regards
> Arkajit Ghosh
> 
>
> -Arkajit Ghosh/DEL/TCS wrote: -
> To: "Wiles, Keith" 
> From: Arkajit Ghosh/DEL/TCS
> Date: 03/11/2015 02:33PM
> Subject: Re: [dpdk-dev] [ dpdk-pktgen execution issue ] Error: Didn't find
> any ports to use
>
>  Hi,
>
> Can you please suggest how to proceed.
>
>
> Thanks & Regards
> Arkajit Ghosh
> 
>
> -Arkajit Ghosh/DEL/TCS wrote: -
> To: "Wiles, Keith" 
> From: Arkajit Ghosh/DEL/TCS
> Date: 03/10/2015 12:49PM
> Subject: Re: [dpdk-dev] [ dpdk-pktgen execution issue ] Error: Didn't find
> any ports to use
>
>  Hi Keith,
>
> Sorry for replying after after long days as I was involved in different
> module so not able to to track down this issue. Now once again back to this
> module.  This time I had executed pktgen-DPDK in Host machine and Bridge
> and DPDK ports configuration done in guest machine (VM). Please find
> attachment for bridge and dpdk-ports creation in guest machine.
>
> Facing same issue "ports not found" and as well as this below issue:
>
> #
> EAL: Support maximum 64 logical core(s) by configuration.
> EAL: Detected 24 lcore(s)
> EAL: Auto-detected process type: PRIMARY
> EAL:   cannot open VFIO container, error 2 (No such file or directory)
> EAL: VFIO support could not be initialized
> EAL: Setting up memory...
> EAL: Ask a virtual area of 0x20 bytes
> EAL: Virtual area found at 0x7f5970c0 (size = 0x20)
> EAL: Ask a virtual area of 0x20 bytes
> EAL: Virtual area found at 0x7f597080 (size = 0x20)
> EAL: Ask a virtual area of 0x20 bytes
> EAL: Virtual area found at 0x7f597040 (size = 0x20)
> EAL: Requesting 1 pages of size 2MB from socket 0
> EAL: rte_eal_common_log_init(): cannot create log_history mempool
> PANIC in rte_eal_init():
> Cannot init logs
> 6: [./app/build/pktgen() [0x422df3]]
> 5: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)
> [0x7f5970f06ec5]]
> 4: [./app/build/pktgen(main+0x127) [0x422547]]
> 3: [./app/build/pktgen(rte_eal_init+0x1d87) [0x4b0207]]
> 2: [./app/build/pktgen(__rte_panic+0xc9) [0x4222c6]]
> 1: [./app/build/pktgen(rte_dump_stack+0x18) [0x4b7478]]
> Aborted (core dumped)
> ###
>
> Here is the output (As requested last mail chain): lspci | grep Ethernet
>
> 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5720
> Gigabit Ethernet PCIe
> 01:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720
> Gigabit Ethernet PCIe
> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719
> Gigabit Ethernet PCIe (rev 01)
> 02:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719
> Gigabit Ethernet PCIe (rev 01)
> 02:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719
> Gigabit Ethernet PCIe (rev 01)
> 02:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719
> Gigabit Ethernet PCIe (rev 01)
>
> ../../../dpdk/tools/dpdk_nic_bind.py --status
>
> Network devices using DPDK-compatible driver
> 
> 
>
> Network devices using kernel driver
> ===
> :01:00.0 'NetXtreme BCM5720 Gigabit Ethernet PCIe' if=eth0 drv=tg3
> unused=
> :01:00.1 'NetXtreme BCM5720 Gigabit Ethernet PCIe' if=eth1 drv=tg3
> unused=
> :02:00.0 'NetXtreme BCM5719 Gigabit Ethernet PCIe' if=eth2 drv=tg3
> unused=
> :02:00.1 'NetXtreme BCM5719 Gigabit Ethernet PCIe' if=eth3 drv=tg3
> unused=
> :02:00.2 'NetXtreme BCM5719 Gigabit Ethernet PCIe' if=eth4 drv=tg3
> unused=
> :02:00.3 'NetXtreme BCM5719 Gigabit Ethernet PCIe' if=eth5 drv=tg3
> unused= *Active*
>
> Other network devices
> =
> 
>
> Please suggest how to proceed.
>
> Thanks & Regards
> Arkajit Ghosh
> 
>
> -"Wiles, Keith"  wrote: -
> To: Arkajit Ghosh , "dev at dpdk.org"  dpdk.org>
> From: "Wiles, Keith" 
> Date: 02/02/2015 08:17PM
> Subject: Re: [dpdk-dev] [ dpdk-pktgen execution issue ] Error: Didn't find
> any ports to use
>
>
> On 2/2/15, 3:10 AM, "Arkajit Ghosh"  wrote:
>
> >
> >Hi,
> >
> >Facing issue during the execution of dpdk-pktgen in VM. Please find the
> >below details:
> >
> >Setup details:
> >
> >> Executing in Guest machine (VM).
> >> Having 2 logical core.
> >>Configured 2048 km hugepages
> >>Number of processor: 2
> >
> >Scenario to verify: Generate some packets by dpdk-pktgen and then one
> >dpdk-ports will work as a RX end and other one will be as TX end to
> >handle the incoming packets and do the required action.
> >
> 

[dpdk-dev] [PATCH v2 2/2] doc: update release note for fm10k pmd driver

[Chen Jing D(Mark)]

From: "Chen Jing D(Mark)" 

Add feature list for fm10k driver.

Signed-off-by: Chen Jing D(Mark) 
---
 doc/guides/rel_notes/new_features.rst |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/doc/guides/rel_notes/new_features.rst 
b/doc/guides/rel_notes/new_features.rst
index 2993b1e..a27e360 100644
--- a/doc/guides/rel_notes/new_features.rst
+++ b/doc/guides/rel_notes/new_features.rst
@@ -58,4 +58,24 @@ New Features

 *   Packet Distributor Sample Application

+*   Poll Mode Driver - PCIE host-interface of Intel Ethernet Switch FM1 
Series (librte_pmd_fm10k)
+
+*   Basic Rx/Tx functions for PF/VF
+
+*   Interrupt handling support for PF/VF
+
+*   Per queue start/stop functions for PF/VF
+
+*   Support Mailbox handling between PF/VF and PF/Switch Manager
+
+*   Receive Side Scaling (RSS) for PF/VF
+
+*   Scatter receive function for PF/VF
+
+*   Reta update/query for PF/VF
+
+*   VLAN filter set for PF
+
+*   Link status query for PF/VF
+
 For further features supported in this release, see Chapter 3 Supported 
Features.
-- 
1.7.7.6

[dpdk-dev] [PATCH v2 1/2] doc: update programmers guide for fm10k pmd driver

[Chen Jing D(Mark)]

From: "Chen Jing D(Mark)" 

DPDK introduced pmd driver for PCIE host-interface of Intel Ethernet
Switch FM1 Series, update programming guide to describe the new
driver and usage.

Signed-off-by: Chen Jing D(Mark) 
---
 .../prog_guide/i40e_ixgbe_igb_virt_func_drv.rst|   37 ++-
 doc/guides/prog_guide/source_org.rst   |1 +
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/doc/guides/prog_guide/i40e_ixgbe_igb_virt_func_drv.rst 
b/doc/guides/prog_guide/i40e_ixgbe_igb_virt_func_drv.rst
index 41e316e..8ea518d 100755
--- a/doc/guides/prog_guide/i40e_ixgbe_igb_virt_func_drv.rst
+++ b/doc/guides/prog_guide/i40e_ixgbe_igb_virt_func_drv.rst
@@ -53,9 +53,10 @@ Refer to Figure 10.

 Therefore, a NIC is logically distributed among multiple virtual machines (as 
shown in Figure 10),
 while still having global data in common to share with the Physical Function 
and other Virtual Functions.
-The DPDK i40evf, igbvf or ixgbevf as a Poll Mode Driver (PMD) serves for the 
Intel? 82576 Gigabit Ethernet Controller,
+The DPDK fm10kvf, i40evf, igbvf or ixgbevf as a Poll Mode Driver (PMD) serves 
for the Intel? 82576 Gigabit Ethernet Controller,
 Intel? Ethernet Controller I350 family, Intel? 82599 10 Gigabit Ethernet 
Controller NIC,
-or Intel? Fortville 10/40 Gigabit Ethernet Controller NIC's virtual PCI 
function.
+Intel? Fortville 10/40 Gigabit Ethernet Controller NIC's virtual PCI 
function,or PCIE host-interface of the Intel Ethernet Switch
+FM1 Series.
 Meanwhile the DPDK Poll Mode Driver (PMD) also supports "Physical Function" of 
such NIC's on the host.

 The DPDK PF/VF Poll Mode Driver (PMD) supports the Layer 2 switch on Intel? 
82576 Gigabit Ethernet Controller,
@@ -93,6 +94,38 @@ and the Physical Function operates on the global resources 
on behalf of the Virt
 For this out-of-band communication, an SR-IOV enabled NIC provides a memory 
buffer for each Virtual Function,
 which is called a "Mailbox".

+
+The PCIE host-interface of Intel Ethernet Switch FM1 Series VF 
infrastructure
+
+
+In a virtualized environment, the programmer can enable a maximum of *64 
Virtual Functions (VF)*
+globally per PCIE host-interface of the Intel Ethernet Switch FM1 Series 
device.
+Each VF can have a maximum of 16 queue pairs.
+The Physical Function in host could be only configured by the Linux* fm10k 
driver
+(in the case of the Linux Kernel-based Virtual Machine [KVM]), DPDK PMD PF 
driver doesn't support it yet.
+
+For example,
+
+*   Using Linux* fm10k driver:
+
+.. code-block:: console
+
+rmmod fm10k (To remove the fm10k module)
+insmod fm0k.ko max_vfs=2,2 (To enable two Virtual Functions per port)
+
+Virtual Function enumeration is performed in the following sequence by the 
Linux* pci driver for a dual-port NIC.
+When you enable the four Virtual Functions with the above command, the four 
enabled functions have a Function#
+represented by (Bus#, Device#, Function#) in sequence starting from 0 to 3.
+However:
+
+*   Virtual Functions 0 and 2 belong to Physical Function 0
+
+*   Virtual Functions 1 and 3 belong to Physical Function 1
+
+.. note::
+
+The above is an important consideration to take into account when 
targeting specific packets to a selected port.
+
 Intel? Fortville 10/40 Gigabit Ethernet Controller VF Infrastructure
 

diff --git a/doc/guides/prog_guide/source_org.rst 
b/doc/guides/prog_guide/source_org.rst
index c66ad16..061f107 100644
--- a/doc/guides/prog_guide/source_org.rst
+++ b/doc/guides/prog_guide/source_org.rst
@@ -81,6 +81,7 @@ The lib directory contains::
 +-- librte_net  # various IP-related headers
 +-- librte_pmd_bond # bonding poll mode driver
 +-- librte_pmd_e1000# 1GbE poll mode drivers (igb and em)
++-- librte_pmd_fm10k# Host interface PMD driver for FM1 Series
 +-- librte_pmd_ixgbe# 10GbE poll mode driver
 +-- librte_pmd_i40e # 40GbE poll mode driver
 +-- librte_pmd_mlx4 # Mellanox ConnectX-3 poll mode driver
-- 
1.7.7.6

[dpdk-dev] [PATCH v2 0/2] doc: update doc for fm10k driver

[Chen Jing D(Mark)]

From: "Chen Jing D(Mark)" 

Update programming guide and release notes for fm10k driver.

Changes in v2:
- Remove a punctuation.


Chen Jing D(Mark) (2):
  doc: update programmers guide for fm10k pmd driver
  doc: update release note for fm10k pmd driver

 .../prog_guide/i40e_ixgbe_igb_virt_func_drv.rst|   37 ++-
 doc/guides/prog_guide/source_org.rst   |1 +
 doc/guides/rel_notes/new_features.rst  |   20 +++
 3 files changed, 56 insertions(+), 2 deletions(-)

-- 
1.7.7.6

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Gonzalez Monroy, Sergio]

On 13/03/2015 16:07, Stephen Hemminger wrote:
> On Thu, 12 Mar 2015 16:27:58 +
> Sergio Gonzalez Monroy  wrote:
>
>> Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME.
>>
>> Signed-off-by: Sergio Gonzalez Monroy 
>> ---
> NAK. The combined library is good and useful for those who want simplicity
> and build with static library.
>
> It is not clear what you are trying to solve.
As I mentioned in other post, you can merge multiple archives into a 
single/combined one pretty easily.

I think we can agree that it is not useful for shared libraries, and 
with versioning in place, combined shared
library will be broken the moment we version an API.

I don't think we need build config  options just for the combined static 
library when we can achieve the
same result with a simple script post build.

Sergio

[dpdk-dev] PMD architecture related to code

[Akshay]

If you mean the actual working, then you'd to explore the code for PMD
drivers that DPDK supports (I suggest try igb).

I tried my hands at making a Atheros E2200 linux driver as PMD for DPDK but
didn't complete it.

-Akshay

On Fri, Mar 13, 2015 at 4:15 PM,  wrote:

>  Hi Akshay ,
>
>
>
> I already gone through the DPDK prog guide , but I am wondering to know
> how Poll Mode driver working IN DPDK framework .
>
>
>
>
>
>
>
>
>
> Regards
>
> Kuldeep
>
>
>
> *From:* Akshay [mailto:akshay.ranjan at gmail.com]
> *Sent:* Friday, March 13, 2015 10:48 AM
> *To:* Kuldeep Samasi (WT01 - Global Media & Telecom)
> *Cc:* dev at dpdk.org
> *Subject:* Re: [dpdk-dev] PMD architecture related to code
>
>
>
> Kuldeep,
>
>
>
> The documentation on dpdk.org explains quite a lot about the
> architecture. I suggest you go through it first.
>
>
>
> http://dpdk.org/doc/guides/prog_guide/
>
>
>
> -Akshay
>
>
>
> On Fri, Mar 13, 2015 at 10:15 AM,  wrote:
>
> Hi Developer Team ,
>
>
> I am trying add new functionality on Poll Mode driver .
> But I don't have idea how packets are coming to kernel mode and going to
> user space and doing packet processing DPDK .
>
> I need suggestion on which file the PMD architecture defined .
>
>
>
> Regards ,
> Kuldeep
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>
>
>  The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>

[dpdk-dev] [PATCH] ethdev: additional parameter in RX callback

[Mcnamara, John]

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Friday, March 13, 2015 3:09 PM
> To: Richardson, Bruce
> Cc: Mcnamara, John; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] ethdev: additional parameter in RX
> callback
> 
> Plese set asside the ABI issue for a moment.  I get that you're trying to
> get it in prior to needing to version it.  Thats not the argument.  The
> argument is how best to codify the new information you want to express in
> the callback.  For this specific case, I think there are better ways to do
> this than to just blindly add a new parameter.

Hi Neil,

I think that is good advice is the general case but this is a very specific 
case. The modified callback is only used in rte_eth_rx_burst(). For context 
here is the function in its entirety (without #defs). The substantive change 
(the addition of nb_pkts) is on the line with an asterisk:


static inline uint16_t
rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id,
 struct rte_mbuf **rx_pkts, const uint16_t nb_pkts)
{
struct rte_eth_dev *dev;

dev = _eth_devices[port_id];

int16_t nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
rx_pkts, nb_pkts);

struct rte_eth_rxtx_callback *cb = dev->post_rx_burst_cbs[queue_id];

if (unlikely(cb != NULL)) {
do {
nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx,
*   nb_pkts, cb->param);
cb = cb->next;
} while (cb != NULL);
}

return nb_rx;
}

> Encoding the array size
> implicitly with a terminating marker lets you use this equally well with
> the tx and rx callbacks (should you ever need it on the latter)

Is encoding the information in the array really a better solution here? The 
cb->param already exists for passing in user defined information to the 
callback. The proposed patch merely transmits the parent function arguments to 
the enclosed callback.

John

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Stefan Puiu]

Hi,

2 cents from a DPDK library user - I make 2 changes to the default
linux+gcc configuration: combine libraries and build shared libraries
(since I want 2 instances of the app, it didn't make sense to me to
link statically). I tried working with the individual libs, but adding
all of them with --start-group/-end-group just seemed so much more
painful than simply linking against one lib. I know there are some
Makefile variables to help with this, but I use scons for building my
app, so that doesn't help much.

Of course, if that can be achieved easily after building all the
libraries, that's fine. But I think combining the libs makes a lot of
sense in many cases.

Thanks,
Stefan.

On Fri, Mar 13, 2015 at 3:17 PM, Neil Horman  wrote:
> On Fri, Mar 13, 2015 at 11:48:59AM +, Gonzalez Monroy, Sergio wrote:
>> On 13/03/2015 11:34, Kavanagh, Mark B wrote:
>> >>On 13/03/2015 10:49, Kavanagh, Mark B wrote:
>> ---
>> config/common_bsdapp|   6 --
>> config/common_linuxapp  |   6 --
>> config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
>> lib/Makefile|   1 -
>> mk/rte.app.mk   |  12 
>> mk/rte.lib.mk   |  35 --
>> mk/rte.sdkbuild.mk  |   3 -
>> mk/rte.sharelib.mk  | 101 
>> 
>> mk/rte.vars.mk  |   9 ---
>> 9 files changed, 175 deletions(-)
>> delete mode 100644 mk/rte.sharelib.mk
>> 
>> diff --git a/config/common_bsdapp b/config/common_bsdapp
>> index 8ff4dc2..7ee5ecf 100644
>> --- a/config/common_bsdapp
>> +++ b/config/common_bsdapp
>> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
>> CONFIG_RTE_BUILD_SHARED_LIB=n
>> 
>> #
>> -# Combine to one single library
>> -#
>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
>> -CONFIG_RTE_LIBNAME=intel_dpdk
>> >>>Hi Sergio,
>> >>>
>> >>>Removing these options breaks compatibility with OVS. While it may be 
>> >>>feasible to link
>> >>to individual static libraries, in our experience, a single combined 
>> >>library provides a
>> >>much more convenient way of linking.
>> >>>Thanks,
>> >>>Mark
>> >>>
>> -
>> >
>> >(snip)
>> >
>> >
>> -endif
>> -
>> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
>> -ifeq ($(RTE_LIBNAME),)
>> -RTE_LIBNAME := intel_dpdk
>> endif
>> 
>> # RTE_TARGET is deducted from config when we are building the SDK.
>> --
>> 1.9.3
>> >>Hi Mark,
>> >>
>> >>How does this patch break compatibility with OVS?
>> >>
>> >>Thanks,
>> >>Sergio
>> >Hey Sergio,
>> >
>> >We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to 
>> >build a single static DPDK library, named 'libintel_dpdk.a', which OVS 
>> >links against. Removing the combined library option breaks compatibility 
>> >with any application that links against the combined DPDK library.
>> >
>> >Is there a strong technical motivation for removing these options?
>> >
>> >Thanks,
>> >Mark
>> From a shared library point of view, it just does not make sense to have
>> applications linked against a 'combined' library that may have different
>> features built in it.
>>
>> Removing these options, aside from the obvious 'less build config option',
>> it simplifies maintenance of makefiles as we currently have a separated
>> makefile with specific rules just for combined library.
>>
>> It is pretty straight forward to build a single combined archive out of
>> multiple archives, would it be acceptable to have a script to do this?
>>
>> Thanks,
>> Sergio
>>
> +1
>
> For the static case, its easy to do a post build combination of archives.  For
> the shared library case, its equally easy to simply create a linker scripts 
> call
> .so that pulls in all the individual libraries.
>
> Neil
>

[dpdk-dev] [PATCH v3] ABI: Add abi checking utility

[Kavanagh, Mark B]

>-Original Message-
>From: Neil Horman [mailto:nhorman at tuxdriver.com]
>Sent: Friday, March 13, 2015 2:59 PM
>To: Kavanagh, Mark B
>Cc: dev at dpdk.org
>Subject: Re: [dpdk-dev] [PATCH v3] ABI: Add abi checking utility
>
>On Fri, Mar 13, 2015 at 02:25:17PM +, Kavanagh, Mark B wrote:
>> >On Fri, Mar 13, 2015 at 11:56:59AM +, Kavanagh, Mark B wrote:
>> >>
>> >>
>> >> >-Original Message-
>> >> >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
>> >> >Sent: Wednesday, March 4, 2015 4:27 PM
>> >> >To: dev at dpdk.org
>> >> >Subject: [dpdk-dev] [PATCH v3] ABI: Add abi checking utility
>> >> >
>>
>>
>> (snip)
>>
>> >> >+log "INFO" "Building DPDK $TAG1. This might take a moment"
>> >> >+make O=$TARGET > $VERBOSE 2>&1
>> >> >+
>> >> >+if [ $? -ne 0 ]
>> >> >+then
>> >> >+log "INFO" "THE BUILD FAILED.  ABORTING"
>> >>
>> >> If the build fails while TAG1 is checked out, the user must check out 
>> >> their original
>> >local branch manually. I'd prefer it if the script checked out 
>> >$CURRENT_BRANCH in the
>> >'cleanup_and_exit' function.
>> >>
>> >Sure, its in V4.
>>
>> Cool.
>>
>> >
>> >> Same applies to TAG2, if the user CTRL-C's out of the script, and to any 
>> >> other
>command
>> >that might fail when a particular branch/tag is checked out (for example, 
>> >the 'sed'
>> >commands fail when I run the script; however, they work when I run them on 
>> >the command
>> >line - I'm investigating this currently).
>> >>
>> >What does the log say?  Please post it here.  If it helps add a set -x to 
>> >the
>> >top of the script for additional verbosity.
>> >
>>
>> Hey Neil - this is the error, but it's not a problem with the script; 
>> presumably I'd
>cleaned my DPDK installation directory, so 'sed' couldn't find the defconfig 
>file:
>> "sed: can't read config/defconfig_x86_64-ivshmem-linuxapp-gcc/: Not a 
>> directory"
>>
>Actually, it looks to me like you added a trailing "/" to the end of the third
>argument on the script command line, so sed bombs when it tries to modify a
>directory instead of a file.  Try specifying:
>x86_64-ivshmem-linuxapp-gcc
>instead of
>x86_64-ivshmem-linuxapp-gcc/
>
>Neil

Nice catch - thanks!

>
>> Thanks,
>> Mark
>>
>> >Neil
>>
>>

[dpdk-dev] pktgen rx errors with intel 82599

[Matt Smith]

Hi,

I?ve been using DPDK pktgen 2.8.0 (built against DPDK 1.8.0 libraries) to send 
traffic on a server using an Intel 82599 (X520-2). Traffic gets sent out port 1 
through another server which also an Intel 82599 installed and is forwarded 
back into port 0. When I send using a single source and destination IP address, 
this works fine and packets arrive on port 0 at close to the maximum line rate. 

If I change port 1 to range mode and send traffic from a range of source IP 
addresses to a single destination IP address, for a second or two the display 
indicates that some packets were received on port 0 but then the rate of 
received packets on the display goes to 0 and all incoming packets on port 0 
are registered as rx errors.

The server that traffic is being forwarded through is running the ip_pipeline 
example app. I ruled this out as the source of the problem by sending directly 
from port 1 to port 0 of the pktgen box. The issue still occurs when the 
traffic is not being forwarded through the other box. Since ip_pipeline is able 
to receive the packets and forward them without getting rx errors and it?s 
running with the same model of NIC as pktgen is using, I checked to see if 
there were any differences in initialization of the rx port between ip_pipeline 
and pktgen. I noticed that pktgen has a setting that ip_pipeline doesn't:

const struct rte_eth_conf port_conf = {
.rxmode = {
.mq_mode = ETH_MQ_RX_RSS,

If I comment out the .mq_mode setting and rebuild pktgen, the problem no longer 
occurs and I now receive packets on port 0 at near line rate when testing from 
a range of source addresses.

I recall reading in the past that if a receive queue fills up on an 82599 , 
that receiving stalls for all of the other queues and no more packets can be 
received. Could that be happening with pktgen? Is there any debugging I can do 
to help track it down?

The command line I have been launching pktgen with is: 

pktgen -c f -n 3 -m 512 -- -p 0x3 -P -m 1.0,2.1

Thanks,

-Matt Smith

[dpdk-dev] [PATCH v2 15/15] eal: Enable Port Hotplug as default in Linux and BSD

[Iremonger, Bernard]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, March 12, 2015 10:18 AM
> To: dev at dpdk.org
> Cc: Iremonger, Bernard; Richardson, Bruce; Tetsuya Mukawa
> Subject: [PATCH v2 15/15] eal: Enable Port Hotplug as default in Linux and BSD
> 
> This patch removes CONFIG_RTE_LIBRTE_EAL_HOTPLUG option, and enables it as 
> default in both
> Linux and BSD.

Hi Tetsuya,

This patch should probably be split with the config changes as the first patch 
of this patch set.
The #ifdef RTE_LIBRTE_EAL_HOTPLUG changes should be no longer necessary as they 
will have been taken care of in the earlier patches (v2-11, v2-12, v2-13).
Maybe the  /lib/librte_eal/bsdapp/eal/rte_eal_version.map changes could be 
moved to one of the earlier bsd patches?

Regards,

Bernard.


> Also, to support port hotplug, rte_eal_pci_scan() and below missing symbols 
> should be exported to
> ethdev library.
>  - rte_eal_parse_devargs_str()
>  - rte_eal_pci_close_one()
>  - rte_eal_pci_probe_one()
>  - rte_eal_pci_scan()
>  - rte_eal_vdev_init()
>  - rte_eal_vdev_uninit()
> 
> Signed-off-by: Tetsuya Mukawa 
> ---
>  config/common_bsdapp  |  6 --
>  config/common_linuxapp|  5 -
>  lib/librte_eal/bsdapp/eal/eal_pci.c   |  6 +++---
>  lib/librte_eal/bsdapp/eal/rte_eal_version.map |  6 ++
>  lib/librte_eal/common/eal_common_dev.c|  2 --
>  lib/librte_eal/common/eal_common_pci.c|  8 
>  lib/librte_eal/common/eal_common_pci_uio.c|  2 --
>  lib/librte_eal/common/include/rte_pci.h   |  2 --
>  lib/librte_ether/rte_ethdev.c | 21 -
>  9 files changed, 9 insertions(+), 49 deletions(-)
> 
> diff --git a/config/common_bsdapp b/config/common_bsdapp index 
> 8ff4dc2..88b44e9 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -116,12 +116,6 @@ CONFIG_RTE_LIBRTE_EAL_BSDAPP=y
> CONFIG_RTE_LIBRTE_EAL_LINUXAPP=n
> 
>  #
> -# Compile Environment Abstraction Layer to support hotplug -# So far, 
> Hotplug functions only support
> linux -# -CONFIG_RTE_LIBRTE_EAL_HOTPLUG=n
> -
> -#
>  # Compile Environment Abstraction Layer to support Vmware TSC map  #
> CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
> diff --git a/config/common_linuxapp b/config/common_linuxapp index 
> 97f1c9e..f9c9780 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -114,11 +114,6 @@ CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE=0
>  CONFIG_RTE_LIBRTE_EAL_LINUXAPP=y
> 
>  #
> -# Compile Environment Abstraction Layer to support hotplug -# -
> CONFIG_RTE_LIBRTE_EAL_HOTPLUG=y
> -
> -#
>  # Compile Environment Abstraction Layer to support Vmware TSC map  #
> CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=y
> diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c 
> b/lib/librte_eal/bsdapp/eal/eal_pci.c
> index b6785d4..50c9544 100644
> --- a/lib/librte_eal/bsdapp/eal/eal_pci.c
> +++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
> @@ -305,8 +305,8 @@ skipdev:
>   * Scan the content of the PCI bus, and add the devices in the devices
>   * list. Call pci_scan_one() for each pci entry found.
>   */
> -static int
> -pci_scan(void)
> +int
> +rte_eal_pci_scan(void)
>  {
>   int fd;
>   unsigned dev_count = 0;
> @@ -362,7 +362,7 @@ rte_eal_pci_init(void)
>   if (internal_config.no_pci)
>   return 0;
> 
> - if (pci_scan() < 0) {
> + if (rte_eal_pci_scan() < 0) {
>   RTE_LOG(ERR, EAL, "%s(): Cannot scan PCI bus\n", __func__);
>   return -1;
>   }
> diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> index 67b6a6c..7e850a9 100644
> --- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> +++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> @@ -37,14 +37,20 @@ DPDK_2.0 {
>   rte_eal_lcore_role;
>   rte_eal_mp_remote_launch;
>   rte_eal_mp_wait_lcore;
> + rte_eal_parse_devargs_str;
> + rte_eal_pci_close_one;
>   rte_eal_pci_dump;
>   rte_eal_pci_probe;
> + rte_eal_pci_probe_one;
>   rte_eal_pci_register;
> + rte_eal_pci_scan;
>   rte_eal_pci_unregister;
>   rte_eal_process_type;
>   rte_eal_remote_launch;
>   rte_eal_tailq_lookup;
>   rte_eal_tailq_register;
> + rte_eal_vdev_init;
> + rte_eal_vdev_uninit;
>   rte_eal_wait_lcore;
>   rte_exit;
>   rte_get_hpet_cycles;
> diff --git a/lib/librte_eal/common/eal_common_dev.c 
> b/lib/librte_eal/common/eal_common_dev.c
> index 92a5a94..4089d66 100644
> --- a/lib/librte_eal/common/eal_common_dev.c
> +++ b/lib/librte_eal/common/eal_common_dev.c
> @@ -125,7 +125,6 @@ rte_eal_dev_init(void)
>   return 0;
>  }
> 
> -#ifdef RTE_LIBRTE_EAL_HOTPLUG
>  int
>  rte_eal_vdev_uninit(const char *name)
>  {
> @@ -151,4 +150,3 @@ rte_eal_vdev_uninit(const char *name)
>   RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
>   return -EINVAL;
>  }
> -#endif /* 

[dpdk-dev] Undefined reference to FUSE

[IñakiMurillo]

Hi Pablo,

Thank you very much, it worked for me.

But now I am trying to compile openvswicth after applying the next patch:

http://openvswitch.org/pipermail/dev/2015-January/050278.html

And it happends the same. I gues that I should ask in the ovs mail list,
but in case you know the answer I ask here.

Thank you in advanced.

Regards,

I?aki


El 13/03/15 a las 13:09, De Lara Guarch, Pablo escribi?:
> Hi I?aki,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of I?akiMurillo
>> Sent: Friday, March 13, 2015 11:50 AM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] Undefined reference to FUSE
>>
>> Hello,
>>
>> I am trying to compile the vhost example using DPDK 1.8.0. I have
>> installed fuse and libfuse-dev (as I am using Ubuntu). I have modified
>> config/common_linuxapp as follows:
>>
>> CONFIG_RTE_BUILD_COMBINE_LIBS=y
>> CONFIG_RTE_LIBRTE_VHOST=y
>>
>> Then, I compile DPDK 1.8.0 as follows:
>>
>> make config T=x86_64-native-linuxapp-gcc
>> make install T=x86_64-native-linuxapp-gcc
>>
>> And when it comes to compile vhost example I get errors about undefined
>> reference. To compile it I use theses intructions:
>>
>> export RTE_SDK=/path/to/dpdk-1.8.0
>> export RTE_TARGET=x86_64-native-linuxapp-gcc
>> make
>>
>> The log of the error is:
>>
>>
>> CC main.o
>>   LD vhost-switch
>> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
>> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
>> In function `vhost_net_ioctl':
>> vhost-net-cdev.c:(.text+0x3c): undefined reference to `fuse_req_ctx'
>> vhost-net-cdev.c:(.text+0xd5): undefined reference to
>> `fuse_reply_ioctl_retry'
>> vhost-net-cdev.c:(.text+0x185): undefined reference to `fuse_reply_ioctl'
>> vhost-net-cdev.c:(.text+0x253): undefined reference to
>> `fuse_reply_ioctl_retry'
>> vhost-net-cdev.c:(.text+0x2c2): undefined reference to `fuse_reply_ioctl'
>> vhost-net-cdev.c:(.text+0x30a): undefined reference to `fuse_reply_err'
>> vhost-net-cdev.c:(.text+0x359): undefined reference to
>> `fuse_reply_ioctl_retry'
>> vhost-net-cdev.c:(.text+0x472): undefined reference to `fuse_reply_ioctl'
>> vhost-net-cdev.c:(.text+0x49f): undefined reference to `fuse_reply_ioctl'
>> vhost-net-cdev.c:(.text+0x4ea): undefined reference to `fuse_reply_ioctl'
>> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
>> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
>> In function `vhost_net_release':
>> vhost-net-cdev.c:(.text+0x515): undefined reference to `fuse_req_ctx'
>> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
>> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
>> In function `vhost_net_open':
>> vhost-net-cdev.c:(.text+0x58d): undefined reference to `fuse_req_ctx'
>> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
>> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
>> In function `rte_vhost_driver_register':
>> vhost-net-cdev.c:(.text+0x828): undefined reference to
>> `cuse_lowlevel_setup'
>> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
>> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
>> In function `rte_vhost_driver_session_start':
>> vhost-net-cdev.c:(.text+0x86c): undefined reference to `fuse_session_loop'
>> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
>> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
>> In function `vhost_net_release':
>> vhost-net-cdev.c:(.text+0x55b): undefined reference to `fuse_reply_err'
>> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
>> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
>> In function `vhost_net_open':
>> vhost-net-cdev.c:(.text+0x5d3): undefined reference to `fuse_reply_open'
>> vhost-net-cdev.c:(.text+0x5ef): undefined reference to `fuse_reply_err'
>> collect2: ld returned 1 exit status
>> make[1]: *** [vhost-switch] Error 1
>> make: *** [all] Error 2
>>
>>
>> Can anyone help me?
> This was fixed after 1.8.0, on this patch:
> http://dpdk.org/dev/patchwork/patch/2603/
>
> You can either apply it yourself or get the latest code using git.
>
> Regards,
> Pablo
>> Thank you in advanced.
>>

[dpdk-dev] [ dpdk-pktgen execution issue ] Error: Didn't find any ports to use

[Arkajit Ghosh]

 Hi,

Can you please guide me as I am facing the below issue during execution of 
DPDK-Pktgen. 

Thanks & Regards
Arkajit Ghosh


-Arkajit Ghosh/DEL/TCS wrote: -
To: "Wiles, Keith" 
From: Arkajit Ghosh/DEL/TCS
Date: 03/11/2015 02:33PM
Subject: Re: [dpdk-dev] [ dpdk-pktgen execution issue ] Error: Didn't find any 
ports to use

 Hi,

Can you please suggest how to proceed.


Thanks & Regards
Arkajit Ghosh


-Arkajit Ghosh/DEL/TCS wrote: -
To: "Wiles, Keith" 
From: Arkajit Ghosh/DEL/TCS
Date: 03/10/2015 12:49PM
Subject: Re: [dpdk-dev] [ dpdk-pktgen execution issue ] Error: Didn't find any 
ports to use

 Hi Keith,

Sorry for replying after after long days as I was involved in different module 
so not able to to track down this issue. Now once again back to this module.? 
This time I had executed pktgen-DPDK in Host machine and Bridge and DPDK ports 
configuration done in guest machine (VM). Please find attachment for bridge and 
dpdk-ports creation in guest machine. 

Facing same issue "ports not found" and as well as this below issue:

#
EAL: Support maximum 64 logical core(s) by configuration.
EAL: Detected 24 lcore(s)
EAL: Auto-detected process type: PRIMARY
EAL:?? cannot open VFIO container, error 2 (No such file or directory)
EAL: VFIO support could not be initialized
EAL: Setting up memory...
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f5970c0 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f597080 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f597040 (size = 0x20)
EAL: Requesting 1 pages of size 2MB from socket 0
EAL: rte_eal_common_log_init(): cannot create log_history mempool
PANIC in rte_eal_init():
Cannot init logs
6: [./app/build/pktgen() [0x422df3]]
5: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f5970f06ec5]]
4: [./app/build/pktgen(main+0x127) [0x422547]]
3: [./app/build/pktgen(rte_eal_init+0x1d87) [0x4b0207]]
2: [./app/build/pktgen(__rte_panic+0xc9) [0x4222c6]]
1: [./app/build/pktgen(rte_dump_stack+0x18) [0x4b7478]]
Aborted (core dumped)
###

Here is the output (As requested last mail chain): lspci | grep Ethernet

01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit 
Ethernet PCIe
01:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit 
Ethernet PCIe
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit 
Ethernet PCIe (rev 01)
02:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit 
Ethernet PCIe (rev 01)
02:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit 
Ethernet PCIe (rev 01)
02:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit 
Ethernet PCIe (rev 01)

../../../dpdk/tools/dpdk_nic_bind.py --status

Network devices using DPDK-compatible driver



Network devices using kernel driver
===
:01:00.0 'NetXtreme BCM5720 Gigabit Ethernet PCIe' if=eth0 drv=tg3 unused= 
:01:00.1 'NetXtreme BCM5720 Gigabit Ethernet PCIe' if=eth1 drv=tg3 unused= 
:02:00.0 'NetXtreme BCM5719 Gigabit Ethernet PCIe' if=eth2 drv=tg3 unused= 
:02:00.1 'NetXtreme BCM5719 Gigabit Ethernet PCIe' if=eth3 drv=tg3 unused= 
:02:00.2 'NetXtreme BCM5719 Gigabit Ethernet PCIe' if=eth4 drv=tg3 unused= 
:02:00.3 'NetXtreme BCM5719 Gigabit Ethernet PCIe' if=eth5 drv=tg3 unused= 
*Active*

Other network devices
=


Please suggest how to proceed.

Thanks & Regards
Arkajit Ghosh


-"Wiles, Keith"  wrote: -
To: Arkajit Ghosh , "dev at dpdk.org" 
From: "Wiles, Keith" 
Date: 02/02/2015 08:17PM
Subject: Re: [dpdk-dev] [ dpdk-pktgen execution issue ] Error: Didn't find any 
ports to use


On 2/2/15, 3:10 AM, "Arkajit Ghosh"  wrote:

>
>Hi,
>
>Facing issue during the execution of dpdk-pktgen in VM. Please find the
>below details:
>
>Setup details:
>
>> Executing in Guest machine (VM).
>> Having 2 logical core.
>>Configured 2048 km hugepages
>>Number of processor: 2
>
>Scenario to verify: Generate some packets by dpdk-pktgen and then one
>dpdk-ports will work as a RX end and other one will be as TX end to
>handle the incoming packets and do the required action.
>
>dpdk-Ports creation: Here is the snapshot
>
>root at tcs-VirtualBox:/usr/src/pktgen-DPDK/dpdk/examples/pktgen#
>/usr/src/ovs/utilities/ovs-vsctl show
>c2245b31-3ca1-49c6-b4c5-1041be5b9dc4
> ? ?Bridge "ovsbr0"
> ? ? ? ?Port "dpdkr2"
> ? ? ? ? ? ?Interface "dpdkr2"
> ? ? ? ? ? ? ? ?type: dpdk
> ? ? ? ? ? ? ? ?options: {port="2"}
> ? ? ? ?Port "ovsbr0"
> ? ? ? ? ? ?Interface "ovsbr0"
> ? ? ? ? ? ? ? 

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Gonzalez Monroy, Sergio]

On 13/03/2015 15:18, Neil Horman wrote:
> On Fri, Mar 13, 2015 at 04:12:35PM +0200, Stefan Puiu wrote:
>> Hi,
>>
>> 2 cents from a DPDK library user - I make 2 changes to the default
>> linux+gcc configuration: combine libraries and build shared libraries
>> (since I want 2 instances of the app, it didn't make sense to me to
>> link statically). I tried working with the individual libs, but adding
>> all of them with --start-group/-end-group just seemed so much more
>> painful than simply linking against one lib. I know there are some
>> Makefile variables to help with this, but I use scons for building my
>> app, so that doesn't help much.
>>
>> Of course, if that can be achieved easily after building all the
>> libraries, that's fine. But I think combining the libs makes a lot of
>> sense in many cases.
>>
> So do it, create a linker script that internally contains one line:
> INPUT(-lrte_eal -lrte_alarm -lrte_mempool ... etc)
>
> Name the file libdpdk.so
>
> then when you build your app, just link -ldpdk
>
> Done.
>
> Neil

Plus I believe that as it currently stands, building combined shared 
libraries will be broken
the moment we have different versions of any API because the linking for 
the combined lib
does not use a version map.

Sergio
>> Thanks,
>> Stefan.
>>
>> On Fri, Mar 13, 2015 at 3:17 PM, Neil Horman  
>> wrote:
>>> On Fri, Mar 13, 2015 at 11:48:59AM +, Gonzalez Monroy, Sergio wrote:
 On 13/03/2015 11:34, Kavanagh, Mark B wrote:
>> On 13/03/2015 10:49, Kavanagh, Mark B wrote:
 ---
 config/common_bsdapp|   6 --
 config/common_linuxapp  |   6 --
 config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
 lib/Makefile|   1 -
 mk/rte.app.mk   |  12 
 mk/rte.lib.mk   |  35 --
 mk/rte.sdkbuild.mk  |   3 -
 mk/rte.sharelib.mk  | 101 
 
 mk/rte.vars.mk  |   9 ---
 9 files changed, 175 deletions(-)
 delete mode 100644 mk/rte.sharelib.mk

 diff --git a/config/common_bsdapp b/config/common_bsdapp
 index 8ff4dc2..7ee5ecf 100644
 --- a/config/common_bsdapp
 +++ b/config/common_bsdapp
 @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
 CONFIG_RTE_BUILD_SHARED_LIB=n

 #
 -# Combine to one single library
 -#
 -CONFIG_RTE_BUILD_COMBINE_LIBS=n
 -CONFIG_RTE_LIBNAME=intel_dpdk
>>> Hi Sergio,
>>>
>>> Removing these options breaks compatibility with OVS. While it may be 
>>> feasible to link
>> to individual static libraries, in our experience, a single combined 
>> library provides a
>> much more convenient way of linking.
>>> Thanks,
>>> Mark
>>>
 -
> (snip)
>
>
 -endif
 -
 -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
 -ifeq ($(RTE_LIBNAME),)
 -RTE_LIBNAME := intel_dpdk
 endif

 # RTE_TARGET is deducted from config when we are building the SDK.
 --
 1.9.3
>> Hi Mark,
>>
>> How does this patch break compatibility with OVS?
>>
>> Thanks,
>> Sergio
> Hey Sergio,
>
> We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to 
> build a single static DPDK library, named 'libintel_dpdk.a', which OVS 
> links against. Removing the combined library option breaks compatibility 
> with any application that links against the combined DPDK library.
>
> Is there a strong technical motivation for removing these options?
>
> Thanks,
> Mark
  From a shared library point of view, it just does not make sense to have
 applications linked against a 'combined' library that may have different
 features built in it.

 Removing these options, aside from the obvious 'less build config option',
 it simplifies maintenance of makefiles as we currently have a separated
 makefile with specific rules just for combined library.

 It is pretty straight forward to build a single combined archive out of
 multiple archives, would it be acceptable to have a script to do this?

 Thanks,
 Sergio

>>> +1
>>>
>>> For the static case, its easy to do a post build combination of archives.  
>>> For
>>> the shared library case, its equally easy to simply create a linker scripts 
>>> call
>>> .so that pulls in all the individual libraries.
>>>
>>> Neil
>>>

[dpdk-dev] [PATCH v2 13/15] eal: Consolidate pci_map/unmap_resource() of linuxapp and bsdapp

[Iremonger, Bernard]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, March 12, 2015 10:18 AM
> To: dev at dpdk.org
> Cc: Iremonger, Bernard; Richardson, Bruce; Tetsuya Mukawa
> Subject: [PATCH v2 13/15] eal: Consolidate pci_map/unmap_resource() of 
> linuxapp and bsdapp
> 
> The patch consolidates below functions, and implemented in common eal code.
>  - pci_map_resource()
>  - pci_unmap_resource()
> 
> Signed-off-by: Tetsuya Mukawa 
> ---
>  lib/librte_eal/bsdapp/eal/eal_pci.c| 24 -
>  lib/librte_eal/common/eal_common_pci.c | 43 
> ++
>  lib/librte_eal/common/include/rte_pci.h| 11 
>  lib/librte_eal/linuxapp/eal/eal_pci.c  | 42 -
>  lib/librte_eal/linuxapp/eal/eal_pci_init.h |  5 
>  5 files changed, 54 insertions(+), 71 deletions(-)
> 
> diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c 
> b/lib/librte_eal/bsdapp/eal/eal_pci.c
> index 1e42e42..d7d6439 100644
> --- a/lib/librte_eal/bsdapp/eal/eal_pci.c
> +++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
> @@ -46,7 +46,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -96,29 +95,6 @@ pci_unbind_kernel_driver(struct rte_pci_device *dev 
> __rte_unused)
>   return -ENOTSUP;
>  }
> 
> -/* map a particular resource from a file */ -static void * 
> -pci_map_resource(void *requested_addr,
> int fd, off_t offset, size_t size,
> -  int additional_flags)
> -{
> - void *mapaddr;
> -
> - /* Map the PCI memory resource of device */
> - mapaddr = mmap(requested_addr, size, PROT_READ | PROT_WRITE,
> - MAP_SHARED | additional_flags, fd, offset);
> - if (mapaddr == MAP_FAILED) {
> - RTE_LOG(ERR, EAL,
> - "%s(): cannot mmap(%d, %p, 0x%lx, 0x%lx): %s (%p)\n",
> - __func__, fd, requested_addr,
> - (unsigned long)size, (unsigned long)offset,
> - strerror(errno), mapaddr);
> - } else {
> - RTE_LOG(DEBUG, EAL, "  PCI memory mapped at %p\n", mapaddr);
> - }
> -
> - return mapaddr;
> -}
> -
>  static int
>  pci_uio_map_secondary(struct rte_pci_device *dev)  { diff --git
> a/lib/librte_eal/common/eal_common_pci.c 
> b/lib/librte_eal/common/eal_common_pci.c
> index 726026f..6d98194 100644
> --- a/lib/librte_eal/common/eal_common_pci.c
> +++ b/lib/librte_eal/common/eal_common_pci.c
> @@ -67,6 +67,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -98,6 +99,48 @@ static struct rte_devargs *pci_devargs_lookup(struct 
> rte_pci_device *dev)
>   return NULL;
>  }
> 
> +/* map a particular resource from a file */ void *
> +pci_map_resource(void *requested_addr, int fd, off_t offset, size_t size,
> +  int additional_flags)
> +{
> + void *mapaddr;
> +
> + /* Map the PCI memory resource of device */
> + mapaddr = mmap(requested_addr, size, PROT_READ | PROT_WRITE,
> + MAP_SHARED | additional_flags, fd, offset);
> + if (mapaddr == MAP_FAILED) {
> + RTE_LOG(ERR, EAL,
> + "%s(): cannot mmap(%d, %p, 0x%lx, 0x%lx): %s (%p)\n",
> + __func__, fd, requested_addr,
> + (unsigned long)size, (unsigned long)offset,
> + strerror(errno), mapaddr);
> + } else {
> + RTE_LOG(DEBUG, EAL, "  PCI memory mapped at %p\n", mapaddr);
> + }
> +
> + return mapaddr;
> +}
> +
> +#ifdef RTE_LIBRTE_EAL_HOTPLUG

Hi Tetsuya,

Can #ifdef RTE_LIBRTE_EAL_HOTPLUG be removed as code is now in eal_common_pci.c 
?

Regards,

Bernard.

> +/* unmap a particular resource */
> +void
> +pci_unmap_resource(void *requested_addr, size_t size) {
> + if (requested_addr == NULL)
> + return;
> +
> + /* Unmap the PCI memory resource of device */
> + if (munmap(requested_addr, size)) {
> + RTE_LOG(ERR, EAL, "%s(): cannot munmap(%p, 0x%lx): %s\n",
> + __func__, requested_addr, (unsigned long)size,
> + strerror(errno));
> + } else
> + RTE_LOG(DEBUG, EAL, "  PCI memory unmapped at %p\n",
> + requested_addr);
> +}
> +#endif /* RTE_LIBRTE_EAL_HOTPLUG */
Hi Tetsuya,

Can #endif  be removed too as code is now in eal_common_pci.c ?

Regards,

Bernard.

> +
>  /* Map pci device */
>  static int
>  pci_map_device(struct rte_pci_device *dev) diff --git 
> a/lib/librte_eal/common/include/rte_pci.h
> b/lib/librte_eal/common/include/rte_pci.h
> index 47345b8..d3b883e 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -363,8 +363,19 @@ int rte_eal_pci_scan(void);
>   */
>  int rte_eal_pci_probe(void);
> 
> +/**
> + * Map pci resouce.
> + */
> +void *pci_map_resource(void *requested_addr, int fd, off_t offset,
> + size_t size, 

[dpdk-dev] [PATCH v2 12/15] eal: Consolidate pci_map/unmap_device() of linuxapp and bsdapp

[Iremonger, Bernard]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, March 12, 2015 10:18 AM
> To: dev at dpdk.org
> Cc: Iremonger, Bernard; Richardson, Bruce; Tetsuya Mukawa
> Subject: [PATCH v2 12/15] eal: Consolidate pci_map/unmap_device() of linuxapp 
> and bsdapp
> 
> The patch consolidates below functions, and implemented in common eal code.
>  - pci_map_device()
>  - pci_unmap_device()
> 
> Signed-off-by: Tetsuya Mukawa 
> ---
>  lib/librte_eal/bsdapp/eal/eal_pci.c | 12 +++
>  lib/librte_eal/common/eal_common_pci.c  | 57 
> +
>  lib/librte_eal/common/eal_private.h |  4 +--
>  lib/librte_eal/common/include/rte_pci.h |  1 +
>  lib/librte_eal/linuxapp/eal/eal_pci.c   | 55 ---
>  lib/librte_ether/rte_ethdev.c   |  1 +
>  6 files changed, 65 insertions(+), 65 deletions(-)
> 
> diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c 
> b/lib/librte_eal/bsdapp/eal/eal_pci.c
> index 3778763..1e42e42 100644
> --- a/lib/librte_eal/bsdapp/eal/eal_pci.c
> +++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
> @@ -280,7 +280,7 @@ fail:
>  }
> 
>  /* map the PCI resource of a PCI device in virtual memory */ -static int
> +int
>  pci_uio_map_resource(struct rte_pci_device *dev)  {
>   int i, map_idx, ret;
> @@ -364,6 +364,9 @@ pci_scan_one(int dev_pci_fd, struct pci_conf *conf)
>   /* FreeBSD has no NUMA support (yet) */
>   dev->numa_node = 0;
> 
> + /* FreeBSD has only one pass through driver */
> + dev->pt_driver = RTE_PT_NIC_UIO;
> +
>   /* parse resources */
>   switch (conf->pc_hdr & PCIM_HDRTYPE) {
>   case PCIM_HDRTYPE_NORMAL:
> @@ -429,13 +432,6 @@ skipdev:
>   return 0;
>  }
> 
> -/* Map pci device */
> -int
> -pci_map_device(struct rte_pci_device *dev) -{
> - return pci_uio_map_resource(dev);
> -}
> -
>  /*
>   * Scan the content of the PCI bus, and add the devices in the devices
>   * list. Call pci_scan_one() for each pci entry found.
> diff --git a/lib/librte_eal/common/eal_common_pci.c 
> b/lib/librte_eal/common/eal_common_pci.c
> index 538b2d9..726026f 100644
> --- a/lib/librte_eal/common/eal_common_pci.c
> +++ b/lib/librte_eal/common/eal_common_pci.c
> @@ -98,6 +98,63 @@ static struct rte_devargs *pci_devargs_lookup(struct 
> rte_pci_device *dev)
>   return NULL;
>  }
> 
> +/* Map pci device */
> +static int
> +pci_map_device(struct rte_pci_device *dev) {
> + int ret = -1;
> +
> + /* try mapping the NIC resources using VFIO if it exists */
> + switch (dev->pt_driver) {
> + case RTE_PT_VFIO:
> +#ifdef VFIO_PRESENT
> + if (pci_vfio_is_enabled())
> + ret = pci_vfio_map_resource(dev);
> +#endif
> + break;
> + case RTE_PT_IGB_UIO:
> + case RTE_PT_UIO_GENERIC:
> + case RTE_PT_NIC_UIO:
> + /* map resources for devices that use uio */
> + ret = pci_uio_map_resource(dev);
> + break;
> + default:
> + RTE_LOG(DEBUG, EAL, "  Not managed by known pt driver,"
> + " skipped\n");
> + ret = 1;
> + break;
> + }
> +
> + return ret;
> +}
> +
> +#ifdef RTE_LIBRTE_EAL_HOTPLUG

Hi Tetsuya,

Can  #ifdef RTE_LIBRTE_EAL_HOTPLUG be removed as code is now in 
eal_common_pci.c ?

Regards,

Bernard.

> +/* Unmap pci device */
> +static void
> +pci_unmap_device(struct rte_pci_device *dev) {
> + if (dev == NULL)
> + return;
> +
> + /* try unmapping the NIC resources using VFIO if it exists */
> + switch (dev->pt_driver) {
> + case RTE_PT_VFIO:
> + RTE_LOG(ERR, EAL, "Hotplug doesn't support vfio yet\n");
> + break;
> + case RTE_PT_IGB_UIO:
> + case RTE_PT_UIO_GENERIC:
> + case RTE_PT_NIC_UIO:
> + /* unmap resources for devices that use uio */
> + pci_uio_unmap_resource(dev);
> + break;
> + default:
> + RTE_LOG(DEBUG, EAL, "  Not managed by known pt driver,"
> + " skipped\n");
> + break;
> + }
> +}
> +#endif /* RTE_LIBRTE_EAL_HOTPLUG */

Hi Tetsuya,

Can  #endif be removed  too as code is now in eal_common_pci.c ?

Regards,

Bernard.


> +
>  /*
>   * If vendor/device ID match, call the devinit() function of the
>   * driver.
> diff --git a/lib/librte_eal/common/eal_private.h 
> b/lib/librte_eal/common/eal_private.h
> index fe2c596..badb55c 100644
> --- a/lib/librte_eal/common/eal_private.h
> +++ b/lib/librte_eal/common/eal_private.h
> @@ -171,14 +171,14 @@ int pci_unbind_kernel_driver(struct rte_pci_device 
> *dev);
>   * @return
>   *   0 on success, negative on error
>   */
> -int pci_map_device(struct rte_pci_device *dev);
> +int pci_uio_map_resource(struct rte_pci_device *dev);
> 
>  /**
>   * Unmap this device
>   *
>   * This function is private to EAL.
>   */
> -void pci_unmap_device(struct rte_pci_device *dev);
> +void pci_uio_unmap_resource(struct rte_pci_device 

[dpdk-dev] [PATCH v3 0/3]: bug fixes in the ixgbe PF PMD Rx flow

[Vladislav Zolotarov]

On Mar 13, 2015 2:51 PM, "Ananyev, Konstantin" 
wrote:
>
> Hi Vlad,
>
> > -Original Message-
> > From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
> > Sent: Friday, March 13, 2015 11:52 AM
> > To: Ananyev, Konstantin; dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3 0/3]: bug fixes in the ixgbe PF PMD
Rx flow
> >
> >
> >
> > On 03/13/15 13:07, Ananyev, Konstantin wrote:
> > >
> > >> -Original Message-
> > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
> > >> Sent: Thursday, March 12, 2015 9:17 PM
> > >> To: dev at dpdk.org
> > >> Subject: [dpdk-dev] [PATCH v3 0/3]: bug fixes in the ixgbe PF PMD Rx
flow
> > >>
> > >> This series contains some bug fixes that were found during my work
on the ixgbe LRO
> > >> patches. Sending this series separately on Thomas request so that it
may be integrated
> > >> into the 2.0 release.
> > >>
> > >> New in v3:
> > >> - Adjusted to the new structs naming in the master.
> > >> - Fixed rx_bulk_alloc_allowed and rx_vec_allowed initialization:
> > >>- Don't set them to FALSE in rte_eth_dev_stop() flow - the
following
> > >>  rte_eth_dev_start() will need them.
> > >>- Reset them to TRUE in rte_eth_dev_configure() and not in a
probe() flow.
> > >>  This will ensure the proper behaviour if port is
re-configured.
> > >> - Rename:
> > >>- ixgbe_rx_vec_condition_check() ->
ixgbe_rx_vec_dev_conf_condition_check()
> > >>- set_rx_function() -> ixgbe_set_rx_function()
> > >> - Clean up the logic in ixgbe_set_rx_function().
> > >> - Define stubs with __attribute__((weak)) instead of using
#ifdef's.
> > >> - Styling: beautify ixgbe_rxtx.h a bit.
> > >>
> > >> New in v2:
> > >> - Fixed a compilation failure.
> > >>
> > >>
> > >> Vlad Zolotarov (3):
> > >>ixgbe: Use the rte_le_to_cpu_xx()/rte_cpu_to_le_xx() when
> > >>  reading/setting HW ring descriptor fields
> > >>ixgbe: Bug fix: Properly configure Rx CRC stripping for x540
devices
> > >>ixgbe: Unify the rx_pkt_bulk callback initialization
> > >>
> > >>   lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h |   2 +
> > >>   lib/librte_pmd_ixgbe/ixgbe_ethdev.c |  13 +-
> > >>   lib/librte_pmd_ixgbe/ixgbe_rxtx.c   | 216
+---
> > >>   lib/librte_pmd_ixgbe/ixgbe_rxtx.h   |  28 -
> > >>   lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c   |   2 +-
> > >>   5 files changed, 183 insertions(+), 78 deletions(-)
> > >>
> > > Acked-by: Konstantin Ananyev 
> > >
> > > Just one nit:
> > >
> > > +int __attribute__((weak)) ixgbe_rxq_vec_setup(
> > > +   struct ixgbe_rx_queue __rte_unused *rxq)
> > > +{
> > >
> > > Please use notation:
> > > int __attribute__((weak))
> > > ixgbe_rxq_vec_setup(struct ixgbe_rx_queue __rte_unused *rxq)
> > >
> > > To keep up with the rest of the code, plus makes much easier to read.
> >
> > I took an example from kni/ethtool/igb/kcompat.h for a template but no
> > problem.
> > Do u want me to respin or it's ok? I will use this format for the
> > follow-up LRO patch anyway...
>
> Doing that in LRO patch set is ok.
> No need for respin that one, I think.

Great! Thanks a lot for reviewing this.

Thomas, it seems like ixgbe maintainer gives this series a green light!..
;)

> Konstantin
>
> >
> > >
> > >> --
> > >> 2.1.0
>

[dpdk-dev] [PATCH] common/rte_memcpy: Fix x86intrin.h missed

[Michael Qiu]

rte_memcpy.h(46): catastrophic error: cannot open source file "x86intrin.h"

For icc and old gcc, this header is not included.

Signed-off-by: Michael Qiu 
---
 lib/librte_eal/common/include/arch/x86/rte_memcpy.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h 
b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
index ac72069..bd10d36 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
@@ -43,7 +43,27 @@
 #include 
 #include 
 #include 
+#if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
+
+#ifdef __SSE__
+#include 
+#endif
+
+#ifdef __SSE2__
+#include 
+#endif
+
+#if defined(__SSE4_2__) || defined(__SSE4_1__)
+#include 
+#endif
+
+#if defined(__AVX__)
+#include 
+#endif
+
+#else
 #include 
+#endif

 #ifdef __cplusplus
 extern "C" {
-- 
1.9.3

[dpdk-dev] PMD architecture related to code

[Bruce Richardson]

On Fri, Mar 13, 2015 at 04:45:47AM +, kuldeep.samasi at wipro.com wrote:
> Hi Developer Team ,
> 
> 
> I am trying add new functionality on Poll Mode driver .
> But I don't have idea how packets are coming to kernel mode and going to user 
> space and doing packet processing DPDK .

The packets never go into the kernel when DPDK is in use. Instead the DPDK PMD
configures the NIC to DMA the packets directly into userspace buffers. Hence the
high performance.

/Bruce

> 
> I need suggestion on which file the PMD architecture defined .
> 
> 
> 
> Regards ,
> Kuldeep
> The information contained in this electronic message and any attachments to 
> this message are intended for the exclusive use of the addressee(s) and may 
> contain proprietary, confidential or privileged information. If you are not 
> the intended recipient, you should not disseminate, distribute or copy this 
> e-mail. Please notify the sender immediately and destroy all copies of this 
> message and any attachments. WARNING: Computer viruses can be transmitted via 
> email. The recipient should check this email and any attachments for the 
> presence of viruses. The company accepts no liability for any damage caused 
> by any virus transmitted by this email. www.wipro.com

[dpdk-dev] [PATCH] ethdev: additional parameter in RX callback

[Bruce Richardson]

On Fri, Mar 13, 2015 at 09:45:14AM -0400, Neil Horman wrote:
> On Fri, Mar 13, 2015 at 09:41:33AM +, Bruce Richardson wrote:
> > On Thu, Mar 12, 2015 at 03:15:40PM -0400, Neil Horman wrote:
> > > On Thu, Mar 12, 2015 at 04:54:27PM +, John McNamara wrote:
> > > > 
> > > > This patch is a minor extension to the recent patchset for RX/TX 
> > > > callbacks
> > > > based on feedback from users implementing solutions based on it.
> > > > 
> > > > The patch adds a new parameter to the RX callback to pass in the number 
> > > > of
> > > > available RX packets in addition to the number of dequeued packets.
> > > > This provides the RX callback functions with additional information
> > > > that can be used to decide how packets from a burst are handled.
> > > > 
> > > > The TX callback doesn't require this additional parameter so the RX
> > > > and TX callbacks no longer have the same function parameters. As such
> > > > the single RX/TX callback has been refactored into two separate 
> > > > callbacks.
> > > > 
> > > > Since this is an API change we hope it can be included in 2.0.0 to avoid
> > > > changing the API in a subsequent release.
> > > > 
> > > > 
> > > > John McNamara (1):
> > > >   ethdev: added additional packet count parameter to RX callbacks
> > > > 
> > > >  examples/rxtx_callbacks/main.c |3 +-
> > > >  lib/librte_ether/rte_ethdev.c  |8 ++--
> > > >  lib/librte_ether/rte_ethdev.h  |   74 
> > > > ++--
> > > >  3 files changed, 54 insertions(+), 31 deletions(-)
> > > > 
> > > > -- 
> > > > 1.7.4.1
> > > > 
> > > > 
> > > 
> > > 
> > > Well, we're well past the new feature phase of this cycle, so I would say 
> > > NACK.
> > > I would also suggest that you don't need to modify ABI to accomodate this
> > > feature.  Instead just document the pkts array to be terminated by a 
> > > reserved
> > > value, so that the callback can determine its size dynamically.  You could
> > > alternatively create a new api call that allows you to retrieve that 
> > > information
> > > from the context of the callback.
> > > 
> > > Neil
> > > 
> > 
> > Yes, I would agree we are past the new feature phase. However, given that we
> > are making a change to the API, and a fairly small change too - adding one 
> > extra
> > parameter - we think that the benefit of including this now outweighs any 
> > risk
> > of merging the patch. It seems a bit crazy to ship a release with a new API 
> > and
> > then immediately change the API straight after release. Is it not better to
> > take the received feedback on the API and fix/improve it pre-release before 
> > it
> > gets set-in-stone?
> > 
> > /Bruce
> > 
> > 
> 
> See above, the API doesn't need to change at all to accomodate this as far as 
> I
> can see.
> 
> Neil
Yes, there are alternative ways to see about accomplishing the same thing, but
they are not nearly as clear as adding in the extra param. That's why we'd like
to see this change go in before release, if possible. If it doesn't make 2.0
I'd like to see it in 2.1, but at the cost of having an API change and the
additional versionning and deprecation that ensues.

Regards,
/Bruce

[dpdk-dev] [PATCH v2 04/15] eal: Fix needless incrementation of pci_map_addr

[Iremonger, Bernard]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, March 12, 2015 10:18 AM
> To: dev at dpdk.org
> Cc: Iremonger, Bernard; Richardson, Bruce; Tetsuya Mukawa
> Subject: [PATCH v2 04/15] eal: Fix needless incrementation of pci_map_addr
> 
> When pci_map_resource() is failed, mapaddr will be MAP_FAILED.
> In this case, pci_map_addr should not be incremented.
> The patch fixes it. Also, fix below.
>  - To shrink code, move close().
>  - Remove fail variable.
> 
> Signed-off-by: Tetsuya Mukawa 
> ---
>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c 
> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> index 901f277..2741c62 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> @@ -337,7 +337,6 @@ pci_uio_map_resource(struct rte_pci_device *dev)
>   maps = uio_res->maps;
>   for (i = 0, map_idx = 0; i != PCI_MAX_RESOURCE; i++) {
>   int fd;
> - int fail = 0;
> 
>   /* skip empty BAR */
>   phaddr = dev->mem_resource[i].phys_addr; @@ -371,18 +370,13 @@
> pci_uio_map_resource(struct rte_pci_device *dev)
> 
>   mapaddr = pci_map_resource(pci_map_addr, fd, 0,
>   (size_t)dev->mem_resource[i].len, 0);
> + close(fd);
>   if (mapaddr == MAP_FAILED)
> - fail = 1;
> + goto fail1;
> 
>   pci_map_addr = RTE_PTR_ADD(mapaddr,
>   (size_t)dev->mem_resource[i].len);
> 
> - if (fail) {
> - close(fd);
> - goto fail1;
> - }
> - close(fd);
> -
>   maps[map_idx].phaddr = dev->mem_resource[i].phys_addr;
>   maps[map_idx].size = dev->mem_resource[i].len;
>   maps[map_idx].addr = mapaddr;
> --
> 1.9.1
Hi Tetsuya,

This patch could be squashed into patch 3.

Regards,

Bernard.

[dpdk-dev] Undefined reference to FUSE

[Traynor, Kevin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of I?akiMurillo
> Sent: Friday, March 13, 2015 2:39 PM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Subject: Re: [dpdk-dev] Undefined reference to FUSE
> 
> Hi Pablo,
> 
> Thank you very much, it worked for me.
> 
> But now I am trying to compile openvswicth after applying the next patch:
> 
> http://openvswitch.org/pipermail/dev/2015-January/050278.html
> 
> And it happends the same. I gues that I should ask in the ovs mail list,
> but in case you know the answer I ask here.

For ovs, if you use the head of master and the latest vhost patch, you 
shouldn't see that error
http://openvswitch.org/pipermail/dev/2015-March/052061.html


> 
> Thank you in advanced.
> 
> Regards,
> 
> I?aki
> 
> 
> El 13/03/15 a las 13:09, De Lara Guarch, Pablo escribi?:
> > Hi I?aki,
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of I?akiMurillo
> >> Sent: Friday, March 13, 2015 11:50 AM
> >> To: dev at dpdk.org
> >> Subject: [dpdk-dev] Undefined reference to FUSE
> >>
> >> Hello,
> >>
> >> I am trying to compile the vhost example using DPDK 1.8.0. I have
> >> installed fuse and libfuse-dev (as I am using Ubuntu). I have modified
> >> config/common_linuxapp as follows:
> >>
> >> CONFIG_RTE_BUILD_COMBINE_LIBS=y
> >> CONFIG_RTE_LIBRTE_VHOST=y
> >>
> >> Then, I compile DPDK 1.8.0 as follows:
> >>
> >> make config T=x86_64-native-linuxapp-gcc
> >> make install T=x86_64-native-linuxapp-gcc
> >>
> >> And when it comes to compile vhost example I get errors about undefined
> >> reference. To compile it I use theses intructions:
> >>
> >> export RTE_SDK=/path/to/dpdk-1.8.0
> >> export RTE_TARGET=x86_64-native-linuxapp-gcc
> >> make
> >>
> >> The log of the error is:
> >>
> >>
> >> CC main.o
> >>   LD vhost-switch
> >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> >> In function `vhost_net_ioctl':
> >> vhost-net-cdev.c:(.text+0x3c): undefined reference to `fuse_req_ctx'
> >> vhost-net-cdev.c:(.text+0xd5): undefined reference to
> >> `fuse_reply_ioctl_retry'
> >> vhost-net-cdev.c:(.text+0x185): undefined reference to `fuse_reply_ioctl'
> >> vhost-net-cdev.c:(.text+0x253): undefined reference to
> >> `fuse_reply_ioctl_retry'
> >> vhost-net-cdev.c:(.text+0x2c2): undefined reference to `fuse_reply_ioctl'
> >> vhost-net-cdev.c:(.text+0x30a): undefined reference to `fuse_reply_err'
> >> vhost-net-cdev.c:(.text+0x359): undefined reference to
> >> `fuse_reply_ioctl_retry'
> >> vhost-net-cdev.c:(.text+0x472): undefined reference to `fuse_reply_ioctl'
> >> vhost-net-cdev.c:(.text+0x49f): undefined reference to `fuse_reply_ioctl'
> >> vhost-net-cdev.c:(.text+0x4ea): undefined reference to `fuse_reply_ioctl'
> >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> >> In function `vhost_net_release':
> >> vhost-net-cdev.c:(.text+0x515): undefined reference to `fuse_req_ctx'
> >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> >> In function `vhost_net_open':
> >> vhost-net-cdev.c:(.text+0x58d): undefined reference to `fuse_req_ctx'
> >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> >> In function `rte_vhost_driver_register':
> >> vhost-net-cdev.c:(.text+0x828): undefined reference to
> >> `cuse_lowlevel_setup'
> >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> >> In function `rte_vhost_driver_session_start':
> >> vhost-net-cdev.c:(.text+0x86c): undefined reference to `fuse_session_loop'
> >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> >> In function `vhost_net_release':
> >> vhost-net-cdev.c:(.text+0x55b): undefined reference to `fuse_reply_err'
> >> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> >> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> >> In function `vhost_net_open':
> >> vhost-net-cdev.c:(.text+0x5d3): undefined reference to `fuse_reply_open'
> >> vhost-net-cdev.c:(.text+0x5ef): undefined reference to `fuse_reply_err'
> >> collect2: ld returned 1 exit status
> >> make[1]: *** [vhost-switch] Error 1
> >> make: *** [all] Error 2
> >>
> >>
> >> Can anyone help me?
> > This was fixed after 1.8.0, on this patch:
> > http://dpdk.org/dev/patchwork/patch/2603/
> >
> > You can either apply it yourself or get the latest code using git.
> >
> > Regards,
> > Pablo
> >> Thank you in advanced.
> >>

[dpdk-dev] [PATCH v3] ABI: Add abi checking utility

[Kavanagh, Mark B]

>On Fri, Mar 13, 2015 at 11:56:59AM +, Kavanagh, Mark B wrote:
>>
>>
>> >-Original Message-
>> >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
>> >Sent: Wednesday, March 4, 2015 4:27 PM
>> >To: dev at dpdk.org
>> >Subject: [dpdk-dev] [PATCH v3] ABI: Add abi checking utility
>> >


(snip)

>> >+log "INFO" "Building DPDK $TAG1. This might take a moment"
>> >+make O=$TARGET > $VERBOSE 2>&1
>> >+
>> >+if [ $? -ne 0 ]
>> >+then
>> >+   log "INFO" "THE BUILD FAILED.  ABORTING"
>>
>> If the build fails while TAG1 is checked out, the user must check out their 
>> original
>local branch manually. I'd prefer it if the script checked out $CURRENT_BRANCH 
>in the
>'cleanup_and_exit' function.
>>
>Sure, its in V4.

Cool.

>
>> Same applies to TAG2, if the user CTRL-C's out of the script, and to any 
>> other command
>that might fail when a particular branch/tag is checked out (for example, the 
>'sed'
>commands fail when I run the script; however, they work when I run them on the 
>command
>line - I'm investigating this currently).
>>
>What does the log say?  Please post it here.  If it helps add a set -x to the
>top of the script for additional verbosity.
>

Hey Neil - this is the error, but it's not a problem with the script; 
presumably I'd cleaned my DPDK installation directory, so 'sed' couldn't find 
the defconfig file:
"sed: can't read config/defconfig_x86_64-ivshmem-linuxapp-gcc/: Not a directory"

Thanks,
Mark

>Neil

[dpdk-dev] [PATCH] common/rte_memcpy: Fix x86intrin.h missed

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu
> Sent: Friday, March 13, 2015 7:03 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] common/rte_memcpy: Fix x86intrin.h missed
> 
> rte_memcpy.h(46): catastrophic error: cannot open source file
> "x86intrin.h"


Hi Michael,

How are you generating that error?

John

[dpdk-dev] [PATCH v6 3/3] ixgbe: Add LRO support

[Vlad Zolotarov]

On 03/13/15 13:28, Ananyev, Konstantin wrote:
> Hi Olivier,
>
>> -Original Message-
>> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
>> Sent: Friday, March 13, 2015 9:08 AM
>> To: Vlad Zolotarov; Ananyev, Konstantin; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v6 3/3] ixgbe: Add LRO support
>>
>> Hi Vlad,
>>
>> On 03/11/2015 05:54 PM, Vlad Zolotarov wrote:
>> About the existing RX/TX functions and PPC support:
>> Note that all of them were created before PPC support for DPDK was
>> introduced.
>> At that moment only IA was supported.
>> That's why in some places where you would expect to see 'mb()' there
>> are 'volatile' and/or ' rte_compiler_barrier' instead.
>> Why all that places wasn't updated when PPC support was added -
>> that's another question.
>>From my understanding - with current implementation some of DPDK
>> PMDs RX/TX functions and  rte_ring wouldn't work correctly
> on PPC.
>> So, I suppose we need to decide for ourselves - do we really want to
>> support PPC and other architectures with non-IA memory
> model or not?
>> If not, then I think we don't need any mb()s inside recv_pkts_lro()
>> - just rte_compiler_barrier seems enough, and no point to
> complain about
>> it in comments.
>> If yes - then why to introduce a new function with a known potential
>> bug?
> In order to introduce a new function with the proper implementation or
> to fix any other places with the similar weakness I would need a proper
> tools like a proper platform-dependent barrier-macros similar to
> smp_Xmb() Linux macros that reduce to a compiler barrier where
> appropriate or to a proper memory fence where needed.
 I understand that.
 Let's add new macro for that: rte_smp_Xmb() or something,
 so it would be just rte_compiler_barrier() for x86 and a proper mb()
 for PPC.
>>> There was an idea to use the C11 built-in memory barriers. I suggest we
>>> open a separate discussion about that and add these and the appropriate
>>> fixes in a separate series. There are quite a few places to fix anyway,
>>> which are currently broken on PPC so this patch doesn't make things any
>>> worse. However adding a new memory barrier doesn't belong to an LRO
>>> functionality and thus to this series.
>> This is an interesting discussion. Just for reference, I submitted a
>> patch on this topic but it was probably too early as only Intel
>> architecture was supported at that time.
>>
>> See http://dpdk.org/ml/archives/dev/2014-May/002597.html
> I do remember that conversation :)
> At that moment, as nothing except IA wasn't supported, I feel it was not 
> needed.
> Though now, if we do want to support PPC and other architectures with weak 
> memory model,
> I think we do need to introduce some platform dependent set of Xmb() macros.
> See http://dpdk.org/ml/archives/dev/2014-October/006729.html
>
> Actually while thinking about it once again:
> Is there any good use for rte_compiler_barrier() for PPC memory model?
> I can't think about any.
> So I wonder can't we just make for PPC:
>   #define rte_compiler_barrierrte_mb
> While keeping it as it is for IA.
> Would save us from searching/replacing though all the code.

I wonder why should we invent a wheel? Like Avi has proposed we may use 
the existing standard C library primitives for that. See this 
http://en.cppreference.com/w/c/atomic. I don't know what's the state of 
icc in this area though... ;)

Pros:

  * Zero maintenance.
  * Multi-platform support.
  * It seems that this is the direction the industry is going to (as
opposed to the discussed above mb(), rmb(), wmb() model).

Cons:

  * The model is a bit different from what most of the kernel
programmers used to.
  * The current code adaptation would be a bit more painful (due to
first "cons").


I think this could be a very nice move. For a user space for sure. The 
open question is a KNI component. I don't know how much code is shared 
between kernel and user space DPDK code but if there isn't much - then 
we may still go for a built-in C atomics primitives in a user space and 
do whatever we choose in the KNI...

>
>   Konstantin
>
>
>
>> Regards,
>> Olivier

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Gonzalez Monroy, Sergio]

On 13/03/2015 13:16, Kavanagh, Mark B wrote:
>
>> -Original Message-
>> From: Gonzalez Monroy, Sergio
>> Sent: Friday, March 13, 2015 11:49 AM
>> To: Kavanagh, Mark B
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and 
>> related options
>>
>> On 13/03/2015 11:34, Kavanagh, Mark B wrote:
 On 13/03/2015 10:49, Kavanagh, Mark B wrote:
>> ---
>> config/common_bsdapp|   6 --
>> config/common_linuxapp  |   6 --
>> config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
>> lib/Makefile|   1 -
>> mk/rte.app.mk   |  12 
>> mk/rte.lib.mk   |  35 --
>> mk/rte.sdkbuild.mk  |   3 -
>> mk/rte.sharelib.mk  | 101 
>> 
>> mk/rte.vars.mk  |   9 ---
>> 9 files changed, 175 deletions(-)
>> delete mode 100644 mk/rte.sharelib.mk
>>
>> diff --git a/config/common_bsdapp b/config/common_bsdapp
>> index 8ff4dc2..7ee5ecf 100644
>> --- a/config/common_bsdapp
>> +++ b/config/common_bsdapp
>> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
>> CONFIG_RTE_BUILD_SHARED_LIB=n
>>
>> #
>> -# Combine to one single library
>> -#
>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
>> -CONFIG_RTE_LIBNAME=intel_dpdk
> Hi Sergio,
>
> Removing these options breaks compatibility with OVS. While it may be 
> feasible to link
 to individual static libraries, in our experience, a single combined 
 library provides a
 much more convenient way of linking.
> Thanks,
> Mark
>
>> -
>>> (snip)
>>>
>>>
>> -endif
>> -
>> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
>> -ifeq ($(RTE_LIBNAME),)
>> -RTE_LIBNAME := intel_dpdk
>> endif
>>
>> # RTE_TARGET is deducted from config when we are building the SDK.
>> --
>> 1.9.3
 Hi Mark,

 How does this patch break compatibility with OVS?

 Thanks,
 Sergio
>>> Hey Sergio,
>>>
>>> We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to 
>>> build a single
>> static DPDK library, named 'libintel_dpdk.a', which OVS links against. 
>> Removing the
>> combined library option breaks compatibility with any application that links 
>> against the
>> combined DPDK library.
>>> Is there a strong technical motivation for removing these options?
>>>
>>> Thanks,
>>> Mark
>>  From a shared library point of view, it just does not make sense to
>> have applications linked against a 'combined' library that may have
>> different features built in it.
>>
> For OVS, we don't build DPDK as a set of shared libraries, but rather an 
> individual static library, due to the performance penalties inherent in using 
> shared libraries.
>
>> Removing these options, aside from the obvious 'less build config
>> option', it simplifies maintenance of makefiles as we currently have a
>> separated makefile with specific rules just for combined library.
>>
>> It is pretty straight forward to build a single combined archive out of
>> multiple archives, would it be acceptable to have a script to do this?
>>
> This seems a bit 'hacky' to me and I'm not sure that it would be amenable to 
> the OVS maintainers. Unless I'm overlooking something here, I'd prefer to 
> maintain the status quo.
This may be a case of personal opinions, but I don't think there is 
anything 'hacky' about it. Straight forward extract objects from 
archive, then archive them into a single library.

Currently to create a combined library we just copy all objects into one 
directory, then create the combined archive.
After the patch, the script just needs to extract all objects from 
individual libraries into a directory and archive them all.

In my opinion, one little exra step, same result plus we get less build 
config options, simplify lib building by removing the 'combined' lib path.

>> Thanks,
>> Sergio

[dpdk-dev] [PATCH v2 03/15] eal: Fix memory leak of pci_uio_map_resource()

[Iremonger, Bernard]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, March 12, 2015 10:18 AM
> To: dev at dpdk.org
> Cc: Iremonger, Bernard; Richardson, Bruce; Tetsuya Mukawa
> Subject: [PATCH v2 03/15] eal: Fix memory leak of pci_uio_map_resource()
> 
> When pci_map_resource() is failed but path is allocated correctly, path won't 
> be freed. Also, when
> open() is failed, uio_res won't be freed.
> This patch fixes these.
> 
> Signed-off-by: Tetsuya Mukawa 
> ---
>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c 
> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> index 77bb5ed..901f277 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> @@ -350,6 +350,11 @@ pci_uio_map_resource(struct rte_pci_device *dev)
>   loc->domain, loc->bus, loc->devid,
>   loc->function, i);
> 
> + /* allocate memory to keep path */
> + maps[map_idx].path = rte_malloc(NULL, strlen(devname) + 1, 0);
> + if (maps[map_idx].path == NULL)
> + goto fail0;
> +
>   /*
>* open resource file, to mmap it
>*/
> @@ -357,7 +362,7 @@ pci_uio_map_resource(struct rte_pci_device *dev)
>   if (fd < 0) {
>   RTE_LOG(ERR, EAL, "Cannot open %s: %s\n",
>   devname, strerror(errno));
> - return -1;
> + goto fail0;
>   }
> 
>   /* try mapping somewhere close to the end of hugepages */ @@ 
> -372,14 +377,9 @@
> pci_uio_map_resource(struct rte_pci_device *dev)
>   pci_map_addr = RTE_PTR_ADD(mapaddr,
>   (size_t)dev->mem_resource[i].len);
> 
> - maps[map_idx].path = rte_malloc(NULL, strlen(devname) + 1, 0);
> - if (maps[map_idx].path == NULL)
> - fail = 1;
> -
Hi Tetsuya,

Could close(fd) be called before if(fail) and the following two close(fd) calls 
removed ?

Regards,

Bernard.

>   if (fail) {
> - rte_free(uio_res);
>   close(fd);
> - return -1;
> + goto fail1;
>   }
>   close(fd);
> 
> @@ -397,6 +397,12 @@ pci_uio_map_resource(struct rte_pci_device *dev)
>   TAILQ_INSERT_TAIL(uio_res_list, uio_res, next);
> 
>   return 0;
> +
> +fail1:
> + rte_free(maps[map_idx].path);
> +fail0:
> + rte_free(uio_res);
> + return -1;
>  }
> 
>  #ifdef RTE_LIBRTE_EAL_HOTPLUG
> --
> 1.9.1

[dpdk-dev] [PATCH v2 02/15] eal: Close file descriptor of uio configuration

[Iremonger, Bernard]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, March 12, 2015 10:18 AM
> To: dev at dpdk.org
> Cc: Iremonger, Bernard; Richardson, Bruce; Tetsuya Mukawa
> Subject: [PATCH v2 02/15] eal: Close file descriptor of uio configuration
> 
> When pci_uio_unmap_resource() is called, a file descriptor that is used for 
> uio configuration should be
> closed.
> 
> Signed-off-by: Tetsuya Mukawa 
> ---
>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c 
> b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> index 6f229d6..77bb5ed 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> @@ -462,6 +462,8 @@ pci_uio_unmap_resource(struct rte_pci_device *dev)
> 
>   /* close fd if in primary process */
>   close(dev->intr_handle.fd);
> + if (dev->intr_handle.uio_cfg_fd >= 0)
> + close(dev->intr_handle.uio_cfg_fd);
Hi Tetsuya,

Should  dev->intr_handle.uio_cfg_fd be set to -1 after closing it?

Regards,

Bernard.


> 
>   dev->intr_handle.fd = -1;
>   dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN;
> --
> 1.9.1

[dpdk-dev] [PATCH v3 0/3]: bug fixes in the ixgbe PF PMD Rx flow

[Vlad Zolotarov]

On 03/13/15 13:07, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
>> Sent: Thursday, March 12, 2015 9:17 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH v3 0/3]: bug fixes in the ixgbe PF PMD Rx flow
>>
>> This series contains some bug fixes that were found during my work on the 
>> ixgbe LRO
>> patches. Sending this series separately on Thomas request so that it may be 
>> integrated
>> into the 2.0 release.
>>
>> New in v3:
>> - Adjusted to the new structs naming in the master.
>> - Fixed rx_bulk_alloc_allowed and rx_vec_allowed initialization:
>>- Don't set them to FALSE in rte_eth_dev_stop() flow - the following
>>  rte_eth_dev_start() will need them.
>>- Reset them to TRUE in rte_eth_dev_configure() and not in a probe() 
>> flow.
>>  This will ensure the proper behaviour if port is re-configured.
>> - Rename:
>>- ixgbe_rx_vec_condition_check() -> 
>> ixgbe_rx_vec_dev_conf_condition_check()
>>- set_rx_function() -> ixgbe_set_rx_function()
>> - Clean up the logic in ixgbe_set_rx_function().
>> - Define stubs with __attribute__((weak)) instead of using #ifdef's.
>> - Styling: beautify ixgbe_rxtx.h a bit.
>>
>> New in v2:
>> - Fixed a compilation failure.
>>
>>
>> Vlad Zolotarov (3):
>>ixgbe: Use the rte_le_to_cpu_xx()/rte_cpu_to_le_xx() when
>>  reading/setting HW ring descriptor fields
>>ixgbe: Bug fix: Properly configure Rx CRC stripping for x540 devices
>>ixgbe: Unify the rx_pkt_bulk callback initialization
>>
>>   lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h |   2 +
>>   lib/librte_pmd_ixgbe/ixgbe_ethdev.c |  13 +-
>>   lib/librte_pmd_ixgbe/ixgbe_rxtx.c   | 216 
>> +---
>>   lib/librte_pmd_ixgbe/ixgbe_rxtx.h   |  28 -
>>   lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c   |   2 +-
>>   5 files changed, 183 insertions(+), 78 deletions(-)
>>
> Acked-by: Konstantin Ananyev 
>
> Just one nit:
>
> +int __attribute__((weak)) ixgbe_rxq_vec_setup(
> + struct ixgbe_rx_queue __rte_unused *rxq)
> +{
>
> Please use notation:
> int __attribute__((weak))
> ixgbe_rxq_vec_setup(struct ixgbe_rx_queue __rte_unused *rxq)
>
> To keep up with the rest of the code, plus makes much easier to read.

I took an example from kni/ethtool/igb/kcompat.h for a template but no 
problem.
Do u want me to respin or it's ok? I will use this format for the 
follow-up LRO patch anyway...

>
>> --
>> 2.1.0

[dpdk-dev] [PATCH] ethdev: additional parameter in RX callback

[Neil Horman]

On Fri, Mar 13, 2015 at 04:26:52PM +, Mcnamara, John wrote:
> 
> 
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Friday, March 13, 2015 3:09 PM
> > To: Richardson, Bruce
> > Cc: Mcnamara, John; dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] ethdev: additional parameter in RX
> > callback
> > 
> > Plese set asside the ABI issue for a moment.  I get that you're trying to
> > get it in prior to needing to version it.  Thats not the argument.  The
> > argument is how best to codify the new information you want to express in
> > the callback.  For this specific case, I think there are better ways to do
> > this than to just blindly add a new parameter.
> 
> Hi Neil,
> 
> I think that is good advice is the general case but this is a very specific 
> case. The modified callback is only used in rte_eth_rx_burst(). For context 
> here is the function in its entirety (without #defs). The substantive change 
> (the addition of nb_pkts) is on the line with an asterisk:
> 
> 
> static inline uint16_t
> rte_eth_rx_burst(uint8_t port_id, uint16_t queue_id,
>  struct rte_mbuf **rx_pkts, const uint16_t nb_pkts)
> {
> struct rte_eth_dev *dev;
> 
> dev = _eth_devices[port_id];
> 
> int16_t nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
> rx_pkts, nb_pkts);
> 
> struct rte_eth_rxtx_callback *cb = dev->post_rx_burst_cbs[queue_id];
> 
> if (unlikely(cb != NULL)) {
> do {
> nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx,
> * nb_pkts, cb->param);
> cb = cb->next;
> } while (cb != NULL);
> }
> 
> return nb_rx;
> }
> 

Not sure I grok your point here.  Why impact does the number of internal
callouts for the callback api have on how we structure the API to external
consumers?


> > Encoding the array size
> > implicitly with a terminating marker lets you use this equally well with
> > the tx and rx callbacks (should you ever need it on the latter)
> 
> Is encoding the information in the array really a better solution here? The 
> cb->param already exists for passing in user defined information to the 
> callback. The proposed patch merely transmits the parent function arguments 
> to the enclosed callback.
> 
The cb->param can't be used here, because its opaque to the internals of the
DPDK.  rte_eth_rx_burst doesn't (and can't) know where in the cb->params pointer
to store that information.  Thats why you added an additional parameter in the
first place, isn't it?  My point is that using an array terminator keeps us out
of this habbit of just adding parameters to communicate more information (as
thats an ABI breaking method, and not particularly scalable if there is more
information to be transmitted in the future).  Using a context sensitive API set
goes beyond even that, and allows to retrieve arbitrary information form
callbacks as needed in an ABI safe manner

Neil

> John
> 
> 
> 
> 
> 
> 
> 

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Kavanagh, Mark B]

>-Original Message-
>From: Gonzalez Monroy, Sergio
>Sent: Friday, March 13, 2015 11:49 AM
>To: Kavanagh, Mark B
>Cc: dev at dpdk.org
>Subject: Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related 
>options
>
>On 13/03/2015 11:34, Kavanagh, Mark B wrote:
>>> On 13/03/2015 10:49, Kavanagh, Mark B wrote:
> ---
> config/common_bsdapp|   6 --
> config/common_linuxapp  |   6 --
> config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
> lib/Makefile|   1 -
> mk/rte.app.mk   |  12 
> mk/rte.lib.mk   |  35 --
> mk/rte.sdkbuild.mk  |   3 -
> mk/rte.sharelib.mk  | 101 
> 
> mk/rte.vars.mk  |   9 ---
> 9 files changed, 175 deletions(-)
> delete mode 100644 mk/rte.sharelib.mk
>
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index 8ff4dc2..7ee5ecf 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> CONFIG_RTE_BUILD_SHARED_LIB=n
>
> #
> -# Combine to one single library
> -#
> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
> -CONFIG_RTE_LIBNAME=intel_dpdk
 Hi Sergio,

 Removing these options breaks compatibility with OVS. While it may be 
 feasible to link
>>> to individual static libraries, in our experience, a single combined 
>>> library provides a
>>> much more convenient way of linking.
 Thanks,
 Mark

> -
>>
>> (snip)
>>
>>
> -endif
> -
> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
> -ifeq ($(RTE_LIBNAME),)
> -RTE_LIBNAME := intel_dpdk
> endif
>
> # RTE_TARGET is deducted from config when we are building the SDK.
> --
> 1.9.3
>>> Hi Mark,
>>>
>>> How does this patch break compatibility with OVS?
>>>
>>> Thanks,
>>> Sergio
>> Hey Sergio,
>>
>> We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to 
>> build a single
>static DPDK library, named 'libintel_dpdk.a', which OVS links against. 
>Removing the
>combined library option breaks compatibility with any application that links 
>against the
>combined DPDK library.
>>
>> Is there a strong technical motivation for removing these options?
>>
>> Thanks,
>> Mark
> From a shared library point of view, it just does not make sense to
>have applications linked against a 'combined' library that may have
>different features built in it.
>

For OVS, we don't build DPDK as a set of shared libraries, but rather an 
individual static library, due to the performance penalties inherent in using 
shared libraries.

>Removing these options, aside from the obvious 'less build config
>option', it simplifies maintenance of makefiles as we currently have a
>separated makefile with specific rules just for combined library.
>
>It is pretty straight forward to build a single combined archive out of
>multiple archives, would it be acceptable to have a script to do this?
>

This seems a bit 'hacky' to me and I'm not sure that it would be amenable to 
the OVS maintainers. Unless I'm overlooking something here, I'd prefer to 
maintain the status quo.

>Thanks,
>Sergio

[dpdk-dev] [PATCH v3 0/3]: bug fixes in the ixgbe PF PMD Rx flow

[Ananyev, Konstantin]

Hi Vlad,

> -Original Message-
> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
> Sent: Friday, March 13, 2015 11:52 AM
> To: Ananyev, Konstantin; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 0/3]: bug fixes in the ixgbe PF PMD Rx flow
> 
> 
> 
> On 03/13/15 13:07, Ananyev, Konstantin wrote:
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
> >> Sent: Thursday, March 12, 2015 9:17 PM
> >> To: dev at dpdk.org
> >> Subject: [dpdk-dev] [PATCH v3 0/3]: bug fixes in the ixgbe PF PMD Rx flow
> >>
> >> This series contains some bug fixes that were found during my work on the 
> >> ixgbe LRO
> >> patches. Sending this series separately on Thomas request so that it may 
> >> be integrated
> >> into the 2.0 release.
> >>
> >> New in v3:
> >> - Adjusted to the new structs naming in the master.
> >> - Fixed rx_bulk_alloc_allowed and rx_vec_allowed initialization:
> >>- Don't set them to FALSE in rte_eth_dev_stop() flow - the following
> >>  rte_eth_dev_start() will need them.
> >>- Reset them to TRUE in rte_eth_dev_configure() and not in a 
> >> probe() flow.
> >>  This will ensure the proper behaviour if port is re-configured.
> >> - Rename:
> >>- ixgbe_rx_vec_condition_check() -> 
> >> ixgbe_rx_vec_dev_conf_condition_check()
> >>- set_rx_function() -> ixgbe_set_rx_function()
> >> - Clean up the logic in ixgbe_set_rx_function().
> >> - Define stubs with __attribute__((weak)) instead of using #ifdef's.
> >> - Styling: beautify ixgbe_rxtx.h a bit.
> >>
> >> New in v2:
> >> - Fixed a compilation failure.
> >>
> >>
> >> Vlad Zolotarov (3):
> >>ixgbe: Use the rte_le_to_cpu_xx()/rte_cpu_to_le_xx() when
> >>  reading/setting HW ring descriptor fields
> >>ixgbe: Bug fix: Properly configure Rx CRC stripping for x540 devices
> >>ixgbe: Unify the rx_pkt_bulk callback initialization
> >>
> >>   lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h |   2 +
> >>   lib/librte_pmd_ixgbe/ixgbe_ethdev.c |  13 +-
> >>   lib/librte_pmd_ixgbe/ixgbe_rxtx.c   | 216 
> >> +---
> >>   lib/librte_pmd_ixgbe/ixgbe_rxtx.h   |  28 -
> >>   lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c   |   2 +-
> >>   5 files changed, 183 insertions(+), 78 deletions(-)
> >>
> > Acked-by: Konstantin Ananyev 
> >
> > Just one nit:
> >
> > +int __attribute__((weak)) ixgbe_rxq_vec_setup(
> > +   struct ixgbe_rx_queue __rte_unused *rxq)
> > +{
> >
> > Please use notation:
> > int __attribute__((weak))
> > ixgbe_rxq_vec_setup(struct ixgbe_rx_queue __rte_unused *rxq)
> >
> > To keep up with the rest of the code, plus makes much easier to read.
> 
> I took an example from kni/ethtool/igb/kcompat.h for a template but no
> problem.
> Do u want me to respin or it's ok? I will use this format for the
> follow-up LRO patch anyway...

Doing that in LRO patch set is ok.
No need for respin that one, I think.
Konstantin

> 
> >
> >> --
> >> 2.1.0

[dpdk-dev] Undefined reference to FUSE

[IñakiMurillo]

Hello,

I am trying to compile the vhost example using DPDK 1.8.0. I have
installed fuse and libfuse-dev (as I am using Ubuntu). I have modified
config/common_linuxapp as follows:

CONFIG_RTE_BUILD_COMBINE_LIBS=y
CONFIG_RTE_LIBRTE_VHOST=y

Then, I compile DPDK 1.8.0 as follows:

make config T=x86_64-native-linuxapp-gcc
make install T=x86_64-native-linuxapp-gcc

And when it comes to compile vhost example I get errors about undefined
reference. To compile it I use theses intructions:

export RTE_SDK=/path/to/dpdk-1.8.0
export RTE_TARGET=x86_64-native-linuxapp-gcc
make

The log of the error is:


CC main.o
  LD vhost-switch
/home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
In function `vhost_net_ioctl':
vhost-net-cdev.c:(.text+0x3c): undefined reference to `fuse_req_ctx'
vhost-net-cdev.c:(.text+0xd5): undefined reference to
`fuse_reply_ioctl_retry'
vhost-net-cdev.c:(.text+0x185): undefined reference to `fuse_reply_ioctl'
vhost-net-cdev.c:(.text+0x253): undefined reference to
`fuse_reply_ioctl_retry'
vhost-net-cdev.c:(.text+0x2c2): undefined reference to `fuse_reply_ioctl'
vhost-net-cdev.c:(.text+0x30a): undefined reference to `fuse_reply_err'
vhost-net-cdev.c:(.text+0x359): undefined reference to
`fuse_reply_ioctl_retry'
vhost-net-cdev.c:(.text+0x472): undefined reference to `fuse_reply_ioctl'
vhost-net-cdev.c:(.text+0x49f): undefined reference to `fuse_reply_ioctl'
vhost-net-cdev.c:(.text+0x4ea): undefined reference to `fuse_reply_ioctl'
/home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
In function `vhost_net_release':
vhost-net-cdev.c:(.text+0x515): undefined reference to `fuse_req_ctx'
/home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
In function `vhost_net_open':
vhost-net-cdev.c:(.text+0x58d): undefined reference to `fuse_req_ctx'
/home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
In function `rte_vhost_driver_register':
vhost-net-cdev.c:(.text+0x828): undefined reference to `cuse_lowlevel_setup'
/home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
In function `rte_vhost_driver_session_start':
vhost-net-cdev.c:(.text+0x86c): undefined reference to `fuse_session_loop'
/home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
In function `vhost_net_release':
vhost-net-cdev.c:(.text+0x55b): undefined reference to `fuse_reply_err'
/home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
In function `vhost_net_open':
vhost-net-cdev.c:(.text+0x5d3): undefined reference to `fuse_reply_open'
vhost-net-cdev.c:(.text+0x5ef): undefined reference to `fuse_reply_err'
collect2: ld returned 1 exit status
make[1]: *** [vhost-switch] Error 1
make: *** [all] Error 2


Can anyone help me?

Thank you in advanced.

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Neil Horman]

On Fri, Mar 13, 2015 at 09:07:59AM -0700, Stephen Hemminger wrote:
> On Thu, 12 Mar 2015 16:27:58 +
> Sergio Gonzalez Monroy  wrote:
> 
> > Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME.
> > 
> > Signed-off-by: Sergio Gonzalez Monroy 
> > ---
> 
> NAK. The combined library is good and useful for those who want simplicity
> and build with static library.
> 
No one is removing the ability to link against a single library, its simple to
do by hand.  The only thing this does is the codification of doing so as part of
the DPDK link process.

> It is not clear what you are trying to solve.
> 
In my mind, the problem is that using combined libs breaks the versioning
infrastrucure.  Because .o files can only be linked into .so files once, the
combined lib in the dpdk tree links all .o files at the same time.  But because
version maps are specified per individual library, and we can only specify one
at link time, we are left with a decision as to how to bring both together:

1) We can write a script to merge all the versioning files into one, and apply
that to the master link

2) Drop the combined libraries all together, and use a linker script to simulate
the merging of the libraries

Option two seems a bit rickety, and prone to failure, whereas option two seems
both easy and clean (at least in my view).  Just create a file libdpdk.so, that
is actually a text file with the contents:
INPUT(-lrte_malloc -lrte_mempool etc)

That will allow you to link applications to a single library -ldpdk, and things
will just work.  The only additional requriement that puts on your head is that
the individual libraries need to be installed locally on the target system, but
thats a run time requirement, not build time, and is easily managed with
whatever run time software management tools you care to use

Neil

[dpdk-dev] [PATCH] eal: remove unnecessary #ifdef CONFIG_BQL

[Alex Gartrell]

I couldn't figure out why this #ifdef existed so I looked around upstream
and it's not there.  It seems to build just fine without it.

Signed-off-by: Alex Gartrell 
---
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h 
b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h
index a582f52..d58e1f3 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h
@@ -472,12 +472,10 @@ static inline u16 igb_desc_unused(const struct igb_ring 
*ring)
return ((ntc > ntu) ? 0 : ring->count) + ntc - ntu - 1;
 }

-#ifdef CONFIG_BQL
 static inline struct netdev_queue *txring_txq(const struct igb_ring *tx_ring)
 {
return netdev_get_tx_queue(tx_ring->netdev, tx_ring->queue_index);
 }
-#endif /* CONFIG_BQL */

 // #ifdef EXT_THERMAL_SENSOR_SUPPORT
 // #ifdef IGB_PROCFS
-- 
Alex Gartrell 

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Neil Horman]

On Fri, Mar 13, 2015 at 03:28:00PM +, Gonzalez Monroy, Sergio wrote:
> On 13/03/2015 15:18, Neil Horman wrote:
> >On Fri, Mar 13, 2015 at 04:12:35PM +0200, Stefan Puiu wrote:
> >>Hi,
> >>
> >>2 cents from a DPDK library user - I make 2 changes to the default
> >>linux+gcc configuration: combine libraries and build shared libraries
> >>(since I want 2 instances of the app, it didn't make sense to me to
> >>link statically). I tried working with the individual libs, but adding
> >>all of them with --start-group/-end-group just seemed so much more
> >>painful than simply linking against one lib. I know there are some
> >>Makefile variables to help with this, but I use scons for building my
> >>app, so that doesn't help much.
> >>
> >>Of course, if that can be achieved easily after building all the
> >>libraries, that's fine. But I think combining the libs makes a lot of
> >>sense in many cases.
> >>
> >So do it, create a linker script that internally contains one line:
> >INPUT(-lrte_eal -lrte_alarm -lrte_mempool ... etc)
> >
> >Name the file libdpdk.so
> >
> >then when you build your app, just link -ldpdk
> >
> >Done.
> >
> >Neil
> 
> Plus I believe that as it currently stands, building combined shared
> libraries will be broken
> the moment we have different versions of any API because the linking for the
> combined lib
> does not use a version map.
> 
Correct, the above is the only way to create a single library that is properly
versioned, short of _only_ building a single library and exporting the version
map for that (which is non-sensical, as it defeats the purpose of DSO's).

> Sergio
> >>Thanks,
> >>Stefan.
> >>
> >>On Fri, Mar 13, 2015 at 3:17 PM, Neil Horman  
> >>wrote:
> >>>On Fri, Mar 13, 2015 at 11:48:59AM +, Gonzalez Monroy, Sergio wrote:
> On 13/03/2015 11:34, Kavanagh, Mark B wrote:
> >>On 13/03/2015 10:49, Kavanagh, Mark B wrote:
> ---
> config/common_bsdapp|   6 --
> config/common_linuxapp  |   6 --
> config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
> lib/Makefile|   1 -
> mk/rte.app.mk   |  12 
> mk/rte.lib.mk   |  35 --
> mk/rte.sdkbuild.mk  |   3 -
> mk/rte.sharelib.mk  | 101 
> 
> mk/rte.vars.mk  |   9 ---
> 9 files changed, 175 deletions(-)
> delete mode 100644 mk/rte.sharelib.mk
> 
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index 8ff4dc2..7ee5ecf 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> CONFIG_RTE_BUILD_SHARED_LIB=n
> 
> #
> -# Combine to one single library
> -#
> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
> -CONFIG_RTE_LIBNAME=intel_dpdk
> >>>Hi Sergio,
> >>>
> >>>Removing these options breaks compatibility with OVS. While it may be 
> >>>feasible to link
> >>to individual static libraries, in our experience, a single combined 
> >>library provides a
> >>much more convenient way of linking.
> >>>Thanks,
> >>>Mark
> >>>
> -
> >(snip)
> >
> >
> -endif
> -
> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
> -ifeq ($(RTE_LIBNAME),)
> -RTE_LIBNAME := intel_dpdk
> endif
> 
> # RTE_TARGET is deducted from config when we are building the SDK.
> --
> 1.9.3
> >>Hi Mark,
> >>
> >>How does this patch break compatibility with OVS?
> >>
> >>Thanks,
> >>Sergio
> >Hey Sergio,
> >
> >We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags 
> >to build a single static DPDK library, named 'libintel_dpdk.a', which 
> >OVS links against. Removing the combined library option breaks 
> >compatibility with any application that links against the combined DPDK 
> >library.
> >
> >Is there a strong technical motivation for removing these options?
> >
> >Thanks,
> >Mark
>  From a shared library point of view, it just does not make sense to have
> applications linked against a 'combined' library that may have different
> features built in it.
> 
> Removing these options, aside from the obvious 'less build config option',
> it simplifies maintenance of makefiles as we currently have a separated
> makefile with specific rules just for combined library.
> 
> It is pretty straight forward to build a single combined archive out of
> multiple archives, would it be acceptable to have a script to do this?
> 
> Thanks,
> Sergio
> 
> >>>+1
> >>>
> >>>For the static case, its easy to do a post build 

[dpdk-dev] [PATCH] rte_mbuf: bulk allocation and freeing functions + unittest

[vadim.sur...@gmail.com]

From: "vadim.suraev at gmail.com" 

- an API function to allocate a bulk of rte_mbufs
- an API function to free a bulk of rte_mbufs
- an API function to free a chained rte_mbuf
- unittest for aboce

Signed-off-by: vadim.suraev at gmail.com 
---
 app/test/test_mbuf.c   |   73 
 lib/librte_mbuf/rte_mbuf.h |  101 
 2 files changed, 174 insertions(+)

diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 1ff66cb..a557705 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -405,6 +405,67 @@ test_pktmbuf_pool(void)
return ret;
 }

+/* test pktmbuf bulk allocation and freeing
+*/
+static int
+test_pktmbuf_pool_bulk(void)
+{
+   unsigned i;
+   unsigned mbufs_to_allocate = NB_MBUF - 32; /* size of mempool - size of 
local cache, otherwise may fail */
+   struct rte_mbuf *m[mbufs_to_allocate];
+   int ret = 0;
+   unsigned mbuf_count_before_allocation = rte_mempool_count(pktmbuf_pool);
+
+   for (i=0; inext = m[i + 1];
+   m[0]->nb_segs++;
+   }
+   /* free them */
+   rte_pktmbuf_free_chain(m[0]);
+   
+   if (rte_mempool_count(pktmbuf_pool)  != mbuf_count_before_allocation) {
+   printf("mempool count %d != initial %d\n",
+   rte_mempool_count(pktmbuf_pool), 
mbuf_count_before_allocation);
+   return -1;
+   }
+   return ret;
+}
+
 /*
  * test that the pointer to the data on a packet mbuf is set properly
  */
@@ -790,6 +851,18 @@ test_mbuf(void)
return -1;
}

+   /* test bulk allocation and freeing */
+   if (test_pktmbuf_pool_bulk() < 0) {
+   printf("test_pktmbuf_pool_bulk() failed\n");
+   return -1;
+   }
+
+   /* once again to ensure all mbufs were freed */
+   if (test_pktmbuf_pool_bulk() < 0) {
+   printf("test_pktmbuf_pool_bulk() failed\n");
+   return -1;
+   }
+
/* test that the pointer to the data on a packet mbuf is set properly */
if (test_pktmbuf_pool_ptr() < 0) {
printf("test_pktmbuf_pool_ptr() failed\n");
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 17ba791..482920e 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -825,6 +825,107 @@ static inline void rte_pktmbuf_free(struct rte_mbuf *m)
 }

 /**
+ * Allocates a bulk of mbufs, initiates refcnt and resets
+ *
+ * @param pool
+ *memory pool to allocate from
+ * @param mbufs
+ *Array of pointers to mbuf
+ * @param count
+ *Array size
+ */
+static inline int rte_pktmbuf_alloc_bulk(struct rte_mempool *pool, struct 
rte_mbuf **mbufs, unsigned count)
+{
+   unsigned idx;
+   int rc = 0;
+
+   if (unlikely(rc = rte_mempool_get_bulk(pool, (void **)mbufs, count))) {
+   return rc;
+   }
+
+   for (idx = 0; idx < count; idx++) {
+   RTE_MBUF_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
+   rte_mbuf_refcnt_set(mbufs[idx], 1);
+   rte_pktmbuf_reset(mbufs[idx]);
+   }
+   

[dpdk-dev] Undefined reference to FUSE

[De Lara Guarch, Pablo]

Hi I?aki,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of I?akiMurillo
> Sent: Friday, March 13, 2015 11:50 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] Undefined reference to FUSE
> 
> Hello,
> 
> I am trying to compile the vhost example using DPDK 1.8.0. I have
> installed fuse and libfuse-dev (as I am using Ubuntu). I have modified
> config/common_linuxapp as follows:
> 
> CONFIG_RTE_BUILD_COMBINE_LIBS=y
> CONFIG_RTE_LIBRTE_VHOST=y
> 
> Then, I compile DPDK 1.8.0 as follows:
> 
> make config T=x86_64-native-linuxapp-gcc
> make install T=x86_64-native-linuxapp-gcc
> 
> And when it comes to compile vhost example I get errors about undefined
> reference. To compile it I use theses intructions:
> 
> export RTE_SDK=/path/to/dpdk-1.8.0
> export RTE_TARGET=x86_64-native-linuxapp-gcc
> make
> 
> The log of the error is:
> 
> 
> CC main.o
>   LD vhost-switch
> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> In function `vhost_net_ioctl':
> vhost-net-cdev.c:(.text+0x3c): undefined reference to `fuse_req_ctx'
> vhost-net-cdev.c:(.text+0xd5): undefined reference to
> `fuse_reply_ioctl_retry'
> vhost-net-cdev.c:(.text+0x185): undefined reference to `fuse_reply_ioctl'
> vhost-net-cdev.c:(.text+0x253): undefined reference to
> `fuse_reply_ioctl_retry'
> vhost-net-cdev.c:(.text+0x2c2): undefined reference to `fuse_reply_ioctl'
> vhost-net-cdev.c:(.text+0x30a): undefined reference to `fuse_reply_err'
> vhost-net-cdev.c:(.text+0x359): undefined reference to
> `fuse_reply_ioctl_retry'
> vhost-net-cdev.c:(.text+0x472): undefined reference to `fuse_reply_ioctl'
> vhost-net-cdev.c:(.text+0x49f): undefined reference to `fuse_reply_ioctl'
> vhost-net-cdev.c:(.text+0x4ea): undefined reference to `fuse_reply_ioctl'
> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> In function `vhost_net_release':
> vhost-net-cdev.c:(.text+0x515): undefined reference to `fuse_req_ctx'
> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> In function `vhost_net_open':
> vhost-net-cdev.c:(.text+0x58d): undefined reference to `fuse_req_ctx'
> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> In function `rte_vhost_driver_register':
> vhost-net-cdev.c:(.text+0x828): undefined reference to
> `cuse_lowlevel_setup'
> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> In function `rte_vhost_driver_session_start':
> vhost-net-cdev.c:(.text+0x86c): undefined reference to `fuse_session_loop'
> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> In function `vhost_net_release':
> vhost-net-cdev.c:(.text+0x55b): undefined reference to `fuse_reply_err'
> /home/imurillo/virtio_dpdk_1_8/dpdk-1.8.0/x86_64-native-linuxapp-
> gcc/lib/libintel_dpdk.a(vhost-net-cdev.o):
> In function `vhost_net_open':
> vhost-net-cdev.c:(.text+0x5d3): undefined reference to `fuse_reply_open'
> vhost-net-cdev.c:(.text+0x5ef): undefined reference to `fuse_reply_err'
> collect2: ld returned 1 exit status
> make[1]: *** [vhost-switch] Error 1
> make: *** [all] Error 2
> 
> 
> Can anyone help me?

This was fixed after 1.8.0, on this patch:
http://dpdk.org/dev/patchwork/patch/2603/

You can either apply it yourself or get the latest code using git.

Regards,
Pablo
> 
> Thank you in advanced.
> 

[dpdk-dev] [PATCH v3] ABI: Add abi checking utility

[Kavanagh, Mark B]

>-Original Message-
>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
>Sent: Wednesday, March 4, 2015 4:27 PM
>To: dev at dpdk.org
>Subject: [dpdk-dev] [PATCH v3] ABI: Add abi checking utility
>
>There was a request for an abi validation utilty for the ongoing ABI stability
>work.  As it turns out there is a abi compliance checker in development that
>seems to be under active development and provides fairly detailed ABI 
>compliance
>reports.  Its not yet intellegent enough to understand symbol versioning, but 
>it
>does provide the ability to identify symbols which have changed between
>releases, along with details of the change, and offers developers the
>opportunity to identify which symbols then need versioning and validation for a
>given update via manual testing.
>
>This script automates the use of the compliance checker between two arbitrarily
>specified tags within the dpdk tree.  To execute enter the $RTE_SDK directory
>and run:
>
>./scripts/validate_abi.sh $GIT_TAG1 $GIT_TAG2 $CONFIG
>
>where $GIT_TAG1 and 2 are git tags and $CONFIG is a config specification
>suitable for passing as the T= variable in the make config command.
>
>Note the upstream source for the abi compliance checker is here:
>http://ispras.linuxbase.org/index.php/ABI_compliance_checker
>
>It generates a report for each DSO built from the requested tags that 
>developers
>can review to find ABI compliance issues.
>
>Signed-off-by: Neil Horman 
>
>---
>
>Change Notes:
>
>v2) Fixed some typos as requested by Thomas
>
>v3) Fixed some additional typos Thomas requested
>Improved script to work from detached state
>Added some documentation to the changelog
>Added some comments to the scripts
>---
> scripts/validate_abi.sh | 248 
> 1 file changed, 248 insertions(+)
> create mode 100755 scripts/validate_abi.sh
>
>diff --git a/scripts/validate_abi.sh b/scripts/validate_abi.sh
>new file mode 100755
>index 000..899cf5f
>--- /dev/null
>+++ b/scripts/validate_abi.sh
>@@ -0,0 +1,248 @@
>+#!/bin/sh
>+#   BSD LICENSE
>+#
>+#   Copyright(c) 2015 Neil Horman. All rights reserved.
>+#   All rights reserved.
>+#
>+#   Redistribution and use in source and binary forms, with or without
>+#   modification, are permitted provided that the following conditions
>+#   are met:
>+#
>+# * Redistributions of source code must retain the above copyright
>+#   notice, this list of conditions and the following disclaimer.
>+# * Redistributions in binary form must reproduce the above copyright
>+#   notice, this list of conditions and the following disclaimer in
>+#   the documentation and/or other materials provided with the
>+#   distribution.
>+#
>+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>+
>+TAG1=$1
>+TAG2=$2
>+TARGET=$3
>+ABI_DIR=`mktemp -d -p /tmp ABI.XX`
>+
>+usage() {
>+  echo "$0   "
>+}
>+
>+log() {
>+  local level=$1
>+  shift
>+  echo "$*"
>+}
>+
>+validate_tags() {
>+  git tag -l | grep -q "$TAG1"
>+  if [ $? -ne 0 ]
>+  then
>+  echo "$TAG1 is invalid"
>+  return
>+  fi
>+  git tag -l | grep -q "$TAG2"
>+  if [ $? -ne 0 ]
>+  then
>+  echo "$TAG2 is invalid"
>+  return
>+  fi
>+}
>+
>+validate_args() {
>+  if [ -z "$TAG1" ]
>+  then
>+  echo "Must Specify TAG1"
>+  return
>+  fi
>+  if [ -z "$TAG2" ]
>+  then
>+  echo "Must Specify TAG2"
>+  return
>+  fi
>+  if [ -z "$TARGET" ]
>+  then
>+  echo "Must Specify a build target"
>+  fi
>+}
>+
>+
>+cleanup_and_exit() {
>+  rm -rf $ABI_DIR
>+  exit $1
>+}
>+
>+###
>+#START
>+
>+
>+#trap on ctrl-c to clean up
>+trap cleanup_and_exit SIGINT
>+
>+#Save the current branch
>+CURRENT_BRANCH=`git branch | grep \* | cut -d' ' -f2`
>+
>+if [ -z "$CURRENT_BRANCH" ]
>+then
>+  CURRENT_BRANCH=`git log --pretty=format:%H HEAD~1..HEAD`
>+fi
>+
>+if [ -n "$VERBOSE" ]
>+then
>+  export VERBOSE=/dev/stdout
>+else
>+  export VERBOSE=/dev/null
>+fi

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Gonzalez Monroy, Sergio]

On 13/03/2015 11:34, Kavanagh, Mark B wrote:
>> On 13/03/2015 10:49, Kavanagh, Mark B wrote:
 ---
 config/common_bsdapp|   6 --
 config/common_linuxapp  |   6 --
 config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
 lib/Makefile|   1 -
 mk/rte.app.mk   |  12 
 mk/rte.lib.mk   |  35 --
 mk/rte.sdkbuild.mk  |   3 -
 mk/rte.sharelib.mk  | 101 
 
 mk/rte.vars.mk  |   9 ---
 9 files changed, 175 deletions(-)
 delete mode 100644 mk/rte.sharelib.mk

 diff --git a/config/common_bsdapp b/config/common_bsdapp
 index 8ff4dc2..7ee5ecf 100644
 --- a/config/common_bsdapp
 +++ b/config/common_bsdapp
 @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
 CONFIG_RTE_BUILD_SHARED_LIB=n

 #
 -# Combine to one single library
 -#
 -CONFIG_RTE_BUILD_COMBINE_LIBS=n
 -CONFIG_RTE_LIBNAME=intel_dpdk
>>> Hi Sergio,
>>>
>>> Removing these options breaks compatibility with OVS. While it may be 
>>> feasible to link
>> to individual static libraries, in our experience, a single combined library 
>> provides a
>> much more convenient way of linking.
>>> Thanks,
>>> Mark
>>>
 -
>
> (snip)
>
>
 -endif
 -
 -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
 -ifeq ($(RTE_LIBNAME),)
 -RTE_LIBNAME := intel_dpdk
 endif

 # RTE_TARGET is deducted from config when we are building the SDK.
 --
 1.9.3
>> Hi Mark,
>>
>> How does this patch break compatibility with OVS?
>>
>> Thanks,
>> Sergio
> Hey Sergio,
>
> We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to 
> build a single static DPDK library, named 'libintel_dpdk.a', which OVS links 
> against. Removing the combined library option breaks compatibility with any 
> application that links against the combined DPDK library.
>
> Is there a strong technical motivation for removing these options?
>
> Thanks,
> Mark
 From a shared library point of view, it just does not make sense to 
have applications linked against a 'combined' library that may have 
different features built in it.

Removing these options, aside from the obvious 'less build config 
option', it simplifies maintenance of makefiles as we currently have a 
separated makefile with specific rules just for combined library.

It is pretty straight forward to build a single combined archive out of 
multiple archives, would it be acceptable to have a script to do this?

Thanks,
Sergio

[dpdk-dev] [PATCH v2 00/15] eal: Port Hotplug support for BSD

[Iremonger, Bernard]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, March 12, 2015 10:18 AM
> To: dev at dpdk.org
> Cc: Iremonger, Bernard; Richardson, Bruce; Tetsuya Mukawa
> Subject: [PATCH v2 00/15] eal: Port Hotplug support for BSD
> 
> This patch series adds port hotplug support to BSD.
> Also, the patches consolidates pci uio functions of linuxapp and bsdapp.
> 
> Following patches cleanup pci uio code to consolidate later.
>   eal: Fix cording style of eal_pci.c and eal_pci_uio.c
>   eal: Close file descriptor of uio configuration
>   eal: Fix memory leak of pci_uio_map_resource()
>   eal: Fix needless incrementation of pci_map_addr
>   eal/bsdapp: Change names of pci related data structure
>   eal: Use map_idx in pci_uio_map_resource() of bsdapp to work same as
> linuxapp
>   eal: Fix interface of pci_map_resource() of bsdapp
>   eal: Add pci_uio_alloc_uio_resource()
>   eal: Add pci_uio_map_uio_resource_by_index()
> 
Hi Tetsuya,

It might be better to split this patchset into two patch sets, 
A cleanup patchset and a consolidation patchset. 
It would make reviewing easier.

Regards,

Bernard.


> Following patches are actually for functions consolidation.
>   eal: Consolidate pci_map and mapped_pci_resource of linuxapp and
> bsdapp
>   eal: Consolidate rte_eal_pci_probe/close_one_driver() of linuxapp and
> bsdapp
>   eal: Consolidate pci_map/unmap_device() of linuxapp and bsdapp
>   eal: Consolidate pci_map/unmap_resource() of linuxapp and bsdapp
>   eal: Consolidate pci uio functions of linuxapp and bsdapp
> 
> The last patch removes CONFIG_RTE_LIBRTE_EAL_HOTPLUG configuration from Linux 
> and BSD.
> And port hotplug is enabled as default with both Linux and BSD.
>   eal: Enable Port Hotplug as default in Linux and BSD
> 
> 
> PATCH v2 changes
>  - Consolidate pci uio functions of linuxapp and bsdapp.
> 
> 
> Tetsuya Mukawa (15):
>   eal: Fix cording style of eal_pci.c and eal_pci_uio.c
>   eal: Close file descriptor of uio configuration
>   eal: Fix memory leak of pci_uio_map_resource()
>   eal: Fix needless incrementation of pci_map_addr
>   eal/bsdapp: Change names of pci related data structure
>   eal: Use map_idx in pci_uio_map_resource() of bsdapp to work same as
> linuxapp
>   eal: Fix interface of pci_map_resource() of bsdapp
>   eal: Add pci_uio_alloc_uio_resource()
>   eal: Add pci_uio_map_uio_resource_by_index()
>   eal: Consolidate pci_map and mapped_pci_resource of linuxapp and
> bsdapp
>   eal: Consolidate rte_eal_pci_probe/close_one_driver() of linuxapp and
> bsdapp
>   eal: Consolidate pci_map/unmap_device() of linuxapp and bsdapp
>   eal: Consolidate pci_map/unmap_resource() of linuxapp and bsdapp
>   eal: Consolidate pci uio functions of linuxapp and bsdapp
>   eal: Enable Port Hotplug as default in Linux and BSD
> 
>  config/common_bsdapp   |   6 -
>  config/common_linuxapp |   5 -
>  lib/librte_eal/bsdapp/eal/Makefile |   1 +
>  lib/librte_eal/bsdapp/eal/eal_pci.c| 292 
> ++---
>  .../bsdapp/eal/include/exec-env/rte_interrupts.h   |   1 +
>  lib/librte_eal/bsdapp/eal/rte_eal_version.map  |   6 +
>  lib/librte_eal/common/eal_common_dev.c |   2 -
>  lib/librte_eal/common/eal_common_pci.c | 234 -
>  lib/librte_eal/common/eal_common_pci_uio.c | 224 
>  lib/librte_eal/common/eal_private.h|  57 +++-
>  lib/librte_eal/common/include/rte_pci.h|  42 ++-
>  lib/librte_eal/linuxapp/eal/Makefile   |   1 +
>  lib/librte_eal/linuxapp/eal/eal_pci.c  | 236 +
>  lib/librte_eal/linuxapp/eal/eal_pci_init.h |  39 +--
>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c  | 263 +--
>  lib/librte_ether/rte_ethdev.c  |  22 +-
>  16 files changed, 702 insertions(+), 729 deletions(-)  create mode 100644
> lib/librte_eal/common/eal_common_pci_uio.c
> 
> --
> 1.9.1

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Kavanagh, Mark B]

>On 13/03/2015 10:49, Kavanagh, Mark B wrote:
>>> ---
>>> config/common_bsdapp|   6 --
>>> config/common_linuxapp  |   6 --
>>> config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
>>> lib/Makefile|   1 -
>>> mk/rte.app.mk   |  12 
>>> mk/rte.lib.mk   |  35 --
>>> mk/rte.sdkbuild.mk  |   3 -
>>> mk/rte.sharelib.mk  | 101 
>>> 
>>> mk/rte.vars.mk  |   9 ---
>>> 9 files changed, 175 deletions(-)
>>> delete mode 100644 mk/rte.sharelib.mk
>>>
>>> diff --git a/config/common_bsdapp b/config/common_bsdapp
>>> index 8ff4dc2..7ee5ecf 100644
>>> --- a/config/common_bsdapp
>>> +++ b/config/common_bsdapp
>>> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
>>> CONFIG_RTE_BUILD_SHARED_LIB=n
>>>
>>> #
>>> -# Combine to one single library
>>> -#
>>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
>>> -CONFIG_RTE_LIBNAME=intel_dpdk
>> Hi Sergio,
>>
>> Removing these options breaks compatibility with OVS. While it may be 
>> feasible to link
>to individual static libraries, in our experience, a single combined library 
>provides a
>much more convenient way of linking.
>>
>> Thanks,
>> Mark
>>
>>> -


(snip)


>>> -endif
>>> -
>>> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
>>> -ifeq ($(RTE_LIBNAME),)
>>> -RTE_LIBNAME := intel_dpdk
>>> endif
>>>
>>> # RTE_TARGET is deducted from config when we are building the SDK.
>>> --
>>> 1.9.3
>Hi Mark,
>
>How does this patch break compatibility with OVS?
>
>Thanks,
>Sergio

Hey Sergio,

We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to build 
a single static DPDK library, named 'libintel_dpdk.a', which OVS links against. 
Removing the combined library option breaks compatibility with any application 
that links against the combined DPDK library.

Is there a strong technical motivation for removing these options?

Thanks,
Mark

[dpdk-dev] [PATCH v6 3/3] ixgbe: Add LRO support

[Ananyev, Konstantin]

Hi Olivier,

> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Friday, March 13, 2015 9:08 AM
> To: Vlad Zolotarov; Ananyev, Konstantin; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 3/3] ixgbe: Add LRO support
> 
> Hi Vlad,
> 
> On 03/11/2015 05:54 PM, Vlad Zolotarov wrote:
>  About the existing RX/TX functions and PPC support:
>  Note that all of them were created before PPC support for DPDK was
>  introduced.
>  At that moment only IA was supported.
>  That's why in some places where you would expect to see 'mb()' there
>  are 'volatile' and/or ' rte_compiler_barrier' instead.
>  Why all that places wasn't updated when PPC support was added -
>  that's another question.
>    From my understanding - with current implementation some of DPDK
>  PMDs RX/TX functions and  rte_ring wouldn't work correctly
> >>> on PPC.
>  So, I suppose we need to decide for ourselves - do we really want to
>  support PPC and other architectures with non-IA memory
> >>> model or not?
>  If not, then I think we don't need any mb()s inside recv_pkts_lro()
>  - just rte_compiler_barrier seems enough, and no point to
> >>> complain about
>  it in comments.
>  If yes - then why to introduce a new function with a known potential
>  bug?
> >>> In order to introduce a new function with the proper implementation or
> >>> to fix any other places with the similar weakness I would need a proper
> >>> tools like a proper platform-dependent barrier-macros similar to
> >>> smp_Xmb() Linux macros that reduce to a compiler barrier where
> >>> appropriate or to a proper memory fence where needed.
> >> I understand that.
> >> Let's add new macro for that: rte_smp_Xmb() or something,
> >> so it would be just rte_compiler_barrier() for x86 and a proper mb()
> >> for PPC.
> >
> > There was an idea to use the C11 built-in memory barriers. I suggest we
> > open a separate discussion about that and add these and the appropriate
> > fixes in a separate series. There are quite a few places to fix anyway,
> > which are currently broken on PPC so this patch doesn't make things any
> > worse. However adding a new memory barrier doesn't belong to an LRO
> > functionality and thus to this series.
> 
> This is an interesting discussion. Just for reference, I submitted a
> patch on this topic but it was probably too early as only Intel
> architecture was supported at that time.
> 
> See http://dpdk.org/ml/archives/dev/2014-May/002597.html

I do remember that conversation :)
At that moment, as nothing except IA wasn't supported, I feel it was not needed.
Though now, if we do want to support PPC and other architectures with weak 
memory model,
I think we do need to introduce some platform dependent set of Xmb() macros.
See http://dpdk.org/ml/archives/dev/2014-October/006729.html

Actually while thinking about it once again:
Is there any good use for rte_compiler_barrier() for PPC memory model?
I can't think about any.
So I wonder can't we just make for PPC:
 #define rte_compiler_barrierrte_mb
While keeping it as it is for IA.
Would save us from searching/replacing though all the code.

 Konstantin



> 
> Regards,
> Olivier

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Gonzalez Monroy, Sergio]

On 13/03/2015 10:49, Kavanagh, Mark B wrote:
>> ---
>> config/common_bsdapp|   6 --
>> config/common_linuxapp  |   6 --
>> config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
>> lib/Makefile|   1 -
>> mk/rte.app.mk   |  12 
>> mk/rte.lib.mk   |  35 --
>> mk/rte.sdkbuild.mk  |   3 -
>> mk/rte.sharelib.mk  | 101 
>> 
>> mk/rte.vars.mk  |   9 ---
>> 9 files changed, 175 deletions(-)
>> delete mode 100644 mk/rte.sharelib.mk
>>
>> diff --git a/config/common_bsdapp b/config/common_bsdapp
>> index 8ff4dc2..7ee5ecf 100644
>> --- a/config/common_bsdapp
>> +++ b/config/common_bsdapp
>> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
>> CONFIG_RTE_BUILD_SHARED_LIB=n
>>
>> #
>> -# Combine to one single library
>> -#
>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
>> -CONFIG_RTE_LIBNAME=intel_dpdk
> Hi Sergio,
>
> Removing these options breaks compatibility with OVS. While it may be 
> feasible to link to individual static libraries, in our experience, a single 
> combined library provides a much more convenient way of linking.
>
> Thanks,
> Mark
>
>> -
>> -#
>> # Compile Environment Abstraction Layer
>> #
>> CONFIG_RTE_LIBRTE_EAL=y
>> diff --git a/config/common_linuxapp b/config/common_linuxapp
>> index 97f1c9e..ae13805 100644
>> --- a/config/common_linuxapp
>> +++ b/config/common_linuxapp
>> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
>> CONFIG_RTE_BUILD_SHARED_LIB=n
>>
>> #
>> -# Combine to one single library
>> -#
>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
>> -CONFIG_RTE_LIBNAME="intel_dpdk"
>> -
>> -#
>> # Compile Environment Abstraction Layer
>> #
>> CONFIG_RTE_LIBRTE_EAL=y
>> diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc 
>> b/config/defconfig_ppc_64-power8-
>> linuxapp-gcc
>> index d97a885..f1af518 100644
>> --- a/config/defconfig_ppc_64-power8-linuxapp-gcc
>> +++ b/config/defconfig_ppc_64-power8-linuxapp-gcc
>> @@ -39,8 +39,6 @@ CONFIG_RTE_ARCH_64=y
>> CONFIG_RTE_TOOLCHAIN="gcc"
>> CONFIG_RTE_TOOLCHAIN_GCC=y
>>
>> -CONFIG_RTE_LIBNAME="powerpc_dpdk"
>> -
>> # Note: Power doesn't have this support
>> CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
>>
>> diff --git a/lib/Makefile b/lib/Makefile
>> index d94355d..c34cf2f 100644
>> --- a/lib/Makefile
>> +++ b/lib/Makefile
>> @@ -77,5 +77,4 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
>> DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
>> endif
>>
>> -include $(RTE_SDK)/mk/rte.sharelib.mk
>> include $(RTE_SDK)/mk/rte.subdir.mk
>> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
>> index 63a41e2..e2baa49 100644
>> --- a/mk/rte.app.mk
>> +++ b/mk/rte.app.mk
>> @@ -61,12 +61,6 @@ ifeq ($(NO_AUTOLIBS),)
>>
>> LDLIBS += --whole-archive
>>
>> -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
>> -LDLIBS += -l$(RTE_LIBNAME)
>> -endif
>> -
>> -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
>> -
>> ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y)
>> LDLIBS += -lrte_distributor
>> endif
>> @@ -137,8 +131,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y)
>> LDLIBS += -lrte_vhost
>> endif
>>
>> -endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
>> -
>> ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
>> LDLIBS += -lpcap
>> endif
>> @@ -153,8 +145,6 @@ endif
>>
>> LDLIBS += --start-group
>>
>> -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
>> -
>> ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y)
>> LDLIBS += -lrte_kvargs
>> endif
>> @@ -253,8 +243,6 @@ endif
>>
>> endif # plugins
>>
>> -endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
>> -
>> LDLIBS += $(EXECENV_LDLIBS)
>>
>> LDLIBS += --end-group
>> diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
>> index 0d7482d..d96101a 100644
>> --- a/mk/rte.lib.mk
>> +++ b/mk/rte.lib.mk
>> @@ -87,24 +87,6 @@ O_TO_S_DO = @set -e; \
>>  $(O_TO_S) && \
>>  echo $(O_TO_S_CMD) > $(call exe2cmd,$(@))
>>
>> -ifeq ($(RTE_BUILD_SHARED_LIB),n)
>> -O_TO_C = $(AR) crus $(LIB_ONE) $(OBJS-y)
>> -O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
>> -O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)","  AR_C $(@)")
>> -O_TO_C_DO = @set -e; \
>> -$(lib_dir) \
>> -$(copy_obj)
>> -else
>> -O_TO_C = $(LD) -shared $(OBJS-y) -o $(LIB_ONE)
>> -O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
>> -O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)","  LD_C $(@)")
>> -O_TO_C_DO = @set -e; \
>> -$(lib_dir) \
>> -$(copy_obj)
>> -endif
>> -
>> -copy_obj = cp -f $(OBJS-y) $(RTE_OUTPUT)/build/lib;
>> -lib_dir = [ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib;
>> -include .$(LIB).cmd
>>
>> #
>> @@ -129,15 +111,6 @@ endif
>>  $(depfile_missing),\
>>  $(depfile_newer)),\
>>  $(O_TO_S_DO))
>> -
>> -ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
>> -$(if $(or \
>> -$(file_missing),\
>> -$(call cmdline_changed,$(O_TO_C_STR)),\
>> -$(depfile_missing),\
>> -$(depfile_newer)),\
>> -$(O_TO_C_DO))
>> -endif
>> else

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Neil Horman]

On Fri, Mar 13, 2015 at 04:12:35PM +0200, Stefan Puiu wrote:
> Hi,
> 
> 2 cents from a DPDK library user - I make 2 changes to the default
> linux+gcc configuration: combine libraries and build shared libraries
> (since I want 2 instances of the app, it didn't make sense to me to
> link statically). I tried working with the individual libs, but adding
> all of them with --start-group/-end-group just seemed so much more
> painful than simply linking against one lib. I know there are some
> Makefile variables to help with this, but I use scons for building my
> app, so that doesn't help much.
> 
> Of course, if that can be achieved easily after building all the
> libraries, that's fine. But I think combining the libs makes a lot of
> sense in many cases.
> 
So do it, create a linker script that internally contains one line:
INPUT(-lrte_eal -lrte_alarm -lrte_mempool ... etc)

Name the file libdpdk.so

then when you build your app, just link -ldpdk

Done.

Neil

> Thanks,
> Stefan.
> 
> On Fri, Mar 13, 2015 at 3:17 PM, Neil Horman  wrote:
> > On Fri, Mar 13, 2015 at 11:48:59AM +, Gonzalez Monroy, Sergio wrote:
> >> On 13/03/2015 11:34, Kavanagh, Mark B wrote:
> >> >>On 13/03/2015 10:49, Kavanagh, Mark B wrote:
> >> ---
> >> config/common_bsdapp|   6 --
> >> config/common_linuxapp  |   6 --
> >> config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
> >> lib/Makefile|   1 -
> >> mk/rte.app.mk   |  12 
> >> mk/rte.lib.mk   |  35 --
> >> mk/rte.sdkbuild.mk  |   3 -
> >> mk/rte.sharelib.mk  | 101 
> >> 
> >> mk/rte.vars.mk  |   9 ---
> >> 9 files changed, 175 deletions(-)
> >> delete mode 100644 mk/rte.sharelib.mk
> >> 
> >> diff --git a/config/common_bsdapp b/config/common_bsdapp
> >> index 8ff4dc2..7ee5ecf 100644
> >> --- a/config/common_bsdapp
> >> +++ b/config/common_bsdapp
> >> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> >> CONFIG_RTE_BUILD_SHARED_LIB=n
> >> 
> >> #
> >> -# Combine to one single library
> >> -#
> >> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
> >> -CONFIG_RTE_LIBNAME=intel_dpdk
> >> >>>Hi Sergio,
> >> >>>
> >> >>>Removing these options breaks compatibility with OVS. While it may be 
> >> >>>feasible to link
> >> >>to individual static libraries, in our experience, a single combined 
> >> >>library provides a
> >> >>much more convenient way of linking.
> >> >>>Thanks,
> >> >>>Mark
> >> >>>
> >> -
> >> >
> >> >(snip)
> >> >
> >> >
> >> -endif
> >> -
> >> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
> >> -ifeq ($(RTE_LIBNAME),)
> >> -RTE_LIBNAME := intel_dpdk
> >> endif
> >> 
> >> # RTE_TARGET is deducted from config when we are building the SDK.
> >> --
> >> 1.9.3
> >> >>Hi Mark,
> >> >>
> >> >>How does this patch break compatibility with OVS?
> >> >>
> >> >>Thanks,
> >> >>Sergio
> >> >Hey Sergio,
> >> >
> >> >We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to 
> >> >build a single static DPDK library, named 'libintel_dpdk.a', which OVS 
> >> >links against. Removing the combined library option breaks compatibility 
> >> >with any application that links against the combined DPDK library.
> >> >
> >> >Is there a strong technical motivation for removing these options?
> >> >
> >> >Thanks,
> >> >Mark
> >> From a shared library point of view, it just does not make sense to have
> >> applications linked against a 'combined' library that may have different
> >> features built in it.
> >>
> >> Removing these options, aside from the obvious 'less build config option',
> >> it simplifies maintenance of makefiles as we currently have a separated
> >> makefile with specific rules just for combined library.
> >>
> >> It is pretty straight forward to build a single combined archive out of
> >> multiple archives, would it be acceptable to have a script to do this?
> >>
> >> Thanks,
> >> Sergio
> >>
> > +1
> >
> > For the static case, its easy to do a post build combination of archives.  
> > For
> > the shared library case, its equally easy to simply create a linker scripts 
> > call
> > .so that pulls in all the individual libraries.
> >
> > Neil
> >
> 

[dpdk-dev] [PATCH] ethdev: additional parameter in RX callback

[Neil Horman]

On Fri, Mar 13, 2015 at 02:50:03PM +, Bruce Richardson wrote:
> On Fri, Mar 13, 2015 at 09:45:14AM -0400, Neil Horman wrote:
> > On Fri, Mar 13, 2015 at 09:41:33AM +, Bruce Richardson wrote:
> > > On Thu, Mar 12, 2015 at 03:15:40PM -0400, Neil Horman wrote:
> > > > On Thu, Mar 12, 2015 at 04:54:27PM +, John McNamara wrote:
> > > > > 
> > > > > This patch is a minor extension to the recent patchset for RX/TX 
> > > > > callbacks
> > > > > based on feedback from users implementing solutions based on it.
> > > > > 
> > > > > The patch adds a new parameter to the RX callback to pass in the 
> > > > > number of
> > > > > available RX packets in addition to the number of dequeued packets.
> > > > > This provides the RX callback functions with additional information
> > > > > that can be used to decide how packets from a burst are handled.
> > > > > 
> > > > > The TX callback doesn't require this additional parameter so the RX
> > > > > and TX callbacks no longer have the same function parameters. As such
> > > > > the single RX/TX callback has been refactored into two separate 
> > > > > callbacks.
> > > > > 
> > > > > Since this is an API change we hope it can be included in 2.0.0 to 
> > > > > avoid
> > > > > changing the API in a subsequent release.
> > > > > 
> > > > > 
> > > > > John McNamara (1):
> > > > >   ethdev: added additional packet count parameter to RX callbacks
> > > > > 
> > > > >  examples/rxtx_callbacks/main.c |3 +-
> > > > >  lib/librte_ether/rte_ethdev.c  |8 ++--
> > > > >  lib/librte_ether/rte_ethdev.h  |   74 
> > > > > ++--
> > > > >  3 files changed, 54 insertions(+), 31 deletions(-)
> > > > > 
> > > > > -- 
> > > > > 1.7.4.1
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > Well, we're well past the new feature phase of this cycle, so I would 
> > > > say NACK.
> > > > I would also suggest that you don't need to modify ABI to accomodate 
> > > > this
> > > > feature.  Instead just document the pkts array to be terminated by a 
> > > > reserved
> > > > value, so that the callback can determine its size dynamically.  You 
> > > > could
> > > > alternatively create a new api call that allows you to retrieve that 
> > > > information
> > > > from the context of the callback.
> > > > 
> > > > Neil
> > > > 
> > > 
> > > Yes, I would agree we are past the new feature phase. However, given that 
> > > we
> > > are making a change to the API, and a fairly small change too - adding 
> > > one extra
> > > parameter - we think that the benefit of including this now outweighs any 
> > > risk
> > > of merging the patch. It seems a bit crazy to ship a release with a new 
> > > API and
> > > then immediately change the API straight after release. Is it not better 
> > > to
> > > take the received feedback on the API and fix/improve it pre-release 
> > > before it
> > > gets set-in-stone?
> > > 
> > > /Bruce
> > > 
> > > 
> > 
> > See above, the API doesn't need to change at all to accomodate this as far 
> > as I
> > can see.
> > 
> > Neil
> Yes, there are alternative ways to see about accomplishing the same thing, but
> they are not nearly as clear as adding in the extra param. That's why we'd 
> like
> to see this change go in before release, if possible. If it doesn't make 2.0
> I'd like to see it in 2.1, but at the cost of having an API change and the
> additional versionning and deprecation that ensues.
> 
Plese set asside the ABI issue for a moment.  I get that you're trying to get it
in prior to needing to version it.  Thats not the argument.  The argument is how
best to codify the new information you want to express in the callback.  For
this specific case, I think there are better ways to do this than to just
blindly add a new parameter.  Encoding the array size implicitly with a
terminating marker lets you use this equally well with the tx and rx callbacks
(should you ever need it on the latter), and isn't uncommon to do at all.  It
also lets you avoid the odd bugs that arise should the caller ever mis-encode
the array length such that it doesn't match the actual array size.

Using additional context sensitive functions are also nice, because they are
additive without being ABI breaking.  That is to say, in the future, if you want
to export more information to a callback you can do so by adding an API call
that simply didnt' exist before.  Thats a nice feature to be able to support.

Just adding more parameters isn't the only (nor in my view) the more flexible
way to do this

Neil

> Regards,
> /Bruce
> 
> 

[dpdk-dev] [PATCH v3 0/3]: bug fixes in the ixgbe PF PMD Rx flow

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
> Sent: Thursday, March 12, 2015 9:17 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v3 0/3]: bug fixes in the ixgbe PF PMD Rx flow
> 
> This series contains some bug fixes that were found during my work on the 
> ixgbe LRO
> patches. Sending this series separately on Thomas request so that it may be 
> integrated
> into the 2.0 release.
> 
> New in v3:
>- Adjusted to the new structs naming in the master.
>- Fixed rx_bulk_alloc_allowed and rx_vec_allowed initialization:
>   - Don't set them to FALSE in rte_eth_dev_stop() flow - the following
> rte_eth_dev_start() will need them.
>   - Reset them to TRUE in rte_eth_dev_configure() and not in a probe() 
> flow.
> This will ensure the proper behaviour if port is re-configured.
>- Rename:
>   - ixgbe_rx_vec_condition_check() -> 
> ixgbe_rx_vec_dev_conf_condition_check()
>   - set_rx_function() -> ixgbe_set_rx_function()
>- Clean up the logic in ixgbe_set_rx_function().
>- Define stubs with __attribute__((weak)) instead of using #ifdef's.
>- Styling: beautify ixgbe_rxtx.h a bit.
> 
> New in v2:
>- Fixed a compilation failure.
> 
> 
> Vlad Zolotarov (3):
>   ixgbe: Use the rte_le_to_cpu_xx()/rte_cpu_to_le_xx() when
> reading/setting HW ring descriptor fields
>   ixgbe: Bug fix: Properly configure Rx CRC stripping for x540 devices
>   ixgbe: Unify the rx_pkt_bulk callback initialization
> 
>  lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h |   2 +
>  lib/librte_pmd_ixgbe/ixgbe_ethdev.c |  13 +-
>  lib/librte_pmd_ixgbe/ixgbe_rxtx.c   | 216 
> +---
>  lib/librte_pmd_ixgbe/ixgbe_rxtx.h   |  28 -
>  lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c   |   2 +-
>  5 files changed, 183 insertions(+), 78 deletions(-)
> 

Acked-by: Konstantin Ananyev 

Just one nit:

+int __attribute__((weak)) ixgbe_rxq_vec_setup(
+   struct ixgbe_rx_queue __rte_unused *rxq)
+{

Please use notation:
int __attribute__((weak))
ixgbe_rxq_vec_setup(struct ixgbe_rx_queue __rte_unused *rxq)

To keep up with the rest of the code, plus makes much easier to read.

> --
> 2.1.0

[dpdk-dev] [PATCH v3] ABI: Add abi checking utility

[Neil Horman]

On Fri, Mar 13, 2015 at 02:25:17PM +, Kavanagh, Mark B wrote:
> >On Fri, Mar 13, 2015 at 11:56:59AM +, Kavanagh, Mark B wrote:
> >>
> >>
> >> >-Original Message-
> >> >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> >> >Sent: Wednesday, March 4, 2015 4:27 PM
> >> >To: dev at dpdk.org
> >> >Subject: [dpdk-dev] [PATCH v3] ABI: Add abi checking utility
> >> >
> 
> 
> (snip)
> 
> >> >+log "INFO" "Building DPDK $TAG1. This might take a moment"
> >> >+make O=$TARGET > $VERBOSE 2>&1
> >> >+
> >> >+if [ $? -ne 0 ]
> >> >+then
> >> >+ log "INFO" "THE BUILD FAILED.  ABORTING"
> >>
> >> If the build fails while TAG1 is checked out, the user must check out 
> >> their original
> >local branch manually. I'd prefer it if the script checked out 
> >$CURRENT_BRANCH in the
> >'cleanup_and_exit' function.
> >>
> >Sure, its in V4.
> 
> Cool.
> 
> >
> >> Same applies to TAG2, if the user CTRL-C's out of the script, and to any 
> >> other command
> >that might fail when a particular branch/tag is checked out (for example, 
> >the 'sed'
> >commands fail when I run the script; however, they work when I run them on 
> >the command
> >line - I'm investigating this currently).
> >>
> >What does the log say?  Please post it here.  If it helps add a set -x to the
> >top of the script for additional verbosity.
> >
> 
> Hey Neil - this is the error, but it's not a problem with the script; 
> presumably I'd cleaned my DPDK installation directory, so 'sed' couldn't find 
> the defconfig file:
> "sed: can't read config/defconfig_x86_64-ivshmem-linuxapp-gcc/: Not a 
> directory"
> 
Actually, it looks to me like you added a trailing "/" to the end of the third
argument on the script command line, so sed bombs when it tries to modify a
directory instead of a file.  Try specifying:
x86_64-ivshmem-linuxapp-gcc
instead of
x86_64-ivshmem-linuxapp-gcc/

Neil

> Thanks,
> Mark
> 
> >Neil
> 
> 

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Kavanagh, Mark B]

>---
> config/common_bsdapp|   6 --
> config/common_linuxapp  |   6 --
> config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
> lib/Makefile|   1 -
> mk/rte.app.mk   |  12 
> mk/rte.lib.mk   |  35 --
> mk/rte.sdkbuild.mk  |   3 -
> mk/rte.sharelib.mk  | 101 
> mk/rte.vars.mk  |   9 ---
> 9 files changed, 175 deletions(-)
> delete mode 100644 mk/rte.sharelib.mk
>
>diff --git a/config/common_bsdapp b/config/common_bsdapp
>index 8ff4dc2..7ee5ecf 100644
>--- a/config/common_bsdapp
>+++ b/config/common_bsdapp
>@@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> CONFIG_RTE_BUILD_SHARED_LIB=n
>
> #
>-# Combine to one single library
>-#
>-CONFIG_RTE_BUILD_COMBINE_LIBS=n
>-CONFIG_RTE_LIBNAME=intel_dpdk

Hi Sergio,

Removing these options breaks compatibility with OVS. While it may be feasible 
to link to individual static libraries, in our experience, a single combined 
library provides a much more convenient way of linking.

Thanks,
Mark 

>-
>-#
> # Compile Environment Abstraction Layer
> #
> CONFIG_RTE_LIBRTE_EAL=y
>diff --git a/config/common_linuxapp b/config/common_linuxapp
>index 97f1c9e..ae13805 100644
>--- a/config/common_linuxapp
>+++ b/config/common_linuxapp
>@@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> CONFIG_RTE_BUILD_SHARED_LIB=n
>
> #
>-# Combine to one single library
>-#
>-CONFIG_RTE_BUILD_COMBINE_LIBS=n
>-CONFIG_RTE_LIBNAME="intel_dpdk"
>-
>-#
> # Compile Environment Abstraction Layer
> #
> CONFIG_RTE_LIBRTE_EAL=y
>diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc 
>b/config/defconfig_ppc_64-power8-
>linuxapp-gcc
>index d97a885..f1af518 100644
>--- a/config/defconfig_ppc_64-power8-linuxapp-gcc
>+++ b/config/defconfig_ppc_64-power8-linuxapp-gcc
>@@ -39,8 +39,6 @@ CONFIG_RTE_ARCH_64=y
> CONFIG_RTE_TOOLCHAIN="gcc"
> CONFIG_RTE_TOOLCHAIN_GCC=y
>
>-CONFIG_RTE_LIBNAME="powerpc_dpdk"
>-
> # Note: Power doesn't have this support
> CONFIG_RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT=n
>
>diff --git a/lib/Makefile b/lib/Makefile
>index d94355d..c34cf2f 100644
>--- a/lib/Makefile
>+++ b/lib/Makefile
>@@ -77,5 +77,4 @@ DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni
> DIRS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += librte_ivshmem
> endif
>
>-include $(RTE_SDK)/mk/rte.sharelib.mk
> include $(RTE_SDK)/mk/rte.subdir.mk
>diff --git a/mk/rte.app.mk b/mk/rte.app.mk
>index 63a41e2..e2baa49 100644
>--- a/mk/rte.app.mk
>+++ b/mk/rte.app.mk
>@@ -61,12 +61,6 @@ ifeq ($(NO_AUTOLIBS),)
>
> LDLIBS += --whole-archive
>
>-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y)
>-LDLIBS += -l$(RTE_LIBNAME)
>-endif
>-
>-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
>-
> ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y)
> LDLIBS += -lrte_distributor
> endif
>@@ -137,8 +131,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y)
> LDLIBS += -lrte_vhost
> endif
>
>-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
>-
> ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y)
> LDLIBS += -lpcap
> endif
>@@ -153,8 +145,6 @@ endif
>
> LDLIBS += --start-group
>
>-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n)
>-
> ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y)
> LDLIBS += -lrte_kvargs
> endif
>@@ -253,8 +243,6 @@ endif
>
> endif # plugins
>
>-endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS
>-
> LDLIBS += $(EXECENV_LDLIBS)
>
> LDLIBS += --end-group
>diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk
>index 0d7482d..d96101a 100644
>--- a/mk/rte.lib.mk
>+++ b/mk/rte.lib.mk
>@@ -87,24 +87,6 @@ O_TO_S_DO = @set -e; \
>   $(O_TO_S) && \
>   echo $(O_TO_S_CMD) > $(call exe2cmd,$(@))
>
>-ifeq ($(RTE_BUILD_SHARED_LIB),n)
>-O_TO_C = $(AR) crus $(LIB_ONE) $(OBJS-y)
>-O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
>-O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)","  AR_C $(@)")
>-O_TO_C_DO = @set -e; \
>-  $(lib_dir) \
>-  $(copy_obj)
>-else
>-O_TO_C = $(LD) -shared $(OBJS-y) -o $(LIB_ONE)
>-O_TO_C_STR = $(subst ','\'',$(O_TO_C)) #'# fix syntax highlight
>-O_TO_C_DISP = $(if $(V),"$(O_TO_C_STR)","  LD_C $(@)")
>-O_TO_C_DO = @set -e; \
>-  $(lib_dir) \
>-  $(copy_obj)
>-endif
>-
>-copy_obj = cp -f $(OBJS-y) $(RTE_OUTPUT)/build/lib;
>-lib_dir = [ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib;
> -include .$(LIB).cmd
>
> #
>@@ -129,15 +111,6 @@ endif
>   $(depfile_missing),\
>   $(depfile_newer)),\
>   $(O_TO_S_DO))
>-
>-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
>-  $(if $(or \
>-$(file_missing),\
>-$(call cmdline_changed,$(O_TO_C_STR)),\
>-$(depfile_missing),\
>-$(depfile_newer)),\
>-$(O_TO_C_DO))
>-endif
> else
> $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
>   @[ -d $(dir $@) ] || mkdir -p $(dir $@)
>@@ -153,14 +126,6 @@ $(LIB): $(OBJS-y) $(DEP_$(LIB)) FORCE
>   $(depfile_missing),\
>   $(depfile_newer)),\
>   $(O_TO_A_DO))
>-ifeq ($(RTE_BUILD_COMBINE_LIBS),y)
>-  $(if $(or \

[dpdk-dev] PMD architecture related to code

[Akshay]

Kuldeep,

The documentation on dpdk.org explains quite a lot about the architecture.
I suggest you go through it first.

http://dpdk.org/doc/guides/prog_guide/

-Akshay

On Fri, Mar 13, 2015 at 10:15 AM,  wrote:

> Hi Developer Team ,
>
>
> I am trying add new functionality on Poll Mode driver .
> But I don't have idea how packets are coming to kernel mode and going to
> user space and doing packet processing DPDK .
>
> I need suggestion on which file the PMD architecture defined .
>
>
>
> Regards ,
> Kuldeep
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>

[dpdk-dev] PMD architecture related to code

[kuldeep.sam...@wipro.com]

Hi Akshay ,

I already gone through the DPDK prog guide , but I am wondering to know how 
Poll Mode driver working IN DPDK framework .




Regards
Kuldeep

From: Akshay [mailto:akshay.ran...@gmail.com]
Sent: Friday, March 13, 2015 10:48 AM
To: Kuldeep Samasi (WT01 - Global Media & Telecom)
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] PMD architecture related to code

Kuldeep,

The documentation on dpdk.org explains quite a lot about the 
architecture. I suggest you go through it first.

http://dpdk.org/doc/guides/prog_guide/

-Akshay

On Fri, Mar 13, 2015 at 10:15 AM, mailto:kuldeep.samasi at wipro.com>> wrote:
Hi Developer Team ,


I am trying add new functionality on Poll Mode driver .
But I don't have idea how packets are coming to kernel mode and going to user 
space and doing packet processing DPDK .

I need suggestion on which file the PMD architecture defined .



Regards ,
Kuldeep
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com

The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com

[dpdk-dev] [PATCH] app/testpmd: Fix not set need_reconfig flag when port id is RTE_PORT_ALL

[Yong Liu]

When port id is RTE_PORT_ALL, port_id_is_invalid will also return zero.
So this function will only set ports[255] need_reconfig flag, other ports will
be skipped.

Signed-off-by: Marvin liu 

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 5b16a69..077d7a4 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -8874,14 +8874,7 @@ prompt(void)
 static void
 cmd_reconfig_device_queue(portid_t id, uint8_t dev, uint8_t queue)
 {
-   if (!port_id_is_invalid(id, DISABLED_WARN)) {
-   /* check if need_reconfig has been set to 1 */
-   if (ports[id].need_reconfig == 0)
-   ports[id].need_reconfig = dev;
-   /* check if need_reconfig_queues has been set to 1 */
-   if (ports[id].need_reconfig_queues == 0)
-   ports[id].need_reconfig_queues = queue;
-   } else {
+   if (id == (portid_t)RTE_PORT_ALL) {
portid_t pid;

FOREACH_PORT(pid, ports) {
@@ -8892,6 +8885,13 @@ cmd_reconfig_device_queue(portid_t id, uint8_t dev, 
uint8_t queue)
if (ports[pid].need_reconfig_queues == 0)
ports[pid].need_reconfig_queues = queue;
}
+   } else if (!port_id_is_invalid(id, DISABLED_WARN)) {
+   /* check if need_reconfig has been set to 1 */
+   if (ports[id].need_reconfig == 0)
+   ports[id].need_reconfig = dev;
+   /* check if need_reconfig_queues has been set to 1 */
+   if (ports[id].need_reconfig_queues == 0)
+   ports[id].need_reconfig_queues = queue;
}
 }

-- 
1.9.3

[dpdk-dev] [RFC] af_packet: support port hotplug

[Iremonger, Bernard]

> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Friday, March 13, 2015 12:11 AM
> To: Iremonger, Bernard
> Cc: John W. Linville; dev at dpdk.org
> Subject: Re: [dpdk-dev] [RFC] af_packet: support port hotplug
> 
> 2015-03-13 2:05 GMT+09:00 Iremonger, Bernard :
> >
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John W. Linville
> >> Sent: Tuesday, March 10, 2015 6:36 PM
> >> To: dev at dpdk.org
> >> Subject: [dpdk-dev] [RFC] af_packet: support port hotplug
> >>
> >> This patch adds finalization code to free resources allocated by the
> >> PMD.  This is based on earlier patches for other PMDs by Tetsuya
> >> Mukawa , with corrections related to data-
> >> >name.
> >>
> >> Signed-off-by: John W. Linville 
> >> Cc: Tetsuya Mukawa 
> >> ---
> >>  lib/librte_pmd_af_packet/rte_eth_af_packet.c | 56
> >> 
> >>  1 file changed, 56 insertions(+)
> >>
> >> diff --git a/lib/librte_pmd_af_packet/rte_eth_af_packet.c
> >> b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
> >> index 80e9bdf7f819..57998ab19c96 100644
> >> --- a/lib/librte_pmd_af_packet/rte_eth_af_packet.c
> >> +++ b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
> >> @@ -399,6 +399,13 @@ static struct eth_dev_ops ops = {
> >>   .stats_reset = eth_stats_reset,  };
> >>
> >> +static struct eth_driver rte_af_packet_pmd = {
> >> + .pci_drv = {
> >> + .name = "rte_af_packet_pmd",
> >> + .drv_flags = RTE_PCI_DRV_DETACHABLE,
> >> + },
> >> +};
> >> +
> >>  /*
> >>   * Opens an AF_PACKET socket
> >>   */
> >> @@ -653,6 +660,10 @@ rte_pmd_init_internals(const char *name,
> >>   if (*eth_dev == NULL)
> >>   goto error;
> >>
> >> + /* check length of device name */
> >> + if ((strlen((*eth_dev)->data->name) + 1) > sizeof(data->name))
> >> + goto error;
> >> +
> >>   /*
> >>* now put it all together
> >>* - store queue data in internals, @@ -669,12 +680,14 @@
> >> rte_pmd_init_internals(const char *name,
> >>   data->nb_tx_queues = (uint16_t)nb_queues;
> >>   data->dev_link = pmd_link;
> >>   data->mac_addrs = &(*internals)->eth_addr;
> >> + strncpy(data->name, (*eth_dev)->data->name,
> >> +strlen((*eth_dev)->data->name));
> >>
> >>   pci_dev->numa_node = numa_node;
> >>
> >>   (*eth_dev)->data = data;
> >>   (*eth_dev)->dev_ops = 
> >>   (*eth_dev)->pci_dev = pci_dev;
> >> + (*eth_dev)->driver = _af_packet_pmd;
> >>
> >>   return 0;
> >>
> >> @@ -835,10 +848,53 @@ rte_pmd_af_packet_devinit(const char *name, const 
> >> char *params)
> >>   return 0;
> >>  }
> >>
> >> +static int
> >> +rte_pmd_af_packet_devuninit(const char *name) {
> >> + struct rte_eth_dev *eth_dev = NULL;
> >> + struct pmd_internals *internals;
> >> + struct tpacket_req req;
> >> +
> >> + unsigned q;
> >> +
> >> + RTE_LOG(INFO, PMD, "Closing AF_PACKET ethdev on numa socket %u\n",
> >> + rte_socket_id());
> >> +
> >> + if (name == NULL)
> >> + return -1;
> >
> > Hi  Tetsuya, John,
> >
> > Before detaching a port, the port must be stopped and closed.
> > The stop and close are only allowed for RTE_PROC_PRIMARY.
> > Should there be a check for process_type here?
> >
> > if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> > return -EPERM;
> >
> > Regards,
> >
> > Bernard
> >
> 
> Hi Bernard,
> 
> I agree with stop() and close() are only called by primary process, but it 
> may not need to add like
> above.
> Could you please check rte_ethdev.c?
> 
> - struct rte_eth_dev_data *rte_eth_dev_data; This array is shared between 
> processes.
> So we need to initialize of finalize carefully like you said.
> 
> - struct rte_eth_dev rte_eth_devices[]
> This array is per process.
> And 'data' variable of this structure indicates a pointer of rte_eth_dev_data.
> 
> All PMDs for physical NIC allocates like above when PMDs are initialized.
> (Even when a process is secondary, initialization function of PMDs will be 
> called) But virtual device
> PMDs allocate rte_eth_dev_data and overwrite 'data'
> variable of rte_eth_devices while initialization.
> 
> As a result, primary and secondary process has their own 'rte_eth_dev_data' 
> for a virtual device.
> So I guess all processes need to free it not to leak memory.
> 
> Thanks,
> Tetsuya
> 
Hi Tetsuya,

In rte_ethdev.c   both rte_eth_dev_stop() and rte_eth_dev_close()  use the 
macro  PROC_PRIMARY_OR_RET().
So for secondary processes  both functions return without doing anything. 
Maybe this check should be added to rte_eth_dev_attach() and 
rte_eth_dev_detach() ?

For the Physical/Virtual  Functions of the NIC  a lot of the finalization is 
done in the  dev->dev_ops->dev_stop() and
dev->dev_ops->dev_close() functions. To complete the finalization the 
dev_uninit() function is called, this should probably do nothing for secondary 
processes  as the 

[dpdk-dev] [PATCH v3] ABI: Add abi checking utility

[Neil Horman]

On Fri, Mar 13, 2015 at 11:56:59AM +, Kavanagh, Mark B wrote:
> 
> 
> >-Original Message-
> >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> >Sent: Wednesday, March 4, 2015 4:27 PM
> >To: dev at dpdk.org
> >Subject: [dpdk-dev] [PATCH v3] ABI: Add abi checking utility
> >
> >There was a request for an abi validation utilty for the ongoing ABI 
> >stability
> >work.  As it turns out there is a abi compliance checker in development that
> >seems to be under active development and provides fairly detailed ABI 
> >compliance
> >reports.  Its not yet intellegent enough to understand symbol versioning, 
> >but it
> >does provide the ability to identify symbols which have changed between
> >releases, along with details of the change, and offers developers the
> >opportunity to identify which symbols then need versioning and validation 
> >for a
> >given update via manual testing.
> >
> >This script automates the use of the compliance checker between two 
> >arbitrarily
> >specified tags within the dpdk tree.  To execute enter the $RTE_SDK directory
> >and run:
> >
> >./scripts/validate_abi.sh $GIT_TAG1 $GIT_TAG2 $CONFIG
> >
> >where $GIT_TAG1 and 2 are git tags and $CONFIG is a config specification
> >suitable for passing as the T= variable in the make config command.
> >
> >Note the upstream source for the abi compliance checker is here:
> >http://ispras.linuxbase.org/index.php/ABI_compliance_checker
> >
> >It generates a report for each DSO built from the requested tags that 
> >developers
> >can review to find ABI compliance issues.
> >
> >Signed-off-by: Neil Horman 
> >
> >---
> >
> >Change Notes:
> >
> >v2) Fixed some typos as requested by Thomas
> >
> >v3) Fixed some additional typos Thomas requested
> >Improved script to work from detached state
> >Added some documentation to the changelog
> >Added some comments to the scripts
> >---
> > scripts/validate_abi.sh | 248 
> > 
> > 1 file changed, 248 insertions(+)
> > create mode 100755 scripts/validate_abi.sh
> >
> >diff --git a/scripts/validate_abi.sh b/scripts/validate_abi.sh
> >new file mode 100755
> >index 000..899cf5f
> >--- /dev/null
> >+++ b/scripts/validate_abi.sh
> >@@ -0,0 +1,248 @@
> >+#!/bin/sh
> >+#   BSD LICENSE
> >+#
> >+#   Copyright(c) 2015 Neil Horman. All rights reserved.
> >+#   All rights reserved.
> >+#
> >+#   Redistribution and use in source and binary forms, with or without
> >+#   modification, are permitted provided that the following conditions
> >+#   are met:
> >+#
> >+# * Redistributions of source code must retain the above copyright
> >+#   notice, this list of conditions and the following disclaimer.
> >+# * Redistributions in binary form must reproduce the above copyright
> >+#   notice, this list of conditions and the following disclaimer in
> >+#   the documentation and/or other materials provided with the
> >+#   distribution.
> >+#
> >+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> >+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> >+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> >+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> >+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> >+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> >+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> >+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> >+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> >+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> >+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> >+
> >+TAG1=$1
> >+TAG2=$2
> >+TARGET=$3
> >+ABI_DIR=`mktemp -d -p /tmp ABI.XX`
> >+
> >+usage() {
> >+echo "$0   "
> >+}
> >+
> >+log() {
> >+local level=$1
> >+shift
> >+echo "$*"
> >+}
> >+
> >+validate_tags() {
> >+git tag -l | grep -q "$TAG1"
> >+if [ $? -ne 0 ]
> >+then
> >+echo "$TAG1 is invalid"
> >+return
> >+fi
> >+git tag -l | grep -q "$TAG2"
> >+if [ $? -ne 0 ]
> >+then
> >+echo "$TAG2 is invalid"
> >+return
> >+fi
> >+}
> >+
> >+validate_args() {
> >+if [ -z "$TAG1" ]
> >+then
> >+echo "Must Specify TAG1"
> >+return
> >+fi
> >+if [ -z "$TAG2" ]
> >+then
> >+echo "Must Specify TAG2"
> >+return
> >+fi
> >+if [ -z "$TARGET" ]
> >+then
> >+echo "Must Specify a build target"
> >+fi
> >+}
> >+
> >+
> >+cleanup_and_exit() {
> >+rm -rf $ABI_DIR
> >+exit $1
> >+}
> >+
> >+###
> >+#START
> >+
> >+
> >+#trap on ctrl-c to clean up
> >+trap cleanup_and_exit SIGINT

[dpdk-dev] [PATCH v4] ABI: Add abi checking utility

[Neil Horman]

There was a request for an abi validation utilty for the ongoing ABI stability
work.  As it turns out there is a abi compliance checker in development that
seems to be under active development and provides fairly detailed ABI compliance
reports.  Its not yet intellegent enough to understand symbol versioning, but it
does provide the ability to identify symbols which have changed between
releases, along with details of the change, and offers developers the
opportunity to identify which symbols then need versioning and validation for a
given update via manual testing.

This script automates the use of the compliance checker between two arbitrarily
specified tags within the dpdk tree.  To execute enter the $RTE_SDK directory
and run:

./scripts/validate_abi.sh $GIT_TAG1 $GIT_TAG2 $CONFIG

where $GIT_TAG1 and 2 are git tags and $CONFIG is a config specification
suitable for passing as the T= variable in the make config command.

Note the upstream source for the abi compliance checker is here:
http://ispras.linuxbase.org/index.php/ABI_compliance_checker

It generates a report for each DSO built from the requested tags that developers
can review to find ABI compliance issues.

Signed-off-by: Neil Horman 

---

Change Notes:

v2) Fixed some typos as requested by Thomas

v3) Fixed some additional typos Thomas requested
Improved script to work from detached state
Added some documentation to the changelog
Added some comments to the scripts

v4) Remove duplicate exports.
Move restoration of starting branch/comit to cleanup_and_exit
---
 scripts/validate_abi.sh | 245 
 1 file changed, 245 insertions(+)
 create mode 100755 scripts/validate_abi.sh

diff --git a/scripts/validate_abi.sh b/scripts/validate_abi.sh
new file mode 100755
index 000..bdec431
--- /dev/null
+++ b/scripts/validate_abi.sh
@@ -0,0 +1,245 @@
+#!/bin/sh
+#   BSD LICENSE
+#
+#   Copyright(c) 2015 Neil Horman. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+TAG1=$1
+TAG2=$2
+TARGET=$3
+ABI_DIR=`mktemp -d -p /tmp ABI.XX`
+
+usage() {
+   echo "$0   "
+}
+
+log() {
+   local level=$1
+   shift
+   echo "$*"
+}
+
+validate_tags() {
+   git tag -l | grep -q "$TAG1"
+   if [ $? -ne 0 ]
+   then
+   echo "$TAG1 is invalid"
+   return
+   fi
+   git tag -l | grep -q "$TAG2"
+   if [ $? -ne 0 ]
+   then
+   echo "$TAG2 is invalid"
+   return
+   fi
+}
+
+validate_args() {
+   if [ -z "$TAG1" ]
+   then
+   echo "Must Specify TAG1"
+   return
+   fi
+   if [ -z "$TAG2" ]
+   then
+   echo "Must Specify TAG2"
+   return
+   fi
+   if [ -z "$TARGET" ]
+   then
+   echo "Must Specify a build target"
+   fi
+}
+
+
+cleanup_and_exit() {
+   rm -rf $ABI_DIR
+   exit $1
+   git checkout $CURRENT_BRANCH
+}
+
+###
+#START
+
+
+#trap on ctrl-c to clean up
+trap cleanup_and_exit SIGINT
+
+#Save the current branch
+CURRENT_BRANCH=`git branch | grep \* | cut -d' ' -f2`
+
+if [ -z "$CURRENT_BRANCH" ]
+then
+   CURRENT_BRANCH=`git log --pretty=format:%H HEAD~1..HEAD`
+fi
+
+if [ -n "$VERBOSE" ]
+then
+   export VERBOSE=/dev/stdout
+else
+   export VERBOSE=/dev/null
+fi
+
+# Validate that we have all the arguments we need
+res=$(validate_args)
+if [ -n "$res" ]
+then
+   echo $res
+   usage
+   cleanup_and_exit 1
+fi
+
+# Make sure our tags exist

[dpdk-dev] [PATCH v6 3/3] ixgbe: Add LRO support

[Olivier MATZ]

Hi Vlad,

On 03/11/2015 05:54 PM, Vlad Zolotarov wrote:
 About the existing RX/TX functions and PPC support:
 Note that all of them were created before PPC support for DPDK was
 introduced.
 At that moment only IA was supported.
 That's why in some places where you would expect to see 'mb()' there
 are 'volatile' and/or ' rte_compiler_barrier' instead.
 Why all that places wasn't updated when PPC support was added -
 that's another question.
   From my understanding - with current implementation some of DPDK
 PMDs RX/TX functions and  rte_ring wouldn't work correctly
>>> on PPC.
 So, I suppose we need to decide for ourselves - do we really want to
 support PPC and other architectures with non-IA memory
>>> model or not?
 If not, then I think we don't need any mb()s inside recv_pkts_lro()
 - just rte_compiler_barrier seems enough, and no point to
>>> complain about
 it in comments.
 If yes - then why to introduce a new function with a known potential
 bug?
>>> In order to introduce a new function with the proper implementation or
>>> to fix any other places with the similar weakness I would need a proper
>>> tools like a proper platform-dependent barrier-macros similar to
>>> smp_Xmb() Linux macros that reduce to a compiler barrier where
>>> appropriate or to a proper memory fence where needed.
>> I understand that.
>> Let's add new macro for that: rte_smp_Xmb() or something,
>> so it would be just rte_compiler_barrier() for x86 and a proper mb()
>> for PPC.
>
> There was an idea to use the C11 built-in memory barriers. I suggest we
> open a separate discussion about that and add these and the appropriate
> fixes in a separate series. There are quite a few places to fix anyway,
> which are currently broken on PPC so this patch doesn't make things any
> worse. However adding a new memory barrier doesn't belong to an LRO
> functionality and thus to this series.

This is an interesting discussion. Just for reference, I submitted a
patch on this topic but it was probably too early as only Intel
architecture was supported at that time.

See http://dpdk.org/ml/archives/dev/2014-May/002597.html

Regards,
Olivier

[dpdk-dev] [RFC PATCH 0/7] add OSv support

[Bruce Richardson]

On Fri, Mar 13, 2015 at 06:05:41AM +0900, Takuya ASADA wrote:
> Hi DPDK developers,
> 
> I'd like to contribute a new EAL to support our open-sourced operating system 
> called "OSv".
> It is a new operating system build from scratch for cloud computing, to run 
> application faster with lower footprint on IaaS.
> Unlike general propose OS, it is a library OS designed to run single 
> application per one instance, everything run in kernel mode, single memory 
> space.
> It's not using Linux kernel but has compatibility with Linux application, not 
> perfect but we already supported various applications such as Cassandra, 
> memcached, Redis, etc.
> 
> In DPDK case, PMDs can access devices directly, without kernel driver help.
> At this point I haven't enough optimized performance of the EAL yet, but it 
> has potential to get better performance than Linux with fewer resources.
> 
> OSv web site: http://osv.io
> USENIX ATC'14 paper: 
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/kivity

This sounds really interesting. Any chance of adding in a "Getting Started 
Guide"
with your patchset to make it easy for us to try out DPDK on OSv?

> 
> Takuya ASADA (7):
>   mk: support compiling C++ code
>   eal: Add extern C on eal_hugepages.h
>   eal: Add extern C on eal_thread.h
>   eal: Add extern C on eal_private.h
>   add OSv support
>   virtio: enable MSI-X on OSv
>   app/test: support OSv
> 
>  app/test/test_eal_flags.c  |  34 +--
>  app/test/test_timer_perf.c |   2 +-
>  config/{common_linuxapp => common_osvapp}  |  20 +-
>  ...xapp-gcc => defconfig_x86_64-native-osvapp-gcc} |   2 +-
>  lib/librte_eal/Makefile|   2 +
>  lib/librte_eal/common/eal_hugepages.h  |   8 +
>  lib/librte_eal/common/eal_private.h|   8 +
>  lib/librte_eal/common/eal_thread.h |   8 +
>  Makefile => lib/librte_eal/osvapp/Makefile |   5 +-
>  lib/librte_eal/osvapp/eal/Makefile | 115 
>  lib/librte_eal/{linuxapp => osvapp}/eal/eal.c  | 123 +---
>  .../{linuxapp => osvapp}/eal/eal_alarm.c   |   0
>  .../{linuxapp => osvapp}/eal/eal_debug.c   |   0
>  lib/librte_eal/osvapp/eal/eal_hugepage_info.cc |  63 +
>  .../{bsdapp => osvapp}/eal/eal_interrupts.c|   0
>  .../eal/eal_lcore.c => osvapp/eal/eal_lcore.cc}|  53 ++--
>  lib/librte_eal/{bsdapp => osvapp}/eal/eal_log.c|   0
>  lib/librte_eal/osvapp/eal/eal_memory.cc| 148 ++
>  lib/librte_eal/osvapp/eal/eal_pci.cc   | 311 
> +
>  .../{linuxapp => osvapp}/eal/eal_thread.c  |   0
>  lib/librte_eal/osvapp/eal/eal_timer.c  | 121 
>  .../eal/include/exec-env/rte_interrupts.h  |   0
>  lib/librte_pmd_virtio/virtio_ethdev.c  |  15 +-
>  mk/exec-env/{linuxapp => osvapp}/rte.app.mk|   0
>  mk/exec-env/{linuxapp => osvapp}/rte.vars.mk   |   6 +-
>  mk/internal/rte.compile-pre.mk |  41 ++-
>  mk/target/generic/rte.vars.mk  |   4 +
>  mk/toolchain/gcc/rte.vars.mk   |   5 +-
>  28 files changed, 907 insertions(+), 187 deletions(-)
>  copy config/{common_linuxapp => common_osvapp} (97%)
>  copy config/{defconfig_x86_64-native-linuxapp-gcc => 
> defconfig_x86_64-native-osvapp-gcc} (98%)
>  copy Makefile => lib/librte_eal/osvapp/Makefile (93%)
>  create mode 100644 lib/librte_eal/osvapp/eal/Makefile
>  copy lib/librte_eal/{linuxapp => osvapp}/eal/eal.c (87%)
>  copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_alarm.c (100%)
>  copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_debug.c (100%)
>  create mode 100644 lib/librte_eal/osvapp/eal/eal_hugepage_info.cc
>  copy lib/librte_eal/{bsdapp => osvapp}/eal/eal_interrupts.c (100%)
>  copy lib/librte_eal/{bsdapp/eal/eal_lcore.c => osvapp/eal/eal_lcore.cc} (80%)
>  copy lib/librte_eal/{bsdapp => osvapp}/eal/eal_log.c (100%)
>  create mode 100644 lib/librte_eal/osvapp/eal/eal_memory.cc
>  create mode 100644 lib/librte_eal/osvapp/eal/eal_pci.cc
>  copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_thread.c (100%)
>  create mode 100644 lib/librte_eal/osvapp/eal/eal_timer.c
>  copy lib/librte_eal/{bsdapp => osvapp}/eal/include/exec-env/rte_interrupts.h 
> (100%)
>  copy mk/exec-env/{linuxapp => osvapp}/rte.app.mk (100%)
>  copy mk/exec-env/{linuxapp => osvapp}/rte.vars.mk (95%)
> 
> -- 
> 2.1.0
> 

[dpdk-dev] [PATCH v3] ABI: Add abi checking utility

[Thomas Monjalon]

Hi Neil,

2015-03-11 15:36, Neil Horman:
> On Thu, Mar 05, 2015 at 11:57:27AM -0500, Neil Horman wrote:
> > On Wed, Mar 04, 2015 at 05:49:50PM +0100, Thomas Monjalon wrote:
> > > 2015-03-04 11:26, Neil Horman:
> > > > +#trap on ctrl-c to clean up
> > > > +trap cleanup_and_exit SIGINT
> > > 
> > > I think INT is preffered over SIGINT.
> > > You may also add QUIT and TERM.
> > > With QUIT, you can replace cleanup_and_exit calls by a simple exit.
> > > 
> > > > +   CURRENT_BRANCH=`git log --pretty=format:%H HEAD~1..HEAD`
> > > 
> > > May be simpler "git log -1 --format=%H"
> > > 
> > It might be, but the above is equivalent, and --format is a more recent 
> > git-log
> > feature.  Older versions still require --pretty=format
> > 
> > > > +log "INFO" "We're going to check and make sure that applications built"
> > > > +log "INFO" "against DPDK DSOs from tag $TAG1 will still run when 
> > > > executed"
> > > > +log "INFO" "against DPDK DSOs built from tag $TAG2."
> > > 
> > > I think it may be removed as no app is run.
> > > 
> > The above doesn't indicate that an application will be run, only that the
> > purpose of this script is to ensure that older applications will still run,
> > which I think is appropriate.
> > 
> > > > +# Make sure we configure SHARED libraries
> > > > +# Also turn off IGB and KNI as those require kernel headers to build
> > > > +sed -i -e"$ a\CONFIG_RTE_BUILD_SHARED_LIB=y" config/defconfig_$TARGET
> > > > +sed -i -e"$ a\CONFIG_RTE_EAL_IGB_UIO=n" config/defconfig_$TARGET
> > > > +sed -i -e"$ a\CONFIG_RTE_LIBRTE_KNI=n" config/defconfig_$TARGET
> > > 
> > > So you prefer modifying defconfig instead of .config, right?
> > > (you sent it while I was answering on v2)
> > > 
> > Yes, correct.
> > 
> > > > +# Checking abi compliance relies on using the dwarf information in
> > > > +# The shared objects.  Thats only included in the DSO's if we build
> > > > +# with -g
> > > > +export EXTRA_CFLAGS=-g
> > > > +export EXTRA_LDFLAGS=-g
> > > [...]
> > > > +export EXTRA_CFLAGS=-g
> > > > +export EXTRA_LDFLAGS=-g
> > > 
> > > Already exported.
> > > 
> > Yeah, I'll clean that up later.

OK, could you send a v4 please?

> > > > +   OLDNAME=`basename $i | sed -e"s/1.dump/0.dump/"`
> > > 
> > > Could be OLDNAME=$(basename $i 1.dump)0.dump
> > > 
> > > > +   LIBNAME=`basename $i | sed -e"s/-ABI-1.dump//"`
> > > 
> > > Could be LIBNAME=$(basename $i -ABI-1.dump)
> > > 
> > It could be, but I prefer the clarity of the sed replacement.
> > 
> > Neil
> > 
> > > Thanks
> > > 
> > > 
> > 
> 
> Ping Thomas, is this going to make 2.0?

Yes sure, waiting a v4.

[dpdk-dev] [PATCH] ethdev: additional parameter in RX callback

[Neil Horman]

On Fri, Mar 13, 2015 at 09:41:33AM +, Bruce Richardson wrote:
> On Thu, Mar 12, 2015 at 03:15:40PM -0400, Neil Horman wrote:
> > On Thu, Mar 12, 2015 at 04:54:27PM +, John McNamara wrote:
> > > 
> > > This patch is a minor extension to the recent patchset for RX/TX callbacks
> > > based on feedback from users implementing solutions based on it.
> > > 
> > > The patch adds a new parameter to the RX callback to pass in the number of
> > > available RX packets in addition to the number of dequeued packets.
> > > This provides the RX callback functions with additional information
> > > that can be used to decide how packets from a burst are handled.
> > > 
> > > The TX callback doesn't require this additional parameter so the RX
> > > and TX callbacks no longer have the same function parameters. As such
> > > the single RX/TX callback has been refactored into two separate callbacks.
> > > 
> > > Since this is an API change we hope it can be included in 2.0.0 to avoid
> > > changing the API in a subsequent release.
> > > 
> > > 
> > > John McNamara (1):
> > >   ethdev: added additional packet count parameter to RX callbacks
> > > 
> > >  examples/rxtx_callbacks/main.c |3 +-
> > >  lib/librte_ether/rte_ethdev.c  |8 ++--
> > >  lib/librte_ether/rte_ethdev.h  |   74 
> > > ++--
> > >  3 files changed, 54 insertions(+), 31 deletions(-)
> > > 
> > > -- 
> > > 1.7.4.1
> > > 
> > > 
> > 
> > 
> > Well, we're well past the new feature phase of this cycle, so I would say 
> > NACK.
> > I would also suggest that you don't need to modify ABI to accomodate this
> > feature.  Instead just document the pkts array to be terminated by a 
> > reserved
> > value, so that the callback can determine its size dynamically.  You could
> > alternatively create a new api call that allows you to retrieve that 
> > information
> > from the context of the callback.
> > 
> > Neil
> > 
> 
> Yes, I would agree we are past the new feature phase. However, given that we
> are making a change to the API, and a fairly small change too - adding one 
> extra
> parameter - we think that the benefit of including this now outweighs any risk
> of merging the patch. It seems a bit crazy to ship a release with a new API 
> and
> then immediately change the API straight after release. Is it not better to
> take the received feedback on the API and fix/improve it pre-release before it
> gets set-in-stone?
> 
> /Bruce
> 
> 

See above, the API doesn't need to change at all to accomodate this as far as I
can see.

Neil

[dpdk-dev] [PATCH] common/rte_memcpy: Fix x86intrin.h missed

[Ananyev, Konstantin]

Hi Michael,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu
> Sent: Friday, March 13, 2015 7:03 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] common/rte_memcpy: Fix x86intrin.h missed
> 
> rte_memcpy.h(46): catastrophic error: cannot open source file "x86intrin.h"
> 
> For icc and old gcc, this header is not included.
> 
> Signed-off-by: Michael Qiu 
> ---
>  lib/librte_eal/common/include/arch/x86/rte_memcpy.h | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h 
> b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> index ac72069..bd10d36 100644
> --- a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> +++ b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> @@ -43,7 +43,27 @@
>  #include 
>  #include 
>  #include 
> +#if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
> +
> +#ifdef __SSE__
> +#include 
> +#endif
> +
> +#ifdef __SSE2__
> +#include 
> +#endif
> +
> +#if defined(__SSE4_2__) || defined(__SSE4_1__)
> +#include 
> +#endif
> +
> +#if defined(__AVX__)
> +#include 
> +#endif
> +
> +#else
>  #include 
> +#endif
> 
>  #ifdef __cplusplus
>  extern "C" {
> --
> 1.9.3

Wonder why to spread this thing over?
Why not just #include ?

Konstantin

[dpdk-dev] [RFC PATCH 0/7] add OSv support

[Neil Horman]

On Fri, Mar 13, 2015 at 06:05:41AM +0900, Takuya ASADA wrote:
> Hi DPDK developers,
> 
> I'd like to contribute a new EAL to support our open-sourced operating system 
> called "OSv".
> It is a new operating system build from scratch for cloud computing, to run 
> application faster with lower footprint on IaaS.
> Unlike general propose OS, it is a library OS designed to run single 
> application per one instance, everything run in kernel mode, single memory 
> space.
> It's not using Linux kernel but has compatibility with Linux application, not 
> perfect but we already supported various applications such as Cassandra, 
> memcached, Redis, etc.
> 
> In DPDK case, PMDs can access devices directly, without kernel driver help.
> At this point I haven't enough optimized performance of the EAL yet, but it 
> has potential to get better performance than Linux with fewer resources.
> 
> OSv web site: http://osv.io
> USENIX ATC'14 paper: 
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/kivity
> 
> Takuya ASADA (7):
>   mk: support compiling C++ code
>   eal: Add extern C on eal_hugepages.h
>   eal: Add extern C on eal_thread.h
>   eal: Add extern C on eal_private.h
>   add OSv support
>   virtio: enable MSI-X on OSv
>   app/test: support OSv
> 
>  app/test/test_eal_flags.c  |  34 +--
>  app/test/test_timer_perf.c |   2 +-
>  config/{common_linuxapp => common_osvapp}  |  20 +-
>  ...xapp-gcc => defconfig_x86_64-native-osvapp-gcc} |   2 +-
>  lib/librte_eal/Makefile|   2 +
>  lib/librte_eal/common/eal_hugepages.h  |   8 +
>  lib/librte_eal/common/eal_private.h|   8 +
>  lib/librte_eal/common/eal_thread.h |   8 +
>  Makefile => lib/librte_eal/osvapp/Makefile |   5 +-
>  lib/librte_eal/osvapp/eal/Makefile | 115 
>  lib/librte_eal/{linuxapp => osvapp}/eal/eal.c  | 123 +---
>  .../{linuxapp => osvapp}/eal/eal_alarm.c   |   0
>  .../{linuxapp => osvapp}/eal/eal_debug.c   |   0
>  lib/librte_eal/osvapp/eal/eal_hugepage_info.cc |  63 +
>  .../{bsdapp => osvapp}/eal/eal_interrupts.c|   0
>  .../eal/eal_lcore.c => osvapp/eal/eal_lcore.cc}|  53 ++--
>  lib/librte_eal/{bsdapp => osvapp}/eal/eal_log.c|   0
>  lib/librte_eal/osvapp/eal/eal_memory.cc| 148 ++
>  lib/librte_eal/osvapp/eal/eal_pci.cc   | 311 
> +
>  .../{linuxapp => osvapp}/eal/eal_thread.c  |   0
>  lib/librte_eal/osvapp/eal/eal_timer.c  | 121 
>  .../eal/include/exec-env/rte_interrupts.h  |   0
>  lib/librte_pmd_virtio/virtio_ethdev.c  |  15 +-
>  mk/exec-env/{linuxapp => osvapp}/rte.app.mk|   0
>  mk/exec-env/{linuxapp => osvapp}/rte.vars.mk   |   6 +-
>  mk/internal/rte.compile-pre.mk |  41 ++-
>  mk/target/generic/rte.vars.mk  |   4 +
>  mk/toolchain/gcc/rte.vars.mk   |   5 +-
>  28 files changed, 907 insertions(+), 187 deletions(-)
>  copy config/{common_linuxapp => common_osvapp} (97%)
>  copy config/{defconfig_x86_64-native-linuxapp-gcc => 
> defconfig_x86_64-native-osvapp-gcc} (98%)
>  copy Makefile => lib/librte_eal/osvapp/Makefile (93%)
>  create mode 100644 lib/librte_eal/osvapp/eal/Makefile
>  copy lib/librte_eal/{linuxapp => osvapp}/eal/eal.c (87%)
>  copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_alarm.c (100%)
>  copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_debug.c (100%)
>  create mode 100644 lib/librte_eal/osvapp/eal/eal_hugepage_info.cc
>  copy lib/librte_eal/{bsdapp => osvapp}/eal/eal_interrupts.c (100%)
>  copy lib/librte_eal/{bsdapp/eal/eal_lcore.c => osvapp/eal/eal_lcore.cc} (80%)
>  copy lib/librte_eal/{bsdapp => osvapp}/eal/eal_log.c (100%)
>  create mode 100644 lib/librte_eal/osvapp/eal/eal_memory.cc
>  create mode 100644 lib/librte_eal/osvapp/eal/eal_pci.cc
>  copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_thread.c (100%)
>  create mode 100644 lib/librte_eal/osvapp/eal/eal_timer.c
>  copy lib/librte_eal/{bsdapp => osvapp}/eal/include/exec-env/rte_interrupts.h 
> (100%)
>  copy mk/exec-env/{linuxapp => osvapp}/rte.app.mk (100%)
>  copy mk/exec-env/{linuxapp => osvapp}/rte.vars.mk (95%)
> 
> -- 
> 2.1.0
> 
> 

I presume you intend for this to get merged during the 2.1 release?

Neil

[dpdk-dev] [PATCH] ethdev: additional parameter in RX callback

[Bruce Richardson]

On Thu, Mar 12, 2015 at 03:15:40PM -0400, Neil Horman wrote:
> On Thu, Mar 12, 2015 at 04:54:27PM +, John McNamara wrote:
> > 
> > This patch is a minor extension to the recent patchset for RX/TX callbacks
> > based on feedback from users implementing solutions based on it.
> > 
> > The patch adds a new parameter to the RX callback to pass in the number of
> > available RX packets in addition to the number of dequeued packets.
> > This provides the RX callback functions with additional information
> > that can be used to decide how packets from a burst are handled.
> > 
> > The TX callback doesn't require this additional parameter so the RX
> > and TX callbacks no longer have the same function parameters. As such
> > the single RX/TX callback has been refactored into two separate callbacks.
> > 
> > Since this is an API change we hope it can be included in 2.0.0 to avoid
> > changing the API in a subsequent release.
> > 
> > 
> > John McNamara (1):
> >   ethdev: added additional packet count parameter to RX callbacks
> > 
> >  examples/rxtx_callbacks/main.c |3 +-
> >  lib/librte_ether/rte_ethdev.c  |8 ++--
> >  lib/librte_ether/rte_ethdev.h  |   74 
> > ++--
> >  3 files changed, 54 insertions(+), 31 deletions(-)
> > 
> > -- 
> > 1.7.4.1
> > 
> > 
> 
> 
> Well, we're well past the new feature phase of this cycle, so I would say 
> NACK.
> I would also suggest that you don't need to modify ABI to accomodate this
> feature.  Instead just document the pkts array to be terminated by a reserved
> value, so that the callback can determine its size dynamically.  You could
> alternatively create a new api call that allows you to retrieve that 
> information
> from the context of the callback.
> 
> Neil
> 

Yes, I would agree we are past the new feature phase. However, given that we
are making a change to the API, and a fairly small change too - adding one extra
parameter - we think that the benefit of including this now outweighs any risk
of merging the patch. It seems a bit crazy to ship a release with a new API and
then immediately change the API straight after release. Is it not better to
take the received feedback on the API and fix/improve it pre-release before it
gets set-in-stone?

/Bruce

[dpdk-dev] [PATCH v2 01/15] eal: Fix cording style of eal_pci.c and eal_pci_uio.c

[Tetsuya Mukawa]

2015-03-12 20:09 GMT+09:00 Bruce Richardson :
> On Thu, Mar 12, 2015 at 10:57:18AM +, Qiu, Michael wrote:
>> On 3/12/2015 6:50 PM, Bruce Richardson wrote:
>> > On Thu, Mar 12, 2015 at 07:17:40PM +0900, Tetsuya Mukawa wrote:
>> >> This patch fixes cording style of below files in linuxapp and bsdapp.
>> >>  - eal_pci.c
>> >>  - eal_pci_uio.c
>> >>
>> >> Signed-off-by: Tetsuya Mukawa 
>> > Hi Tetsuya,
>> >
>> > While there is some good cleanup here, I disagree with a number of the 
>> > changes
>> > made purely to the whitespace in the file. The style of using a 
>> > double-indent
>> > for line continuations is very widely used in DPDK code, much more so than 
>> > the
>> > style of lining things up with the previous line.
>>
>> Yes, but both style are seeing in dpdk, here the patch is using Tab +
>> whitespace, which is also
>> the linux kernel's style.
>>
>> So is there any rule to allow only one style?
>> Mixed style is bad...
>>
>> Thanks,
>> Michael
>
> No there is no hard rule, that I am aware of. While I prefer the double-indent
> myself, that is beside the point that in the absense of a hard rule to be 
> applied
> globally, fixing whitespace from style A to style B just increases the size
> of the diff which makes it hard to see the real code changes. Even with a 
> slight
> mixing of the styles the code is readable enough as-is.
>
> /Bruce

Hi Bruce, Michael,

Thanks for your reviews.
I will fix it, and submit again early next week.

Regards,
Tetsuya

>
>> > So ack to the changes removing unnecessary braces, and occasional 
>> > splitting of
>> > really long lines (though a few chars over 80 is ok). NAK to the whitespace
>> > and indentation changes.
>> >
>> > Regards,
>> > /Bruce
>> >
>> >> ---
>> >>  lib/librte_eal/bsdapp/eal/eal_pci.c   | 67 
>> >> ++-
>> >>  lib/librte_eal/linuxapp/eal/eal_pci.c | 32 +--
>> >>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 37 ++---
>> >>  3 files changed, 80 insertions(+), 56 deletions(-)
>> >>
>> >> diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c 
>> >> b/lib/librte_eal/bsdapp/eal/eal_pci.c
>> >> index fe3ef86..cbd0a4e 100644
>> >> --- a/lib/librte_eal/bsdapp/eal/eal_pci.c
>> >> +++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
>> >> @@ -142,8 +142,9 @@ pci_map_resource(void *requested_addr, const char 
>> >> *devname, off_t offset,
>> >>MAP_SHARED, fd, offset);
>> >>close(fd);
>> >>if (mapaddr == MAP_FAILED ||
>> >> -  (requested_addr != NULL && mapaddr != requested_addr)) 
>> >> {
>> >> -  RTE_LOG(ERR, EAL, "%s(): cannot mmap(%s(%d), %p, 0x%lx, 
>> >> 0x%lx):"
>> >> +  (requested_addr != NULL && mapaddr != requested_addr)) {
>> >> +  RTE_LOG(ERR, EAL,
>> >> +  "%s(): cannot mmap(%s(%d), %p, 0x%lx, 0x%lx):"
>> >>" %s (%p)\n", __func__, devname, fd, requested_addr,
>> >>(unsigned long)size, (unsigned long)offset,
>> >>strerror(errno), mapaddr);
>> >> @@ -161,9 +162,10 @@ fail:
>> >>  static int
>> >>  pci_uio_map_secondary(struct rte_pci_device *dev)
>> >>  {
>> >> -size_t i;
>> >> -struct uio_resource *uio_res;
>> >> -  struct uio_res_list *uio_res_list = RTE_TAILQ_CAST(rte_uio_tailq.head, 
>> >> uio_res_list);
>> >> +  size_t i;
>> >> +  struct uio_resource *uio_res;
>> >> +  struct uio_res_list *uio_res_list =
>> >> +  RTE_TAILQ_CAST(rte_uio_tailq.head, uio_res_list);
>> >>
>> >>TAILQ_FOREACH(uio_res, uio_res_list, next) {
>> >>
>> >> @@ -179,10 +181,10 @@ pci_uio_map_secondary(struct rte_pci_device *dev)
>> >>!= uio_res->maps[i].addr) {
>> >>RTE_LOG(ERR, EAL,
>> >>"Cannot mmap device resource\n");
>> >> -  return (-1);
>> >> +  return -1;
>> >>}
>> >>}
>> >> -  return (0);
>> >> +  return 0;
>> >>}
>> >>
>> >>RTE_LOG(ERR, EAL, "Cannot find resource for device\n");
>> >> @@ -201,7 +203,8 @@ pci_uio_map_resource(struct rte_pci_device *dev)
>> >>uint64_t pagesz;
>> >>struct rte_pci_addr *loc = >addr;
>> >>struct uio_resource *uio_res;
>> >> -  struct uio_res_list *uio_res_list = RTE_TAILQ_CAST(rte_uio_tailq.head, 
>> >> uio_res_list);
>> >> +  struct uio_res_list *uio_res_list =
>> >> +  RTE_TAILQ_CAST(rte_uio_tailq.head, uio_res_list);
>> >>struct uio_map *maps;
>> >>
>> >>dev->intr_handle.fd = -1;
>> >> @@ -209,14 +212,16 @@ pci_uio_map_resource(struct rte_pci_device *dev)
>> >>
>> >>/* secondary processes - use already recorded details */
>> >>if (rte_eal_process_type() != RTE_PROC_PRIMARY)
>> >> -  return (pci_uio_map_secondary(dev));
>> >> +  return pci_uio_map_secondary(dev);
>> >>
>> >>snprintf(devname, sizeof(devname), "/dev/uio at pci:%u:%u:%u",
>> >>

[dpdk-dev] [PATCH v2 0/2] doc: update doc for fm10k driver

[Butler, Siobhan A]

Acked-by Siobhan Butler 

On Mar 13, 2015 9:14 AM, "Chen, Jing D"  wrote:
From: "Chen Jing D(Mark)" 

Update programming guide and release notes for fm10k driver.

Changes in v2:
- Remove a punctuation.


Chen Jing D(Mark) (2):
  doc: update programmers guide for fm10k pmd driver
  doc: update release note for fm10k pmd driver

 .../prog_guide/i40e_ixgbe_igb_virt_func_drv.rst|   37 ++-
 doc/guides/prog_guide/source_org.rst   |1 +
 doc/guides/rel_notes/new_features.rst  |   20 +++
 3 files changed, 56 insertions(+), 2 deletions(-)

--
1.7.7.6

[dpdk-dev] [PATCH v2 2/2] doc: update release note for fm10k pmd driver

[Butler, Siobhan A]

Acked-by Siobhan Butler 

On Mar 13, 2015 9:14 AM, "Chen, Jing D"  wrote:
From: "Chen Jing D(Mark)" 

Add feature list for fm10k driver.

Signed-off-by: Chen Jing D(Mark) 
---
 doc/guides/rel_notes/new_features.rst |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/doc/guides/rel_notes/new_features.rst 
b/doc/guides/rel_notes/new_features.rst
index 2993b1e..a27e360 100644
--- a/doc/guides/rel_notes/new_features.rst
+++ b/doc/guides/rel_notes/new_features.rst
@@ -58,4 +58,24 @@ New Features

 *   Packet Distributor Sample Application

+*   Poll Mode Driver - PCIE host-interface of Intel Ethernet Switch FM1 
Series (librte_pmd_fm10k)
+
+*   Basic Rx/Tx functions for PF/VF
+
+*   Interrupt handling support for PF/VF
+
+*   Per queue start/stop functions for PF/VF
+
+*   Support Mailbox handling between PF/VF and PF/Switch Manager
+
+*   Receive Side Scaling (RSS) for PF/VF
+
+*   Scatter receive function for PF/VF
+
+*   Reta update/query for PF/VF
+
+*   VLAN filter set for PF
+
+*   Link status query for PF/VF
+
 For further features supported in this release, see Chapter 3 Supported 
Features.
--
1.7.7.6

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Neil Horman]

On Fri, Mar 13, 2015 at 11:48:59AM +, Gonzalez Monroy, Sergio wrote:
> On 13/03/2015 11:34, Kavanagh, Mark B wrote:
> >>On 13/03/2015 10:49, Kavanagh, Mark B wrote:
> ---
> config/common_bsdapp|   6 --
> config/common_linuxapp  |   6 --
> config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
> lib/Makefile|   1 -
> mk/rte.app.mk   |  12 
> mk/rte.lib.mk   |  35 --
> mk/rte.sdkbuild.mk  |   3 -
> mk/rte.sharelib.mk  | 101 
> 
> mk/rte.vars.mk  |   9 ---
> 9 files changed, 175 deletions(-)
> delete mode 100644 mk/rte.sharelib.mk
> 
> diff --git a/config/common_bsdapp b/config/common_bsdapp
> index 8ff4dc2..7ee5ecf 100644
> --- a/config/common_bsdapp
> +++ b/config/common_bsdapp
> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
> CONFIG_RTE_BUILD_SHARED_LIB=n
> 
> #
> -# Combine to one single library
> -#
> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
> -CONFIG_RTE_LIBNAME=intel_dpdk
> >>>Hi Sergio,
> >>>
> >>>Removing these options breaks compatibility with OVS. While it may be 
> >>>feasible to link
> >>to individual static libraries, in our experience, a single combined 
> >>library provides a
> >>much more convenient way of linking.
> >>>Thanks,
> >>>Mark
> >>>
> -
> >
> >(snip)
> >
> >
> -endif
> -
> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
> -ifeq ($(RTE_LIBNAME),)
> -RTE_LIBNAME := intel_dpdk
> endif
> 
> # RTE_TARGET is deducted from config when we are building the SDK.
> --
> 1.9.3
> >>Hi Mark,
> >>
> >>How does this patch break compatibility with OVS?
> >>
> >>Thanks,
> >>Sergio
> >Hey Sergio,
> >
> >We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to 
> >build a single static DPDK library, named 'libintel_dpdk.a', which OVS links 
> >against. Removing the combined library option breaks compatibility with any 
> >application that links against the combined DPDK library.
> >
> >Is there a strong technical motivation for removing these options?
> >
> >Thanks,
> >Mark
> From a shared library point of view, it just does not make sense to have
> applications linked against a 'combined' library that may have different
> features built in it.
> 
> Removing these options, aside from the obvious 'less build config option',
> it simplifies maintenance of makefiles as we currently have a separated
> makefile with specific rules just for combined library.
> 
> It is pretty straight forward to build a single combined archive out of
> multiple archives, would it be acceptable to have a script to do this?
> 
> Thanks,
> Sergio
> 
+1

For the static case, its easy to do a post build combination of archives.  For
the shared library case, its equally easy to simply create a linker scripts call
.so that pulls in all the individual libraries.

Neil

[dpdk-dev] [RFC] af_packet: support port hotplug

[Tetsuya Mukawa]

2015-03-13 2:05 GMT+09:00 Iremonger, Bernard :
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John W. Linville
>> Sent: Tuesday, March 10, 2015 6:36 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [RFC] af_packet: support port hotplug
>>
>> This patch adds finalization code to free resources allocated by the PMD.  
>> This is based on earlier
>> patches for other PMDs by Tetsuya Mukawa , with 
>> corrections related to data-
>> >name.
>>
>> Signed-off-by: John W. Linville 
>> Cc: Tetsuya Mukawa 
>> ---
>>  lib/librte_pmd_af_packet/rte_eth_af_packet.c | 56 
>> 
>>  1 file changed, 56 insertions(+)
>>
>> diff --git a/lib/librte_pmd_af_packet/rte_eth_af_packet.c
>> b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
>> index 80e9bdf7f819..57998ab19c96 100644
>> --- a/lib/librte_pmd_af_packet/rte_eth_af_packet.c
>> +++ b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
>> @@ -399,6 +399,13 @@ static struct eth_dev_ops ops = {
>>   .stats_reset = eth_stats_reset,
>>  };
>>
>> +static struct eth_driver rte_af_packet_pmd = {
>> + .pci_drv = {
>> + .name = "rte_af_packet_pmd",
>> + .drv_flags = RTE_PCI_DRV_DETACHABLE,
>> + },
>> +};
>> +
>>  /*
>>   * Opens an AF_PACKET socket
>>   */
>> @@ -653,6 +660,10 @@ rte_pmd_init_internals(const char *name,
>>   if (*eth_dev == NULL)
>>   goto error;
>>
>> + /* check length of device name */
>> + if ((strlen((*eth_dev)->data->name) + 1) > sizeof(data->name))
>> + goto error;
>> +
>>   /*
>>* now put it all together
>>* - store queue data in internals,
>> @@ -669,12 +680,14 @@ rte_pmd_init_internals(const char *name,
>>   data->nb_tx_queues = (uint16_t)nb_queues;
>>   data->dev_link = pmd_link;
>>   data->mac_addrs = &(*internals)->eth_addr;
>> + strncpy(data->name, (*eth_dev)->data->name,
>> +strlen((*eth_dev)->data->name));
>>
>>   pci_dev->numa_node = numa_node;
>>
>>   (*eth_dev)->data = data;
>>   (*eth_dev)->dev_ops = 
>>   (*eth_dev)->pci_dev = pci_dev;
>> + (*eth_dev)->driver = _af_packet_pmd;
>>
>>   return 0;
>>
>> @@ -835,10 +848,53 @@ rte_pmd_af_packet_devinit(const char *name, const char 
>> *params)
>>   return 0;
>>  }
>>
>> +static int
>> +rte_pmd_af_packet_devuninit(const char *name) {
>> + struct rte_eth_dev *eth_dev = NULL;
>> + struct pmd_internals *internals;
>> + struct tpacket_req req;
>> +
>> + unsigned q;
>> +
>> + RTE_LOG(INFO, PMD, "Closing AF_PACKET ethdev on numa socket %u\n",
>> + rte_socket_id());
>> +
>> + if (name == NULL)
>> + return -1;
>
> Hi  Tetsuya, John,
>
> Before detaching a port, the port must be stopped and closed.
> The stop and close are only allowed for RTE_PROC_PRIMARY.
> Should there be a check for process_type here?
>
> if (rte_eal_process_type() != RTE_PROC_PRIMARY)
> return -EPERM;
>
> Regards,
>
> Bernard
>

Hi Bernard,

I agree with stop() and close() are only called by primary process,
but it may not need to add like above.
Could you please check rte_ethdev.c?

- struct rte_eth_dev_data *rte_eth_dev_data;
This array is shared between processes.
So we need to initialize of finalize carefully like you said.

- struct rte_eth_dev rte_eth_devices[]
This array is per process.
And 'data' variable of this structure indicates a pointer of rte_eth_dev_data.

All PMDs for physical NIC allocates like above when PMDs are initialized.
(Even when a process is secondary, initialization function of PMDs
will be called)
But virtual device PMDs allocate rte_eth_dev_data and overwrite 'data'
variable of rte_eth_devices while initialization.

As a result, primary and secondary process has their own
'rte_eth_dev_data' for a virtual device.
So I guess all processes need to free it not to leak memory.

Thanks,
Tetsuya

>> +
>> + /* retrieve ethdev entry */
>> + eth_dev = rte_eth_dev_allocated(name);
>> + if (eth_dev == NULL)
>> + return -1;
>> +
>> + internals = eth_dev->data->dev_private;
>> + req = internals->req;
>> +
>> + for (q = 0; q < internals->nb_queues; q++) {
>> + munmap(internals->rx_queue[q].map,
>> +2 * req.tp_block_size * req.tp_block_nr);
>> + if (internals->rx_queue[q].rd)
>> + rte_free(internals->rx_queue[q].rd);
>> + if (internals->tx_queue[q].rd)
>> + rte_free(internals->tx_queue[q].rd);
>> + }
>> +
>> + rte_free(internals);
>> + rte_free(eth_dev->data);
>> + rte_free(eth_dev->pci_dev);
>> +
>> + rte_eth_dev_release_port(eth_dev);
>> +
>> +
>> + return 0;
>> +}
>> +
>>  static struct rte_driver pmd_af_packet_drv = {
>>   .name = "eth_af_packet",
>>   .type = PMD_VDEV,
>>   .init = rte_pmd_af_packet_devinit,
>> + .uninit = rte_pmd_af_packet_devuninit,
>>  };
>>
>>  

[dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Stephen Hemminger]

On Thu, 12 Mar 2015 16:27:58 +
Sergio Gonzalez Monroy  wrote:

> Remove CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LIBNAME.
> 
> Signed-off-by: Sergio Gonzalez Monroy 
> ---

NAK. The combined library is good and useful for those who want simplicity
and build with static library.

It is not clear what you are trying to solve.

[dpdk-dev] Testing Summary about DPDK R2.0 RC1

[Cao, Waterman]

Hi Thomas,

We are test RC1 package with full test suite in last two weeks.
Since there are compilation errors in RC1, we have to verify latest
DPDK mater branch.
Till now, there are the following issues in master branch.
Please help to prioritize to merge fixed patches.

Thanks
waterman

Issues List:

Issue #1 (Priority H)
- Descriptions :  Errors in Centos 6.5 , Kenerl 2.6.32-431, GCC
4.4.7 / OracleLinux6.4, Kernel 2.6.39, GCC 4.4.7, ICC 14.0.0 /
RedHat6.5, Kenerl 2.6.32, GCC 4.4.7
  CC test_hash.o
cc1: warnings being treated as errors

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/app/test/test_hash.c:
In function ?test_crc32_hash_alg_equiv?:

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
note: initialized from here

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
note: initialized from here

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
note: initialized from here

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
note: initialized from here

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:554:
note: initialized from here

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
error: dereferencing pointer ?p64.354? does break strict-aliasing rules

/jenkins/workspace/DPDK_AUTO_IDT_VM_CENTOS65_64_BUILD/DPDK/x86_64-native-linuxapp-gcc/include/rte_hash_crc.h:558:
note: initialized from here
gmake[5]: *** [test_hash.o] Error 1


Issue #2 (Priority H)
- Descriptions :  Errors in Suse11 , Kernel 3.0.13-0, GCC 4.3.4
 == Build lib/librte_eal/linuxapp/eal
gmake[7]: Warning: File
`/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/mk/internal/rte.depdirs-post.mk'
has modification time 2.9e+04 s in the future
  CC eal.o
  CC eal_hugepage_info.o
  CC eal_memory.o
 CC eal_thread.o
  CC eal_log.o
  CC eal_pci.o
  CC eal_pci_uio.o
cc1: warnings being treated as errors

/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/lib/librte_eal/linuxapp/eal/eal_pci_uio.c:
In function ?pci_uio_set_bus_master?:

/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/lib/librte_eal/linuxapp/eal/eal_pci_uio.c:62:2:
error: implicit declaration of function ?pread?

/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/lib/librte_eal/linuxapp/eal/eal_pci_uio.c:62:2:
error: nested extern declaration of ?pread?

/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/lib/librte_eal/linuxapp/eal/eal_pci_uio.c:75:2:
error: implicit declaration of function ?pwrite?

/jenkins/workspace/DPDK_AUTO_IDT_VM_SUSE11SP2_64_BUILD/DPDK/lib/librte_eal/linuxapp/eal/eal_pci_uio.c:75:2:
error: nested extern declaration of ?pwrite?
gmake[7]: *** [eal_pci_uio.o] Error 1
gmake[6]: *** [eal] Error 2
gmake[5]: *** [linuxapp] Error 2
gmake[4]: *** [librte_eal] Error 2
gmake[3]: *** [lib] Error 2
gmake[2]: *** [all] Error 2

Issue #3 (Priority L)
- Descriptions :  Errors in OracleLinux6.4 32Bit OS
CC rte_eth_af_packet.o

/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/lib/librte_pmd_af_packet/rte_eth_af_packet.c:
In function ?eth_af_packet_rx?:

/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/lib/librte_pmd_af_packet/rte_eth_af_packet.c:146:
error: dereferencing pointer to incomplete type

/jenkins/workspace/DPDK_AUTO_IDT_VM_ORACLELINUX64_32_BUILD/DPDK/lib/librte_pmd_af_packet/rte_eth_af_packet.c:155:
error: dereferencing pointer to incomplete type

[dpdk-dev] [PATCH] common/rte_memcpy: Fix x86intrin.h missed

[Wang, Zhihong]

> -Original Message-
> From: Qiu, Michael
> Sent: Friday, March 13, 2015 3:03 PM
> To: dev at dpdk.org
> Cc: Wang, Zhihong; Qiu, Michael
> Subject: [PATCH] common/rte_memcpy: Fix x86intrin.h missed
> 
> rte_memcpy.h(46): catastrophic error: cannot open source file "x86intrin.h"
> 
> For icc and old gcc, this header is not included.
> 
> Signed-off-by: Michael Qiu 
> ---
>  lib/librte_eal/common/include/arch/x86/rte_memcpy.h | 20
> 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> index ac72069..bd10d36 100644
> --- a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> +++ b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
> @@ -43,7 +43,27 @@
>  #include 
>  #include 
>  #include 
> +#if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
> +
> +#ifdef __SSE__
> +#include 
> +#endif
> +
> +#ifdef __SSE2__
> +#include 
> +#endif
> +
> +#if defined(__SSE4_2__) || defined(__SSE4_1__) #include 
> +#endif
> +
> +#if defined(__AVX__)
> +#include 
> +#endif
> +
> +#else
>  #include 
> +#endif
> 
>  #ifdef __cplusplus
>  extern "C" {
> --
> 1.9.3

Acked-by:  Wang, Zhihong 

[dpdk-dev] [RFC PATCH 7/7] app/test: support OSv

[Takuya ASADA]

Add support OSv EAL.

Signed-off-by: Takuya ASADA 
---
 app/test/test_eal_flags.c  | 34 +-
 app/test/test_timer_perf.c |  2 +-
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/app/test/test_eal_flags.c b/app/test/test_eal_flags.c
index 0352f87..40a5c7e 100644
--- a/app/test/test_eal_flags.c
+++ b/app/test/test_eal_flags.c
@@ -287,7 +287,7 @@ static int
 test_whitelist_flag(void)
 {
unsigned i;
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
/* BSD target doesn't support prefixes at this point */
const char * prefix = "";
 #else
@@ -353,7 +353,7 @@ test_whitelist_flag(void)
 static int
 test_invalid_b_flag(void)
 {
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
/* BSD target doesn't support prefixes at this point */
const char * prefix = "";
 #else
@@ -400,7 +400,7 @@ test_invalid_b_flag(void)
 static int
 test_invalid_vdev_flag(void)
 {
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
/* BSD target doesn't support prefixes at this point, and we also need 
to
 * run another primary process here */
const char * prefix = no_shconf;
@@ -454,7 +454,7 @@ test_invalid_vdev_flag(void)
 static int
 test_invalid_r_flag(void)
 {
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
/* BSD target doesn't support prefixes at this point */
const char * prefix = "";
 #else
@@ -498,7 +498,7 @@ test_invalid_r_flag(void)
 static int
 test_missing_c_flag(void)
 {
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
/* BSD target doesn't support prefixes at this point */
const char * prefix = "";
 #else
@@ -629,7 +629,7 @@ test_missing_c_flag(void)
 static int
 test_master_lcore_flag(void)
 {
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
/* BSD target doesn't support prefixes at this point */
const char *prefix = "";
 #else
@@ -677,7 +677,7 @@ test_master_lcore_flag(void)
 static int
 test_missing_n_flag(void)
 {
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
/* BSD target doesn't support prefixes at this point */
const char * prefix = "";
 #else
@@ -722,7 +722,7 @@ test_no_hpet_flag(void)
 {
char prefix[PATH_MAX], tmp[PATH_MAX];

-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
return 0;
 #endif
if (get_current_prefix(tmp, sizeof(tmp)) == NULL) {
@@ -754,7 +754,7 @@ test_no_hpet_flag(void)
 static int
 test_no_huge_flag(void)
 {
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
/* BSD target doesn't support prefixes at this point, and we also need 
to
 * run another primary process here */
const char * prefix = no_shconf;
@@ -782,7 +782,7 @@ test_no_huge_flag(void)
printf("Error - process run ok with --no-huge and -m flags\n");
return -1;
}
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
/* BSD target does not support NUMA, hence no --socket-mem tests */
return 0;
 #endif
@@ -870,7 +870,7 @@ static int
 test_misc_flags(void)
 {
char hugepath[PATH_MAX] = {0};
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
/* BSD target doesn't support prefixes at this point */
const char * prefix = "";
const char * nosh_prefix = "";
@@ -942,7 +942,7 @@ test_misc_flags(void)
const char *argv6[] = {prgname, "-c", "1", "-n", "2", "-m", 
DEFAULT_MEM_SIZE,
no_shconf, nosh_prefix };

-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
return 0;
 #endif
/* With --huge-dir */
@@ -1007,7 +1007,7 @@ test_misc_flags(void)
printf("Error - process did not run ok with --no-shconf 
flag\n");
return -1;
}
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
return 0;
 #endif
if (launch_proc(argv7) != 0) {
@@ -1068,7 +1068,7 @@ test_file_prefix(void)
 * 7. check that only memtest2 hugefiles are present in the hugedir
 */

-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
return 0;
 #endif

@@ -1175,7 +1175,7 @@ test_file_prefix(void)
 static int
 test_memory_flags(void)
 {
-#ifdef RTE_EXEC_ENV_BSDAPP
+#if defined(RTE_EXEC_ENV_BSDAPP) || defined(RTE_EXEC_ENV_OSVAPP)
/* BSD target doesn't support prefixes at this point */
const char * prefix = "";
 #else
@@ -1228,7 +1228,7 @@ test_memory_flags(void)
  

[dpdk-dev] [RFC PATCH 6/7] virtio: enable MSI-X on OSv

[Takuya ASADA]

Add support OSv EAL.

Signed-off-by: Takuya ASADA 
---
 lib/librte_pmd_virtio/virtio_ethdev.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c 
b/lib/librte_pmd_virtio/virtio_ethdev.c
index 603be2d..fed65f3 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -1055,7 +1055,20 @@ static int virtio_resource_init(struct rte_pci_device 
*pci_dev)
return virtio_resource_init_by_ioports(pci_dev);
 }

-#else
+#elif defined(RTE_EXEC_ENV_OSVAPP)
+static int
+virtio_has_msix(const struct rte_pci_addr *loc __rte_unused)
+{
+   /* TODO: ask to OSv this NIC has MSI-X */
+   return 1;
+}
+
+static int virtio_resource_init(struct rte_pci_device *pci_dev __rte_unused)
+{
+   /* no setup required */
+   return 0;
+}
+#else /* BSD */
 static int
 virtio_has_msix(const struct rte_pci_addr *loc __rte_unused)
 {
-- 
2.1.0

[dpdk-dev] [RFC PATCH 5/7] add OSv support

[Takuya ASADA]

Adding OSv support.
Based on Linux/FreeBSD EAL, but calling OSv kernel APIs to access devices, 
allocate contiguous memory, etc.

Signed-off-by: Takuya ASADA 
---
 config/{common_linuxapp => common_osvapp}  |  20 +-
 ...xapp-gcc => defconfig_x86_64-native-osvapp-gcc} |   2 +-
 lib/librte_eal/Makefile|   2 +
 Makefile => lib/librte_eal/osvapp/Makefile |   5 +-
 lib/librte_eal/osvapp/eal/Makefile | 115 
 lib/librte_eal/{linuxapp => osvapp}/eal/eal.c  | 123 +---
 .../{linuxapp => osvapp}/eal/eal_alarm.c   |   0
 .../{linuxapp => osvapp}/eal/eal_debug.c   |   0
 lib/librte_eal/osvapp/eal/eal_hugepage_info.cc |  63 +
 .../{bsdapp => osvapp}/eal/eal_interrupts.c|   0
 .../eal/eal_lcore.c => osvapp/eal/eal_lcore.cc}|  53 ++--
 lib/librte_eal/{bsdapp => osvapp}/eal/eal_log.c|   0
 lib/librte_eal/osvapp/eal/eal_memory.cc| 148 ++
 lib/librte_eal/osvapp/eal/eal_pci.cc   | 311 +
 .../{linuxapp => osvapp}/eal/eal_thread.c  |   0
 lib/librte_eal/osvapp/eal/eal_timer.c  | 121 
 .../eal/include/exec-env/rte_interrupts.h  |   0
 mk/exec-env/{linuxapp => osvapp}/rte.app.mk|   0
 mk/exec-env/{linuxapp => osvapp}/rte.vars.mk   |   6 +-
 19 files changed, 805 insertions(+), 164 deletions(-)
 copy config/{common_linuxapp => common_osvapp} (97%)
 copy config/{defconfig_x86_64-native-linuxapp-gcc => 
defconfig_x86_64-native-osvapp-gcc} (98%)
 copy Makefile => lib/librte_eal/osvapp/Makefile (93%)
 create mode 100644 lib/librte_eal/osvapp/eal/Makefile
 copy lib/librte_eal/{linuxapp => osvapp}/eal/eal.c (87%)
 copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_alarm.c (100%)
 copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_debug.c (100%)
 create mode 100644 lib/librte_eal/osvapp/eal/eal_hugepage_info.cc
 copy lib/librte_eal/{bsdapp => osvapp}/eal/eal_interrupts.c (100%)
 copy lib/librte_eal/{bsdapp/eal/eal_lcore.c => osvapp/eal/eal_lcore.cc} (80%)
 copy lib/librte_eal/{bsdapp => osvapp}/eal/eal_log.c (100%)
 create mode 100644 lib/librte_eal/osvapp/eal/eal_memory.cc
 create mode 100644 lib/librte_eal/osvapp/eal/eal_pci.cc
 copy lib/librte_eal/{linuxapp => osvapp}/eal/eal_thread.c (100%)
 create mode 100644 lib/librte_eal/osvapp/eal/eal_timer.c
 copy lib/librte_eal/{bsdapp => osvapp}/eal/include/exec-env/rte_interrupts.h 
(100%)
 copy mk/exec-env/{linuxapp => osvapp}/rte.app.mk (100%)
 copy mk/exec-env/{linuxapp => osvapp}/rte.vars.mk (95%)

diff --git a/config/common_linuxapp b/config/common_osvapp
similarity index 97%
copy from config/common_linuxapp
copy to config/common_osvapp
index 97f1c9e..ce973fe 100644
--- a/config/common_linuxapp
+++ b/config/common_osvapp
@@ -35,8 +35,8 @@
 #
 # CONFIG_RTE_EXEC_ENV can be linuxapp, bsdapp
 #
-CONFIG_RTE_EXEC_ENV="linuxapp"
-CONFIG_RTE_EXEC_ENV_LINUXAPP=y
+CONFIG_RTE_EXEC_ENV="osvapp"
+CONFIG_RTE_EXEC_ENV_OSVAPP=y

 ##
 ## machine can define specific variables or action for a specific board
@@ -89,7 +89,7 @@ CONFIG_RTE_LIBNAME="intel_dpdk"
 #
 CONFIG_RTE_LIBRTE_EAL=y
 CONFIG_RTE_MAX_LCORE=128
-CONFIG_RTE_MAX_NUMA_NODES=8
+CONFIG_RTE_MAX_NUMA_NODES=1
 CONFIG_RTE_MAX_MEMSEG=256
 CONFIG_RTE_MAX_MEMZONE=2560
 CONFIG_RTE_MAX_TAILQ=32
@@ -98,8 +98,8 @@ CONFIG_RTE_LOG_HISTORY=256
 CONFIG_RTE_LIBEAL_USE_HPET=n
 CONFIG_RTE_EAL_ALLOW_INV_SOCKET_ID=n
 CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
-CONFIG_RTE_EAL_IGB_UIO=y
-CONFIG_RTE_EAL_VFIO=y
+CONFIG_RTE_EAL_IGB_UIO=n
+CONFIG_RTE_EAL_VFIO=n

 #
 # Special configurations in PCI Config Space for high performance
@@ -111,7 +111,13 @@ CONFIG_RTE_PCI_MAX_READ_REQUEST_SIZE=0
 #
 # Compile Environment Abstraction Layer for linux
 #
-CONFIG_RTE_LIBRTE_EAL_LINUXAPP=y
+CONFIG_RTE_LIBRTE_EAL_OSVAPP=y
+
+#
+# Compile OSv specific parameters
+#
+CONFIG_RTE_CONTIGUOUS_CHUNK_SIZE=32M
+CONFIG_RTE_DEFAULT_NUM_CHUNKS=4

 #
 # Compile Environment Abstraction Layer to support hotplug
@@ -403,7 +409,7 @@ CONFIG_RTE_LIBRTE_PIPELINE=y
 #
 # Compile librte_kni
 #
-CONFIG_RTE_LIBRTE_KNI=y
+CONFIG_RTE_LIBRTE_KNI=n
 CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
 CONFIG_RTE_KNI_KO_DEBUG=n
 CONFIG_RTE_KNI_VHOST=n
diff --git a/config/defconfig_x86_64-native-linuxapp-gcc 
b/config/defconfig_x86_64-native-osvapp-gcc
similarity index 98%
copy from config/defconfig_x86_64-native-linuxapp-gcc
copy to config/defconfig_x86_64-native-osvapp-gcc
index 60baf5b..2134270 100644
--- a/config/defconfig_x86_64-native-linuxapp-gcc
+++ b/config/defconfig_x86_64-native-osvapp-gcc
@@ -30,7 +30,7 @@
 #   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #

-#include "common_linuxapp"
+#include "common_osvapp"

 CONFIG_RTE_MACHINE="native"

diff --git a/lib/librte_eal/Makefile b/lib/librte_eal/Makefile
index 69003cf..c87 100644
--- a/lib/librte_eal/Makefile
+++ b/lib/librte_eal/Makefile
@@ -35,5 +35,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += common
 

[dpdk-dev] [RFC PATCH 4/7] eal: Add extern C on eal_private.h

[Takuya ASADA]

This is required to link with OSv EAL.

Signed-off-by: Takuya ASADA 
---
 lib/librte_eal/common/eal_private.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/lib/librte_eal/common/eal_private.h 
b/lib/librte_eal/common/eal_private.h
index 4acf5a0..80b3d44 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -34,6 +34,10 @@
 #ifndef _EAL_PRIVATE_H_
 #define _EAL_PRIVATE_H_

+#ifdef __cplusplus
+extern "C" {
+#endif
+
 #include 

 /**
@@ -232,4 +236,8 @@ int rte_eal_dev_init(void);
  */
 int rte_eal_check_module(const char *module_name);

+#ifdef __cplusplus
+}
+#endif
+
 #endif /* _EAL_PRIVATE_H_ */
-- 
2.1.0

[dpdk-dev] [RFC PATCH 3/7] eal: Add extern C on eal_thread.h

[Takuya ASADA]

This is required to link with OSv EAL.

Signed-off-by: Takuya ASADA 
---
 lib/librte_eal/common/eal_thread.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/lib/librte_eal/common/eal_thread.h 
b/lib/librte_eal/common/eal_thread.h
index e4e76b9..794137f 100644
--- a/lib/librte_eal/common/eal_thread.h
+++ b/lib/librte_eal/common/eal_thread.h
@@ -34,6 +34,10 @@
 #ifndef EAL_THREAD_H
 #define EAL_THREAD_H

+#ifdef __cplusplus
+extern "C" {
+#endif
+
 #include 

 /**
@@ -97,4 +101,8 @@ int eal_cpuset_socket_id(rte_cpuset_t *cpusetp);
 int
 eal_thread_dump_affinity(char *str, unsigned size);

+#ifdef __cplusplus
+}
+#endif
+
 #endif /* EAL_THREAD_H */
-- 
2.1.0

[dpdk-dev] [RFC PATCH 2/7] eal: Add extern C on eal_hugepages.h

[Takuya ASADA]

This is required to link with OSv EAL.

Signed-off-by: Takuya ASADA 
---
 lib/librte_eal/common/eal_hugepages.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/lib/librte_eal/common/eal_hugepages.h 
b/lib/librte_eal/common/eal_hugepages.h
index 38edac0..b722aee 100644
--- a/lib/librte_eal/common/eal_hugepages.h
+++ b/lib/librte_eal/common/eal_hugepages.h
@@ -34,6 +34,10 @@
 #ifndef EAL_HUGEPAGES_H
 #define EAL_HUGEPAGES_H

+#ifdef __cplusplus
+extern "C" {
+#endif
+
 #include 
 #include 
 #include 
@@ -64,4 +68,8 @@ struct hugepage_file {
  */
 int eal_hugepage_info_init(void);

+#ifdef __cplusplus
+}
+#endif
+
 #endif /* EAL_HUGEPAGES_H */
-- 
2.1.0

[dpdk-dev] [RFC PATCH 1/7] mk: support compiling C++ code

[Takuya ASADA]

Since OSv is written in C++, we need to write OSv EAL in C++.
To do so, we need to compile .cc files by $(CXX).

This patch does not contain diff for clang and icc, but OSv EAL does not 
supported these toolchain, this is enough for now.

Signed-off-by: Takuya ASADA 
---
 mk/internal/rte.compile-pre.mk | 41 ++---
 mk/target/generic/rte.vars.mk  |  4 
 mk/toolchain/gcc/rte.vars.mk   |  5 -
 3 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/mk/internal/rte.compile-pre.mk b/mk/internal/rte.compile-pre.mk
index b9bff4a..142f996 100644
--- a/mk/internal/rte.compile-pre.mk
+++ b/mk/internal/rte.compile-pre.mk
@@ -37,7 +37,7 @@ SRCS-all := $(SRCS-y) $(SRCS-n) $(SRCS-)

 # convert source to obj file
 src2obj = $(strip $(patsubst %.c,%.o,\
-   $(patsubst %.S,%_s.o,$(1
+   $(patsubst %.S,%_s.o,$(patsubst %.cc,%.o,$(1)

 # add a dot in front of the file name
 dotfile = $(strip $(foreach f,$(1),\
@@ -46,12 +46,12 @@ dotfile = $(strip $(foreach f,$(1),\
 # convert source/obj files into dot-dep filename (does not
 # include .S files)
 src2dep = $(strip $(call dotfile,$(patsubst %.c,%.o.d, \
-   $(patsubst %.S,,$(1)
+   $(patsubst %.S,,$(patsubst %.cc,%.o.d,$(1))
 obj2dep = $(strip $(call dotfile,$(patsubst %.o,%.o.d,$(1

 # convert source/obj files into dot-cmd filename
 src2cmd = $(strip $(call dotfile,$(patsubst %.c,%.o.cmd, \
-   $(patsubst %.S,%_s.o.cmd,$(1)
+   $(patsubst %.S,%_s.o.cmd,$(patsubst %.cc,%.o.cmd,$(1))
 obj2cmd = $(strip $(call dotfile,$(patsubst %.o,%.o.cmd,$(1

 OBJS-y := $(call src2obj,$(SRCS-y))
@@ -78,11 +78,19 @@ C_TO_O = $(HOSTCC) -Wp,-MD,$(call obj2dep,$(@)).tmp 
$(HOST_CFLAGS) \
$(CFLAGS_$(@)) $(HOST_EXTRA_CFLAGS) -o $@ -c $<
 C_TO_O_STR = $(subst ','\'',$(C_TO_O)) #'# fix syntax highlight
 C_TO_O_DISP = $(if $(V),"$(C_TO_O_STR)","  HOSTCC $(@)")
+CXX_TO_O = $(HOSTCXX) -Wp,-MD,$(call obj2dep,$(@)).tmp $(HOST_CXXFLAGS) \
+   $(CXXFLAGS_$(@)) $(HOST_EXTRA_CXXFLAGS) -o $@ -c $<
+CXX_TO_O_STR = $(subst ','\'',$(CXX_TO_O)) #'# fix syntax highlight
+CXX_TO_O_DISP = $(if $(V),"$(CXX_TO_O_STR)","  HOSTCXX $(@)")
 else
 C_TO_O = $(CC) -Wp,-MD,$(call obj2dep,$(@)).tmp $(CFLAGS) \
$(CFLAGS_$(@)) $(EXTRA_CFLAGS) -o $@ -c $<
 C_TO_O_STR = $(subst ','\'',$(C_TO_O)) #'# fix syntax highlight
 C_TO_O_DISP = $(if $(V),"$(C_TO_O_STR)","  CC $(@)")
+CXX_TO_O = $(CXX) -Wp,-MD,$(call obj2dep,$(@)).tmp $(CXXFLAGS) \
+   $(CXXFLAGS_$(@)) $(EXTRA_CXXFLAGS) -o $@ -c $<
+CXX_TO_O_STR = $(subst ','\'',$(CXX_TO_O)) #'# fix syntax highlight
+CXX_TO_O_DISP = $(if $(V),"$(CXX_TO_O_STR)","  CXX $(@)")
 endif
 C_TO_O_CMD = 'cmd_$@ = $(C_TO_O_STR)'
 C_TO_O_DO = @set -e; \
@@ -91,6 +99,13 @@ C_TO_O_DO = @set -e; \
echo $(C_TO_O_CMD) > $(call obj2cmd,$(@)) && \
sed 's,'$@':,dep_'$@' =,' $(call obj2dep,$(@)).tmp > $(call 
obj2dep,$(@)) && \
rm -f $(call obj2dep,$(@)).tmp
+CXX_TO_O_CMD = 'cmd_$@ = $(CXX_TO_O_STR)'
+CXX_TO_O_DO = @set -e; \
+   echo $(CXX_TO_O_DISP); \
+   $(CXX_TO_O) && \
+   echo $(CXX_TO_O_CMD) > $(call obj2cmd,$(@)) && \
+   sed 's,'$@':,dep_'$@' =,' $(call obj2dep,$(@)).tmp > $(call 
obj2dep,$(@)) && \
+   rm -f $(call obj2dep,$(@)).tmp

 # return an empty string if string are equal
 compare = $(strip $(subst $(1),,$(2)) $(subst $(2),,$(1)))
@@ -136,6 +151,26 @@ boolean = $(if $1,1,0)
$(depfile_missing),\
$(depfile_newer)),\
$(C_TO_O_DO))
+#
+# Compile .cc file if needed
+# Note: dep_$$@ is from the .d file and DEP_$$@ can be specified by
+# user (by default it is empty)
+#
+.SECONDEXPANSION:
+%.o: %.cc $$(wildcard $$(dep_$$@)) $$(DEP_$$(@)) FORCE
+   @[ -d $(dir $@) ] || mkdir -p $(dir $@)
+   $(if $(D),\
+   @echo -n "$< -> $@ " ; \
+   echo -n "file_missing=$(call boolean,$(file_missing)) " ; \
+   echo -n "cmdline_changed=$(call boolean,$(call 
cmdline_changed,$(CXX_TO_O))) " ; \
+   echo -n "depfile_missing=$(call boolean,$(depfile_missing)) " ; 
\
+   echo "depfile_newer=$(call boolean,$(depfile_newer))")
+   $(if $(or \
+   $(file_missing),\
+   $(call cmdline_changed,$(CXX_TO_O)),\
+   $(depfile_missing),\
+   $(depfile_newer)),\
+   $(CXX_TO_O_DO))

 # command to assemble a .S file to generate an object
 ifeq ($(USE_HOST),1)
diff --git a/mk/target/generic/rte.vars.mk b/mk/target/generic/rte.vars.mk
index 53650c3..47d845b 100644
--- a/mk/target/generic/rte.vars.mk
+++ b/mk/target/generic/rte.vars.mk
@@ -146,7 +146,11 @@ endif
 LDFLAGS += -L$(RTE_SDK_BIN)/lib
 endif

+# copy CFLAGS to CXXFLAGS
+CXXFLAGS := $(CFLAGS)
+
 export CFLAGS
 export LDFLAGS
+export CXXFLAGS

 endif
diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk
index 88f235c..4bdf2eb 100644
--- a/mk/toolchain/gcc/rte.vars.mk
+++ 

[dpdk-dev] PMD architecture related to code

[kuldeep.sam...@wipro.com]

Hi Developer Team ,


I am trying add new functionality on Poll Mode driver .
But I don't have idea how packets are coming to kernel mode and going to user 
space and doing packet processing DPDK .

I need suggestion on which file the PMD architecture defined .



Regards ,
Kuldeep
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com

[dpdk-dev] [PATCH] lib/librte_vhost: add CONFIG_RTE_LIBRTE_VHOST_USER switch

[Ouyang, Changchun]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie
> Sent: Thursday, March 12, 2015 11:30 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] lib/librte_vhost: add
> CONFIG_RTE_LIBRTE_VHOST_USER switch
> 
> Turn on CONFIG_RTE_LIBRTE_VHOST to enable vhost.
> vhost-user is turned on by default. Turn off
> CONFIG_RTE_LIBRTE_VHOST_USER to enable vhost-cuse implementation.
> 
> Signed-off-by: Huawei Xie 

Acked-by: Changchun Ouyang 

[dpdk-dev] Appropriate DPDK data structures for TCP sockets

[Matthew Hall]

On Mon, Feb 23, 2015 at 11:51:46PM +0200, Avi Kivity wrote:
> https://github.com/cloudius-systems/seastar

Hi Avi and others,

My code unintentionally ended up looking somewhat like a C version of your 
seastar C++ code, even though I didn't really look at yours too much when I 
coded mine as it was using a lot of hardcore C++ features I really don't have 
any clue about. :)

Someday maybe we can all do a bake-off of tests of DPDK TCPs and Host TCPs and 
see what kind of stability, features, and performance we can get.

I didn't use anything too crazy or high performance just yet... just rte_hash 
and some spinlocks... but I'm keeping all the collective advice in mind to 
figure out how I'm going to make all this stuff work right soon.

Matthew.

[dpdk-dev] [PATCH] lib/librte_vhost: add CONFIG_RTE_LIBRTE_VHOST_USER switch

[Huawei Xie]

Turn on CONFIG_RTE_LIBRTE_VHOST to enable vhost.
vhost-user is turned on by default. Turn off CONFIG_RTE_LIBRTE_VHOST_USER to
enable vhost-cuse implementation.

Signed-off-by: Huawei Xie 
---
 config/common_linuxapp|  4 +++-
 lib/librte_vhost/Makefile | 11 +--
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/config/common_linuxapp b/config/common_linuxapp
index 97f1c9e..09a58ac 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -414,10 +414,12 @@ CONFIG_RTE_KNI_VHOST_DEBUG_TX=n

 #
 # Compile vhost library
-# fuse-devel is needed to run vhost.
+# fuse-devel is needed to run vhost-cuse.
 # fuse-devel enables user space char driver development
+# vhost-user is turned on by default.
 #
 CONFIG_RTE_LIBRTE_VHOST=n
+CONFIG_RTE_LIBRTE_VHOST_USER=y
 CONFIG_RTE_LIBRTE_VHOST_DEBUG=n

 #
diff --git a/lib/librte_vhost/Makefile b/lib/librte_vhost/Makefile
index 52f6575..a8645a6 100644
--- a/lib/librte_vhost/Makefile
+++ b/lib/librte_vhost/Makefile
@@ -39,13 +39,20 @@ EXPORT_MAP := rte_vhost_version.map
 LIBABIVER := 1

 CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -D_FILE_OFFSET_BITS=64
-CFLAGS += -I vhost_cuse -lfuse
+ifeq ($(CONFIG_RTE_LIBRTE_VHOST_USER),y)
 CFLAGS += -I vhost_user
+else
+CFLAGS += -I vhost_cuse -lfuse
 LDFLAGS += -lfuse
+endif
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_VHOST) := virtio-net.c vhost_rxtx.c
-#SRCS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost_cuse/vhost-net-cdev.c 
vhost_cuse/virtio-net-cdev.c vhost_cuse/eventfd_copy.c
+ifeq ($(CONFIG_RTE_LIBRTE_VHOST_USER),y)
 SRCS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost_user/vhost-net-user.c 
vhost_user/virtio-net-user.c vhost_user/fd_man.c
+else
+SRCS-$(CONFIG_RTE_LIBRTE_VHOST) += vhost_cuse/vhost-net-cdev.c 
vhost_cuse/virtio-net-cdev.c vhost_cuse/eventfd_copy.c
+endif

 # install includes
 SYMLINK-$(CONFIG_RTE_LIBRTE_VHOST)-include += rte_virtio_net.h
-- 
1.8.1.4

[dpdk-dev] [PATCH] ethdev: additional parameter in RX callback

[Mcnamara, John]

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Thursday, March 12, 2015 7:16 PM
> To: Mcnamara, John
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] ethdev: additional parameter in RX
> callback
> 
> 
> Well, we're well past the new feature phase of this cycle, so I would say
> NACK.

Hi Neil,

This is more of a bug fix than a feature request.

In retrospect it was a mistake not to have the same function declaration in the 
callbacks as in the rte_eth_XX_burst functions since it was likely that the 
callbacks would need access to the same information.

This patch is trying to fix that error before it is set in stone.

John

[dpdk-dev] [PATCH v3 3/3] ixgbe: Unify the rx_pkt_bulk callback initialization

[Vlad Zolotarov]

   - Set the callback in a single function that is called from
 ixgbe_dev_rx_init() for a primary process and from eth_ixgbe_dev_init()
 for a secondary processes. This is instead of multiple, hard to track 
places.
   - Added ixgbe_hw.rx_bulk_alloc_allowed - see ixgbe_hw.rx_vec_allowed 
description below.
   - Added ixgbe_hw.rx_vec_allowed: like with Bulk Allocation, Vector Rx is
 enabled or disabled on a per-port level. All queues have to meet the 
appropriate
 preconditions and if any of them doesn't - the feature has to be disabled.
 Therefore ixgbe_hw.rx_vec_allowed will be updated during each queues 
configuration
 (rte_eth_rx_queue_setup()) and then used in rte_eth_dev_start() to 
configure the
 appropriate callbacks. The same happens with ixgbe_hw.rx_vec_allowed in a 
Bulk Allocation
 context.
   - Bugs fixed:
  - Vector scattered packets callback was called regardless the appropriate
preconditions:
 - Vector Rx specific preconditions.
 - Bulk Allocation preconditions.
  - Vector Rx was enabled/disabled according to the last queue setting and 
not
based on all queues setting (which may be different for each queue).

Signed-off-by: Vlad Zolotarov 
---
New in v3:
   - Adjusted to the new structs naming in the master.
   - Fixed rx_bulk_alloc_allowed and rx_vec_allowed initialization:
  - Don't set them to FALSE in rte_eth_dev_stop() flow - the following
rte_eth_dev_start() will need them.
  - Reset them to TRUE in rte_eth_dev_configure() and not in a probe() flow.
This will ensure the proper behaviour if port is re-configured.
   - Rename:
  - ixgbe_rx_vec_condition_check() -> 
ixgbe_rx_vec_dev_conf_condition_check()
  - set_rx_function() -> ixgbe_set_rx_function()
   - Clean up the logic in ixgbe_set_rx_function().
   - Define stubs with __attribute__((weak)) instead of using #ifdef's.
   - Styling: beautify ixgbe_rxtx.h a bit.

New in v2:
   - Fixed an artifact caused by git rebasing that broke the compilation.
---
 lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h |   2 +
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c |  13 ++-
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c   | 200 ++--
 lib/librte_pmd_ixgbe/ixgbe_rxtx.h   |  28 -
 lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c   |   2 +-
 5 files changed, 174 insertions(+), 71 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h 
b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h
index c67d462..9a66370 100644
--- a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h
+++ b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h
@@ -3657,6 +3657,8 @@ struct ixgbe_hw {
bool force_full_reset;
bool allow_unsupported_sfp;
bool wol_enabled;
+   bool rx_bulk_alloc_allowed;
+   bool rx_vec_allowed;
 };

 #define ixgbe_call_func(hw, func, params, error) \
diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c 
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
index e4edb01..92d75db 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
@@ -756,8 +756,8 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
   "Using default TX function.");
}

-   if (eth_dev->data->scattered_rx)
-   eth_dev->rx_pkt_burst = ixgbe_recv_scattered_pkts;
+   ixgbe_set_rx_function(eth_dev);
+
return 0;
}
pci_dev = eth_dev->pci_dev;
@@ -1429,12 +1429,21 @@ ixgbe_dev_configure(struct rte_eth_dev *dev)
 {
struct ixgbe_interrupt *intr =
IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
+   struct ixgbe_hw *hw =
+   IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);

PMD_INIT_FUNC_TRACE();

/* set flag to update link status after init */
intr->flags |= IXGBE_FLAG_NEED_LINK_UPDATE;

+   /*
+* Initialize to TRUE. If any of Rx queues doesn't meet the bulk
+* allocation or vector Rx preconditions we will reset it.
+*/
+   hw->rx_bulk_alloc_allowed = true;
+   hw->rx_vec_allowed = true;
+
return 0;
 }

diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index 92be61e..5b1ba82 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -2075,12 +2075,12 @@ check_rx_burst_bulk_alloc_preconditions(__rte_unused 
struct ixgbe_rx_queue *rxq)

 /* Reset dynamic ixgbe_rx_queue fields back to defaults */
 static void
-ixgbe_reset_rx_queue(struct ixgbe_rx_queue *rxq)
+ixgbe_reset_rx_queue(struct ixgbe_hw *hw, struct ixgbe_rx_queue *rxq)
 {
static const union ixgbe_adv_rx_desc zeroed_desc = { .read = {
.pkt_addr = 0}};
unsigned i;
-   uint16_t len;
+   uint16_t len = rxq->nb_rx_desc;

/*
 * By default, the Rx queue setup function allocates enough memory for
@@ -2092,14 +2092,9 @@ ixgbe_reset_rx_queue(struct 

[dpdk-dev] [PATCH v3 2/3] ixgbe: Bug fix: Properly configure Rx CRC stripping for x540 devices

[Vlad Zolotarov]

According to x540 spec chapter 8.2.4.8.9 CRCSTRIP field of RDRXCTL should
be configured to the same value as HLREG0.RXCRCSTRP.

Clearing the RDRXCTL.RSCFRSTSIZE field for x540 is not required by the spec
but seems harmless.

Signed-off-by: Vlad Zolotarov 
---
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index f7c081f..92be61e 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -3680,7 +3680,8 @@ ixgbe_dev_rx_init(struct rte_eth_dev *dev)

IXGBE_WRITE_REG(hw, IXGBE_RXCSUM, rxcsum);

-   if (hw->mac.type == ixgbe_mac_82599EB) {
+   if (hw->mac.type == ixgbe_mac_82599EB ||
+   hw->mac.type == ixgbe_mac_X540) {
rdrxctl = IXGBE_READ_REG(hw, IXGBE_RDRXCTL);
if (dev->data->dev_conf.rxmode.hw_strip_crc)
rdrxctl |= IXGBE_RDRXCTL_CRCSTRIP;
-- 
2.1.0

[dpdk-dev] [PATCH v3 0/3]: bug fixes in the ixgbe PF PMD Rx flow

[Vlad Zolotarov]

This series contains some bug fixes that were found during my work on the ixgbe 
LRO
patches. Sending this series separately on Thomas request so that it may be 
integrated
into the 2.0 release.

New in v3:
   - Adjusted to the new structs naming in the master.
   - Fixed rx_bulk_alloc_allowed and rx_vec_allowed initialization:
  - Don't set them to FALSE in rte_eth_dev_stop() flow - the following
rte_eth_dev_start() will need them.
  - Reset them to TRUE in rte_eth_dev_configure() and not in a probe() flow.
This will ensure the proper behaviour if port is re-configured.
   - Rename:
  - ixgbe_rx_vec_condition_check() -> 
ixgbe_rx_vec_dev_conf_condition_check()
  - set_rx_function() -> ixgbe_set_rx_function()
   - Clean up the logic in ixgbe_set_rx_function().
   - Define stubs with __attribute__((weak)) instead of using #ifdef's.
   - Styling: beautify ixgbe_rxtx.h a bit.

New in v2:
   - Fixed a compilation failure.


Vlad Zolotarov (3):
  ixgbe: Use the rte_le_to_cpu_xx()/rte_cpu_to_le_xx() when
reading/setting HW ring descriptor fields
  ixgbe: Bug fix: Properly configure Rx CRC stripping for x540 devices
  ixgbe: Unify the rx_pkt_bulk callback initialization

 lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h |   2 +
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c |  13 +-
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c   | 216 +---
 lib/librte_pmd_ixgbe/ixgbe_rxtx.h   |  28 -
 lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c   |   2 +-
 5 files changed, 183 insertions(+), 78 deletions(-)

-- 
2.1.0