[dpdk-dev] [PATCH] kni: Use utsrelease.h to determine Ubuntu kernel version

[Thomas Monjalon]

2015-05-27 13:45, Simon Kagstrom:
> /proc/version_signature is the version for the host machine, but in
> e.g., chroots, this does not need to match that DPDK is built for. Use
> utsrelease.h from the kernel sources instead and fake the upload
> version.

Sorry, I don't really understand the problem.
Do you mean that /proc/version_signature is not readable from the chroot?
Or do you mean that the /proc in the chroot is the host one and it
doesn't match the OS installed in the chroot?

Please precise which case you try to solve and which tests you did
with which Ubuntu versions?

[dpdk-dev] Debugging SR-IOV related packet flow problem with DPDK

[Thomas Monjalon]

Hi,

That's third email in 8 hours for this question.
Do you plan to send an email every 4 hours?

It's really hard to help you without knowing which application you run?
in which VM? which VLAN configuration? etc

2015-06-16 20:22, Anjali Kulkarni:
> Hi,
> 
> Can someone please help with this? How can packet flow be traced on DPDK?
> Where are all the logs stored if we do enable the _DEBUG configs in
> config/ directory?

stdout or somewhere else if you configured logs in your app.

> Anjali
[...]
> I am observing that the SR-IOV enabled NIC does not increment any VF packet
> counters despite incoming packet flow. I have enabled some debug logs like
> CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX in config file.
> Can someone point me to where these logs are being printed so I can try to
> figure out where packets are being dropped? Or how can I debug DPDK packet
> flow related issues (are there any stats I can look at)?

Statistics can be requested through a dedicated ethdev API.

[dpdk-dev] [dpdk-announce] important design choices - statistics - ABI

[Stephen Hemminger]

On Tue, Jun 16, 2015 at 9:36 PM, Matthew Hall  wrote:

> On Wed, Jun 17, 2015 at 01:29:47AM +0200, Thomas Monjalon wrote:
> > There were some debates about software statistics disabling.
> > Should they be always on or possibly disabled when compiled?
> > We need to take a decision shortly and discuss (or agree) this proposal:
> >   http://dpdk.org/ml/archives/dev/2015-June/019461.html
>
> This goes against the idea I have seen before that we should be moving
> toward
> a distro-friendly approach where one copy of DPDK can be used by multiple
> apps
> without having to rebuild it. It seems like it is also a bit ABI hostile
> according to the below goals / discussions.
>
> Jemalloc is also very high-performance code and still manages to allow
> enabling and disabling statistics at runtime. Are we sure it's impossible
> for
> DPDK or just theorizing?
>
> > During the development of the release 2.0, there was an agreement to keep
> > ABI compatibility or to bring new ABI while keeping old one during one
> release.
> > In case it's not possible to have this transition, the (exceptional)
> break
> > should be acknowledged by several developers.
>
> Personally to me it seems more important to preserve the ABI on patch
> releases, like 2.X.Y going to 2.X.Z. But maybe I missed something?
>
> > During the current development cycle for the release 2.1, the ABI
> question
> > arises many times in different threads.
>
> Most but not all of these examples point to a different issue which
> sometimes
> happens in libraries... often seen as "old-style" versus "new-style" C
> library
> interface. For example, in old-style like libpcap there are a lot of
> structs,
> both opaque and non-opaque, which the caller must allocate in order to run
> libpcap.
>
> However new-style libraries such as libcurl usually just have init
> functions
> which initialize all the secret structs based on some defaults and some
> user
> parameters and hide the actual structs from the user. If you want to adjust
> some you call an adjuster function that modifies the actual secret struct
> contents, with some enum saying what field to adjust, and the new value you
> want it to have.
>
> If you want to keep a stable ABI for a non-stable library like DPDK,
> there's a
> good chance you must begin hiding all these weird device specific structs
> all
> over the DPDK from the user needing to directly allocate and modify them.
> Otherwise the ABI breaks everytime you have to add adjustments, extensions,
> modifications to all these obscure special features.
>
> Matthew.
>

The DPDK makes extensive use of inline functions which prevents data hiding
necessary for ABI stablility. This a fundamental tradeoff, and since the
whole
reason for DPDK is performance; the ABI is going to be a moving target.

It would make more sense to provide a higher level API which was abstracted,
slower, but stable for applications. But in doing so it would mean giving
up things
like inline lockless rings. Just don't go as far as the Open (not)
dataplane API;
which is just an excuse for closed source.

[dpdk-dev] [PATCH v2] Add toeplitz hash algorithm used by RSS

[Vladimir Medvedkin]

Hi Bruce,

2015-06-16 15:29 GMT+03:00 Bruce Richardson :

> On Fri, May 08, 2015 at 10:58:12AM -0400, Vladimir Medvedkin wrote:
> > Software implementation of the Toeplitz hash function used by RSS.
> > Can be used either for packet distribution on single queue NIC
> > or for simulating of RSS computation on specific NIC (for example
> > after GRE header decapsulating).
> >
> > v3 changes
> > - Rework API to be more generic
> > - Add sctp_tag into tuple
> >
> > v2 changes
> > - Add ipv6 support
> > - Various style fixes
> >
> > Signed-off-by: Vladimir Medvedkin 
>
> Hi Vladimir,
>
> first off, thanks for this patch, it looks like something we want into
> DPDK.
> However, as Thomas has already pointed out, I think we could really do with
> some unit tests for this code. As it stands right now, we don't even know
> if this
> header compiles, as the header file is not used by any C file in DPDK.
>
I'll try to make a unit test this week

>
> Some other comments are inline below.
>
> Regards,
> /Bruce
> > ---
> >  lib/librte_hash/Makefile|   1 +
> >  lib/librte_hash/rte_thash.h | 207
> 
> >  2 files changed, 208 insertions(+)
> >  create mode 100644 lib/librte_hash/rte_thash.h
> >
> > diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile
> > index 3696cb1..981230b 100644
> > --- a/lib/librte_hash/Makefile
> > +++ b/lib/librte_hash/Makefile
> > @@ -49,6 +49,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_HASH) += rte_fbk_hash.c
> >  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include := rte_hash.h
> >  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_hash_crc.h
> >  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_jhash.h
> > +SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_thash.h
> >  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_fbk_hash.h
> >
> >  # this lib needs eal
> > diff --git a/lib/librte_hash/rte_thash.h b/lib/librte_hash/rte_thash.h
> > new file mode 100644
> > index 000..5d5111b
> > --- /dev/null
> > +++ b/lib/librte_hash/rte_thash.h
> > @@ -0,0 +1,207 @@
> > +/*-
> > + *   BSD LICENSE
> > + *
> > + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
>
> Date and copyright owner look to need update here.
>
> > + *   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.
> > + * * Neither the name of Intel Corporation nor the names of its
> > + *   contributors may be used to endorse or promote products derived
> > + *   from this software without specific prior written permission.
> > + *
> > + *   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.
> > + */
> > +
> > +#ifndef _RTE_THASH_H
> > +#define _RTE_THASH_H
> > +
> > +/**
> > + * @file
> > + *
> > + * toeplitz hash functions.
> > + */
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +/**
> > + * Software implementation of the Toeplitz hash function used by RSS.
> > + * Can be used either for packet distribution on single queue NIC
> > + * or for simulating of RSS computation on specific NIC (for example
> > + * after GRE header decapsulating)
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#ifdef __SSE3__
> > +static const __m128i bswap_mask = {0x0405060700010203,
> 0x0C0D0E0F08090A0B};
> > +#endif
>
> I think a more descriptive name for this might help. Yes, it's a mask for
> byteswapping, but I think the name could do with being more descriptive. I
> see
> below it's used for IPv6 IP extraction, so maybe that could be put in the
> name
> somehow. A comment should also be added on what it is used for.
> Finally, since this is a public symbol in the including C file, it sho

[dpdk-dev] DPDK-Pktgen

[Wiles, Keith]

On 6/16/15, 4:18 PM, "Assaad, Sami (Sami)"
 wrote:

>Hello.
>
>I am using DPDK-Pktgen (Pktgen version 2.77 using DPDK-1.7.1).
>My NIC consists of two 10G ports.

Please try to use the latest version from here
http://dpdk.org/browse/apps/pktgen-dpdk/refs/

The one you are using is fairly old now.
>Now, my question is : How are the port MBits/s Rx/Tx calculated?

You could look at the code to find the answer on exactly how it calculates
the bit rate.

>
>Example: I am running the traffic generator with the following
>configuration:
>
>* 400 Byte Packet Sizes
>
>* At Line Rate (i.e: 100%)
>
>* Unidirectional (Tx only)
>
>The Pkts/s TX is 2985600. (Looks correct)
>But the MBits/s Tx is set to 2006 (per port Tx).

INTER_FRAME_GAP = 12,
PKT_PREAMBLE_SIZE   = 8,
FCS_SIZE= 4,

#define Million (uint64_t)(1000ULL * 1000ULL)

#define iBitsTotal(_x) \
(((_x.ipackets * (INTER_FRAME_GAP + PKT_PREAMBLE_SIZE)) + _x.ibytes)
<< 3)
#define oBitsTotal(_x) \
(((_x.opackets * (INTER_FRAME_GAP + PKT_PREAMBLE_SIZE)) + _x.obytes)
<< 3)

snprintf(buff, sizeof(buff), "%lu/%lu",
   iBitsTotal(info->rate_stats)/Million,
oBitsTotal(info->rate_stats)/Million);
wr_scrn_printf(row++,  col, "%*s", COLUMN_WIDTH_1, buff);

I will let you do the math :-)

When I run the 2.9.1 code and DPDK 2.1 I get almost line rate for 400
bytes frames.
The values are calculated from the NIC counters. If the old is wrong then
update to the latest version is my only suggestion.

Regards,
++Keith



>
>How does DPDK-Pktgen calculate 2006 MBits/s Tx ?
>Is this a bug?
>
>Thanks in advance.
>
>Best Regards,
>Sami Assaad.
>

[dpdk-dev] [PATCH 0/6] Cuckoo hash

[De Lara Guarch, Pablo]

Hi Thomas,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, June 16, 2015 2:44 PM
> To: De Lara Guarch, Pablo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/6] Cuckoo hash
> 
> Hi Pablo,
> 
> 2015-06-05 15:33, Pablo de Lara:
> > Things left for v2:
> > - Improve unit tests to show clearer performance numbers
> > - Documentation changes
> 
> When do you plan to submit a v2?

I should have a v2 submitted by the end of this week.

Thanks for asking,
Pablo

[dpdk-dev] [dpdk-announce] important design choices - statistics - ABI

[Matthew Hall]

On Wed, Jun 17, 2015 at 01:29:47AM +0200, Thomas Monjalon wrote:
> There were some debates about software statistics disabling.
> Should they be always on or possibly disabled when compiled?
> We need to take a decision shortly and discuss (or agree) this proposal:
>   http://dpdk.org/ml/archives/dev/2015-June/019461.html

This goes against the idea I have seen before that we should be moving toward 
a distro-friendly approach where one copy of DPDK can be used by multiple apps 
without having to rebuild it. It seems like it is also a bit ABI hostile 
according to the below goals / discussions.

Jemalloc is also very high-performance code and still manages to allow 
enabling and disabling statistics at runtime. Are we sure it's impossible for 
DPDK or just theorizing?

> During the development of the release 2.0, there was an agreement to keep
> ABI compatibility or to bring new ABI while keeping old one during one 
> release.
> In case it's not possible to have this transition, the (exceptional) break
> should be acknowledged by several developers.

Personally to me it seems more important to preserve the ABI on patch 
releases, like 2.X.Y going to 2.X.Z. But maybe I missed something?

> During the current development cycle for the release 2.1, the ABI question
> arises many times in different threads.

Most but not all of these examples point to a different issue which sometimes 
happens in libraries... often seen as "old-style" versus "new-style" C library 
interface. For example, in old-style like libpcap there are a lot of structs, 
both opaque and non-opaque, which the caller must allocate in order to run 
libpcap. 

However new-style libraries such as libcurl usually just have init functions 
which initialize all the secret structs based on some defaults and some user 
parameters and hide the actual structs from the user. If you want to adjust 
some you call an adjuster function that modifies the actual secret struct 
contents, with some enum saying what field to adjust, and the new value you 
want it to have.

If you want to keep a stable ABI for a non-stable library like DPDK, there's a 
good chance you must begin hiding all these weird device specific structs all 
over the DPDK from the user needing to directly allocate and modify them. 
Otherwise the ABI breaks everytime you have to add adjustments, extensions, 
modifications to all these obscure special features.

Matthew.

[dpdk-dev] DPDK-Pktgen

[Assaad, Sami (Sami)]

Hello.

I am using DPDK-Pktgen (Pktgen version 2.77 using DPDK-1.7.1).
My NIC consists of two 10G ports.

Now, my question is : How are the port MBits/s Rx/Tx calculated?

Example: I am running the traffic generator with the following configuration:

* 400 Byte Packet Sizes

* At Line Rate (i.e: 100%)

* Unidirectional (Tx only)

The Pkts/s TX is 2985600. (Looks correct)
But the MBits/s Tx is set to 2006 (per port Tx).

How does DPDK-Pktgen calculate 2006 MBits/s Tx ?
Is this a bug?

Thanks in advance.

Best Regards,
Sami Assaad.

[dpdk-dev] Debugging SR-IOV related packet flow problem with DPDK

[Anjali Kulkarni]

Thanks for your response.
I am running my own application, and it is actually running inside a
docker, not a VM.
No VLAN configuration. Just SR-IOV is enabled on 2 NICs, and both devices
(/dev/uio0 and /dev/uio1) are assigned to the docker.
This worked a while ago perfectly.
What I see is that an ixia connected to the 2 10G NICs is pumping traffic,
but the VF statistics are 0. It is as if the VF or NIC did not see the
packets. 
The source dst MAC is set correctly to the VF?s MAC. I don?t see any
prints on stdout after enabling the _DEBUG logs in config.

Anjali

On 6/16/15, 1:52 PM, "Thomas Monjalon"  wrote:

>Hi,
>
>That's third email in 8 hours for this question.
>Do you plan to send an email every 4 hours?
>
>It's really hard to help you without knowing which application you run?
>in which VM? which VLAN configuration? etc
>
>2015-06-16 20:22, Anjali Kulkarni:
>> Hi,
>> 
>> Can someone please help with this? How can packet flow be traced on
>>DPDK?
>> Where are all the logs stored if we do enable the _DEBUG configs in
>> config/ directory?
>
>stdout or somewhere else if you configured logs in your app.
>
>> Anjali
>[...]
>> I am observing that the SR-IOV enabled NIC does not increment any VF
>>packet
>> counters despite incoming packet flow. I have enabled some debug logs
>>like
>> CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX in config file.
>> Can someone point me to where these logs are being printed so I can try
>>to
>> figure out where packets are being dropped? Or how can I debug DPDK
>>packet
>> flow related issues (are there any stats I can look at)?
>
>Statistics can be requested through a dedicated ethdev API.
>

[dpdk-dev] Debugging SR-IOV related packet flow problem with DPDK

[Anjali Kulkarni]

Hi,

Can someone please help with this? How can packet flow be traced on DPDK? Where 
are all the logs stored if we do enable the _DEBUG configs in config/ directory?

Anjali

From: Microsoft Office User mailto:sum...@juniper.net>>
Date: Tuesday, June 16, 2015 at 9:10 AM
To: "dev at dpdk.org" mailto:dev at 
dpdk.org>>, Microsoft Office User mailto:sumerj at 
juniper.net>>
Cc: Microsoft Office User mailto:sumerj at juniper.net>>
Subject: Re: Debugging SR-IOV related packet flow problem with DPDK

Pls keep me on cc for response. Thanks!!

Hi,

I am observing that the SR-IOV enabled NIC does not increment any VF packet 
counters despite incoming packet flow. I have enabled some debug logs like 
CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX in config file.
Can someone point me to where these logs are being printed so I can try to 
figure out where packets are being dropped? Or how can I debug DPDK packet flow 
related issues (are there any stats I can look at)?

Thanks
Anjali

[dpdk-dev] [PATCH] vfio: Fix overflow while assigning vfio BAR region offset and size

[Rahul Lakkireddy]

After the commit-id 90a1633b2 (eal/linux: allow to map BARs with MSI-X tables),
VFIO stopped working. On further debug, found that although BAR region
offset and size from vfio are read as u64, they are truncated when assigned to
uint32_t variables resulting in wrong offset being passed for mmap.

The fix is to use uint64_t for offset and size.

Signed-off-by: Rahul Lakkireddy 
Signed-off-by: Kumar Sanghvi 
---
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c 
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index 426953a..d0385ff 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -728,7 +728,7 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
struct vfio_region_info reg = { .argsz = sizeof(reg) };
void *bar_addr;
struct memreg {
-   uint32_t offset, size;
+   uint64_t offset, size;
} memreg[2] = {};

reg.index = i;
@@ -771,7 +771,7 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
RTE_LOG(DEBUG, EAL,
"Trying to map BAR %d that contains the 
MSI-X "
"table. Trying offsets: "
-   "%04x:%04x, %04x:%04x\n", i,
+   "%04lx:%04lx, %04lx:%04lx\n", i,
memreg[0].offset, memreg[0].size,
memreg[1].offset, memreg[1].size);
}
-- 
2.4.1

[dpdk-dev] [PATCH v4 1/4] ethdev: add apis to support access device info

[Ananyev, Konstantin]

> > > > > > > > > > +int
> > > > > > > > > > +rte_eth_dev_get_ringparam(uint8_t port_id, struct
> > > > > > > > > > +rte_dev_ring_info
> > > > > > > > > > +*info) {
> > > > > > > > > > +   struct rte_eth_dev *dev;
> > > > > > > > > > +
> > > > > > > > > > +   if (!rte_eth_dev_is_valid_port(port_id)) {
> > > > > > > > > > +   PMD_DEBUG_TRACE("Invalid port_id=%d\n",
> > > > > port_id);
> > > > > > > > > > +   return -ENODEV;
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > > +   if ((dev= &rte_eth_devices[port_id]) == NULL) {
> > > > > > > > > > +   PMD_DEBUG_TRACE("Invalid port device\n");
> > > > > > > > > > +   return -ENODEV;
> > > > > > > > > > +   }
> > > > > > > > > > +
> > > > > > > > > > +   FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_ringparam, -
> > > > > > > > > ENOTSUP);
> > > > > > > > > > +   return (*dev->dev_ops->get_ringparam)(dev, info); }
> > > > > > > > >
> > > > > > > > > I think it will be a useful addition to the ethdev API  to
> > > > > > > > > have an ability to retrieve current RX/TX queue parameters.
> > > > > > > > > Though again, it need to be more generic, so it could be
> > > > > > > > > useful for
> > > > > > > > > non- ethtool upper layer too.
> > > > > > > > > So I suggest to modify it a bit.
> > > > > > > > > Something like that:
> > > > > > > > >
> > > > > > > > > struct rte_eth_tx_queue_info {
> > > > > > > > > struct rte_eth_txconf txconf;
> > > > > > > > > uint32_t nb_tx_desc;
> > > > > > > > > uint32_t nb_max_tx_desc; /*max allowable TXDs for that
> > > queue */
> > > > > > > > > uint32_t nb_tx_free;/* number of free TXDs at
> > > the moment
> > > > > of
> > > > > > > call.
> > > > > > > > > */
> > > > > > > > > /* other tx queue data. */ };
> > > > > > > > >
> > > > > > > > > int rte_etdev_get_tx_queue_info(portid, queue_id, struct
> > > > > > > > > rte_eth_tx_queue_info *qinfo)
> > > > > > > > >
> > > > > > > > > Then, your upper layer ethtool wrapper, can implement yours
> > > > > > > > > ethtool_get_ringparam() by:
> > > > > > > > >
> > > > > > > > >  ...
> > > > > > > > >  struct rte_eth_tx_queue_info qinfo;
> > > > > > > > > rte_ethdev_get_tx_queue_info(port, 0, &qinfo);
> > > > > > > > > ring_param->tx_pending = qinfo.nb_tx_desc -
> > > > > > > > > rte_eth_rx_queue_count(port, 0);
> > > > > > > > >
> > > > > > > > > Or probably even:
> > > > > > > > > ring_param->tx_pending = qinfo.nb_tx_desc -
> > > > > > > > > qinfo.nb_tx_free;
> > > > > > > > >
> > > > > > > > > Same for RX.
> > > > > > > > >
> > > > > > > > For now, this descriptor ring information is used by the ethtool
> > > op.
> > > > > > > > To make this interface simple, i.e. caller doesn't need to
> > > > > > > > access other
> > > > > > > queue information.
> > > > > > >
> > > > > > > I just repeat what I said to you in off-line conversation:
> > > > > > > ethdev API is not equal ethtool API.
> > > > > > > It is ok to add  a new function/structure to ethdev if it really
> > > > > > > needed, but we should do mechanical one to one copy.
> > > > > > > It is much better to add  a function/structure that would be
> > > > > > > more generic, and suit other users, not only ethtool.
> > > > > > > There is no point to have dozen functions in rte_ethdev API
> > > > > > > providing similar information.
> > > > > > > BTW, I don't see how API I proposed is much more  complex, then
> > > > > > > yours
> > > > > one.
> > > > > > The ring parameter is a run-time information which is different
> > > > > > than data
> > > > > structure described in this discussion.
> > > > >
> > > > > I don't see how they are different.
> > > > > Looking at ixgbe_get_ringparam(), it returns:
> > > > > rx_max_pending - that's a static IXGBE PMD value (max possible
> > > > > number of RXDs per one queue).
> > > > > rx_pending - number of RXD currently in use by the HW for queue 0
> > > > > (that information can be changed at each call).
> > > > >
> > > > > With the approach I suggesting - you can get same information for
> > > > > each RX queue by calling rte_ethdev_get_rx_queue_info() and
> > > > > rte_eth_rx_queue_count().
> > > > > Plus you are getting other RX queue data.
> > > > >
> > > > > Another thing - what is practical usage of the information you
> > > > > retrieving now by get_ringparam()?
> > > > > Let say it returned to you: rx_max_pending=4096; rx_pending=128; How
> > > > > that information would help to understand what is going on with the
> > > device?
> > > > > Without knowing  value of nb_tx_desc for the queue, you can't say is
> > > > > you queue full or not.
> > > > > Again, it could be that all your traffic going through some other
> > > > > queue (not 0).
> > > > > So from my point rte_eth_dev_get_ringparam()  usage is very limited,
> > > > > and doesn't provide enough information about current queue state.
> > > > >
> > > > > Same thing applies for TX.
> > > > >
> > > >
> > > > After careful review the suggestion in this comment, and 

[dpdk-dev] [PATCH 1/3] pmd_ring: remove deprecated functions

[Stephen Hemminger]

On Tue, 16 Jun 2015 23:37:32 +
Thomas Monjalon  wrote:

> 2015-06-16 16:05, Stephen Hemminger:
> > On Tue, 16 Jun 2015 14:52:16 +0100
> > Bruce Richardson  wrote:
> > 
> > > On Mon, Jun 15, 2015 at 09:51:11AM -0700, Stephen Hemminger wrote:
> > > > From: Stephen Hemminger 
> > > > 
> > > > These were deprecated in 2.0 so remove them from 2.1
> > > > 
> > > > Signed-off-by: Stephen Hemminger 
> > > > ---
> > > >  drivers/net/ring/rte_eth_ring.c   | 55 
> > > > ---
> > > >  drivers/net/ring/rte_eth_ring_version.map |  4 +--
> > > >  2 files changed, 1 insertion(+), 58 deletions(-)
> > > >   
> > > [..snip..]
> > > > diff --git a/drivers/net/ring/rte_eth_ring_version.map 
> > > > b/drivers/net/ring/rte_eth_ring_version.map
> > > > index 8ad107d..5ee55d9 100644
> > > > --- a/drivers/net/ring/rte_eth_ring_version.map
> > > > +++ b/drivers/net/ring/rte_eth_ring_version.map
> > > > @@ -1,9 +1,7 @@
> > > > -DPDK_2.0 {
> > > > +DPDK_2.1 {
> > > > global:
> > > >  
> > > > rte_eth_from_rings;
> > > > -   rte_eth_ring_pair_attach;
> > > > -   rte_eth_ring_pair_create;
> > > >  
> > > > local: *;
> > > >  };  
> > > 
> > > [ABI newbie question] Is this how deprecating a fn is done? We no longer 
> > > have any DPDK_2.0 
> > > version listings in the .map file?
> > 
> > Notice the version # changed as well, so linker will generate a new version.
> > The function was marked deprecated in last version.
> 
> What happens if you load the 2.1 lib with an app built for 2.0?
> Shouldn't we keep the DPDK_2.0 block?

What happens is that build process makes a new version of DPDK package
with a new version number. This version can co-exist on same system with
old library (depends on library packaging).
Old library will have old functions, and old application will
use old library. New applications will be have new so version and get the
new library.

  
http://unix.stackexchange.com/questions/475/how-do-so-shared-object-numbers-work

If we didn't do this, nothing could ever really be removed!

[dpdk-dev] [PATCH v2] kni: Add set_rx_mode callback to handle multicast groups

[Thomas Monjalon]

> > We did some (very basic) tests with IGMP, which involves adding multicast
> > addresses to ETH interfaces. This is done via the ip tool, an example can 
> > be found
> > on e.g.,
> > 
> > http://superuser.com/questions/324824/linux-built-in-or-open-source-program-
> > to-join-multicast-group
> > 
> > and this will fail on KNI interfaces because of an unimplemented ioctl
> > SIOCADDMULTI. The patch simply adds an empty callback for set_rx_mode
> > (typically used for setting up hardware) so that the ioctl succeeds.
> > This is the same thing as the Linux tap interface does.
> > 
> > Signed-off-by: Simon Kagstrom 
> > Signed-off-by: Johan Faltstrom 
> Acked-by: Helin Zhang 

Applied, thanks

[dpdk-dev] [PATCH 1/3] kni: minor opto

[Thomas Monjalon]

2015-06-16 01:15, Zhang, Helin:
> Yes, your patches are OK for me. I have acked it.

Series applied, thanks

[dpdk-dev] [PATCH 4/4] bnx2x: enable PMD build

[Stephen Hemminger]

From: Stephen Hemminger 

This is build infrastructure changes for bnx2x driver.
 - enable BNX2X poll mode driver in default config.
 - add it to mk
 - put entry in MAINTAINERS

Qlogic has discussed taking over as maintainer,
if they want to they can submit a patch to change MAINTAINER file.

Signed-off-by: Stephen Hemminger 
---
 MAINTAINERS |  3 +++
 config/common_linuxapp  | 10 +
 drivers/net/Makefile|  1 +
 drivers/net/bnx2x/Makefile  | 28 +++
 lib/librte_eal/common/include/rte_pci_dev_ids.h | 30 +
 mk/rte.app.mk   |  2 ++
 6 files changed, 74 insertions(+)
 create mode 100644 drivers/net/bnx2x/Makefile

diff --git a/MAINTAINERS b/MAINTAINERS
index 9362c19..3339cbc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -259,6 +259,9 @@ M: John McNamara 
 F: drivers/net/pcap/
 F: doc/guides/nics/pcap_ring.rst

+Qlogic/Broadcom bnx2x
+F: drivers/net/bnx2x/
+
 Ring PMD
 M: Bruce Richardson 
 F: drivers/net/ring/
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 5deb55a..cf30529 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -214,6 +214,16 @@ CONFIG_RTE_LIBRTE_ENIC_PMD=y
 CONFIG_RTE_LIBRTE_ENIC_DEBUG=n

 #
+# Compile burst-oriented Broadcom PMD driver
+#
+CONFIG_RTE_LIBRTE_BNX2X_PMD=y
+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n
+CONFIG_RTE_LIBRTE_BNX2X_DEBUG=n
+CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n
+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n
+CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n
+
+#
 # Compile burst-oriented VIRTIO PMD driver
 #
 CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 1e6648a..c265f63 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -45,6 +45,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += ring
 DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio
 DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3
 DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += xenvirt
+DIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x

 include $(RTE_SDK)/mk/rte.sharelib.mk
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/net/bnx2x/Makefile b/drivers/net/bnx2x/Makefile
new file mode 100644
index 000..0de5db9
--- /dev/null
+++ b/drivers/net/bnx2x/Makefile
@@ -0,0 +1,28 @@
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_bnx2x.a
+
+CFLAGS += -O3 -g
+CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -DZLIB_CONST
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x.c
+SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x_rxtx.c
+SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x_stats.c
+SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x_ethdev.c
+SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += ecore_sp.c
+SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += elink.c
+SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x_vfpf.c
+SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_DEBUG) += debug.c
+
+# this lib depends upon:
+DEPDIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += lib/librte_eal lib/librte_ether 
lib/librte_hash
+DEPDIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += lib/librte_mempool lib/librte_mbuf
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h 
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 5d1b285..35429e9 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -144,6 +144,14 @@
 #define RTE_PCI_DEV_ID_DECL_ENIC(vend, dev)
 #endif

+#ifndef RTE_PCI_DEV_ID_DECL_BNX2X
+#define RTE_PCI_DEV_ID_DECL_BNX2X(vend, dev)
+#endif
+
+#ifndef RTE_PCI_DEV_ID_DECL_BNX2XVF
+#define RTE_PCI_DEV_ID_DECL_BNX2XVF(vend, dev)
+#endif
+
 #ifndef PCI_VENDOR_ID_INTEL
 /** Vendor ID used by Intel devices */
 #define PCI_VENDOR_ID_INTEL 0x8086
@@ -164,6 +172,11 @@
 #define PCI_VENDOR_ID_CISCO 0x1137
 #endif

+#ifndef PCI_VENDOR_ID_BROADCOM
+/** Vendor ID used by Broadcom devices */
+#define PCI_VENDOR_ID_BROADCOM 0x14E4
+#endif
+
 / Physical EM devices from e1000_hw.h /

 #define E1000_DEV_ID_825420x1000
@@ -565,6 +578,21 @@ RTE_PCI_DEV_ID_DECL_FM10KVF(PCI_VENDOR_ID_INTEL, 
FM10K_DEV_ID_VF)
 RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET)
 RTE_PCI_DEV_ID_DECL_ENIC(PCI_VENDOR_ID_CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_VF)

+/** Qualcom devices **/
+
+/* Broadcom/Qualcom BNX2X */
+#define BNX2X_DEV_ID_57711 0x164F
+#define BNX2X_DEV_ID_57810 0x168E
+#define BNX2X_DEV_ID_57810_MF  0x16AE
+#define BNX2X_DEV_ID_57810_VF  0x16AF
+
+RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57711)
+RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57810)
+#ifdef RTE_LIBRTE_BNX2X_MF_SUPPORT
+RTE_PCI_DEV_ID_DECL_BNX2X(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57810_MF)
+#endif
+RTE_PCI_DEV_ID_DECL_BNX2XVF(PCI_VENDOR_ID_BROADCOM, BNX2X_DEV_ID_57810_VF)
+
 /*
  * Undef all RTE_PCI_DEV_ID_DECL_* h

[dpdk-dev] [PATCH 3/4] bnx2x: driver support routines

[Stephen Hemminger]

From: Stephen Hemminger 

More code for the Broadcom/Qlogic NetExtreme II poll mode driver.
Split into pieces for review and not to overwhelm mailers.

Signed-off-by: Stephen Hemminger 
---
 drivers/net/bnx2x/debug.c   |   113 +
 drivers/net/bnx2x/ecore_fw_defs.h   |   422 +
 drivers/net/bnx2x/ecore_hsi.h   |  6348 
 drivers/net/bnx2x/ecore_init.h  |   841 ++
 drivers/net/bnx2x/ecore_init_ops.h  |   886 ++
 drivers/net/bnx2x/ecore_mfw_req.h   |   206 +
 drivers/net/bnx2x/ecore_reg.h   |  3663 +++
 drivers/net/bnx2x/ecore_sp.c|  5455 +++
 drivers/net/bnx2x/ecore_sp.h|  1795 
 drivers/net/bnx2x/elink.c   | 13378 ++
 drivers/net/bnx2x/elink.h   |   609 ++
 drivers/net/bnx2x/rte_pmd_bnx2x_version.map | 4 +
 12 files changed, 33720 insertions(+)
 create mode 100644 drivers/net/bnx2x/debug.c
 create mode 100644 drivers/net/bnx2x/ecore_fw_defs.h
 create mode 100644 drivers/net/bnx2x/ecore_hsi.h
 create mode 100644 drivers/net/bnx2x/ecore_init.h
 create mode 100644 drivers/net/bnx2x/ecore_init_ops.h
 create mode 100644 drivers/net/bnx2x/ecore_mfw_req.h
 create mode 100644 drivers/net/bnx2x/ecore_reg.h
 create mode 100644 drivers/net/bnx2x/ecore_sp.c
 create mode 100644 drivers/net/bnx2x/ecore_sp.h
 create mode 100644 drivers/net/bnx2x/elink.c
 create mode 100644 drivers/net/bnx2x/elink.h
 create mode 100644 drivers/net/bnx2x/rte_pmd_bnx2x_version.map

diff --git a/drivers/net/bnx2x/debug.c b/drivers/net/bnx2x/debug.c
new file mode 100644
index 000..ba51f1a
--- /dev/null
+++ b/drivers/net/bnx2x/debug.c
@@ -0,0 +1,113 @@
+/*-
+ * Copyright (c) 2007-2013 Broadcom Corporation. All rights reserved.
+ *
+ * Eric Davis
+ * David Christensen 
+ * Gary Zambrano 
+ *
+ * Copyright (c) 2013-2015 Brocade Communications Systems, Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. 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.
+ * 3. Neither the name of Broadcom Corporation nor the name of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written consent.
+ *
+ * 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.
+ */
+
+#include "bnx2x.h"
+
+
+/*
+ * Debug versions of the 8/16/32 bit OS register read/write functions to
+ * capture/display values read/written from/to the controller.
+ */
+void
+bnx2x_reg_write8(struct bnx2x_softc *sc, size_t offset, uint8_t val)
+{
+   PMD_DRV_LOG(DEBUG, "offset=0x%08lx val=0x%02x", offset, val);
+   *((volatile uint8_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)) = 
val;
+}
+
+void
+bnx2x_reg_write16(struct bnx2x_softc *sc, size_t offset, uint16_t val)
+{
+   if ((offset % 2) != 0) {
+   PMD_DRV_LOG(DEBUG, "Unaligned 16-bit write to 0x%08lx", offset);
+   }
+
+   PMD_DRV_LOG(DEBUG, "offset=0x%08lx val=0x%04x", offset, val);
+   *((volatile uint16_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)) = 
val;
+}
+
+void
+bnx2x_reg_write32(struct bnx2x_softc *sc, size_t offset, uint32_t val)
+{
+   if ((offset % 4) != 0) {
+   PMD_DRV_LOG(DEBUG, "Unaligned 32-bit write to 0x%08lx", offset);
+   }
+
+   PMD_DRV_LOG(DEBUG, "offset=0x%08lx val=0x%08x", offset, val);
+   *((volatile uint32_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)) = 
val;
+}
+
+uint8_t
+bnx2x_reg_read8(struct bnx2x_softc *sc, size_t offset)
+{
+   uint8_t val;
+
+   val = (uint8_t)(*((volatile uint8_t*)((uint64_t)sc->bar[BAR0].base_addr 
+ offset)));
+   PMD_DRV_LOG(DEBUG, "offset=0x%08lx val=0x%02x", offset, val);
+
+   return (val);
+}
+
+uint16_t
+bnx2x_reg_read16(struct bnx2x_softc *sc, s

[dpdk-dev] [PATCH 2/4] bnx2x: driver core

[Stephen Hemminger]

From: Stephen Hemminger 

This is the first of several parts for a new driver supporting
Broadcom/Qlogic NetXtremeII 10 gigabit devices.

Signed-off-by: Stephen Hemminger 
---
 drivers/net/bnx2x/bnx2x.c| 11821 +
 drivers/net/bnx2x/bnx2x.h|  1998 +++
 drivers/net/bnx2x/bnx2x_ethdev.c |   542 ++
 drivers/net/bnx2x/bnx2x_ethdev.h |79 +
 drivers/net/bnx2x/bnx2x_logs.h   |51 +
 drivers/net/bnx2x/bnx2x_rxtx.c   |   487 ++
 drivers/net/bnx2x/bnx2x_rxtx.h   |85 +
 drivers/net/bnx2x/bnx2x_stats.c  |  1619 +
 drivers/net/bnx2x/bnx2x_stats.h  |   632 ++
 drivers/net/bnx2x/bnx2x_vfpf.c   |   597 ++
 drivers/net/bnx2x/bnx2x_vfpf.h   |   315 +
 11 files changed, 18226 insertions(+)
 create mode 100644 drivers/net/bnx2x/bnx2x.c
 create mode 100644 drivers/net/bnx2x/bnx2x.h
 create mode 100644 drivers/net/bnx2x/bnx2x_ethdev.c
 create mode 100644 drivers/net/bnx2x/bnx2x_ethdev.h
 create mode 100644 drivers/net/bnx2x/bnx2x_logs.h
 create mode 100644 drivers/net/bnx2x/bnx2x_rxtx.c
 create mode 100644 drivers/net/bnx2x/bnx2x_rxtx.h
 create mode 100644 drivers/net/bnx2x/bnx2x_stats.c
 create mode 100644 drivers/net/bnx2x/bnx2x_stats.h
 create mode 100644 drivers/net/bnx2x/bnx2x_vfpf.c
 create mode 100644 drivers/net/bnx2x/bnx2x_vfpf.h

diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
new file mode 100644
index 000..154c0f6
--- /dev/null
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -0,0 +1,11821 @@
+/*-
+ * Copyright (c) 2007-2013 Broadcom Corporation. All rights reserved.
+ *
+ * Eric Davis
+ * David Christensen 
+ * Gary Zambrano 
+ *
+ * Copyright (c) 2013-2015 Brocade Communications Systems, Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. 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.
+ * 3. Neither the name of Broadcom Corporation nor the name of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written consent.
+ *
+ * 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.
+ */
+
+#define BNX2X_DRIVER_VERSION "1.78.18"
+
+#include "bnx2x.h"
+#include "bnx2x_vfpf.h"
+#include "ecore_sp.h"
+#include "ecore_init.h"
+#include "ecore_init_ops.h"
+
+#include "rte_pci_dev_ids.h"
+
+#include 
+#include 
+#include 
+#include 
+
+static z_stream zlib_stream;
+
+#define EVL_VLID_MASK 0x0FFF
+
+#define BNX2X_DEF_SB_ATT_IDX 0x0001
+#define BNX2X_DEF_SB_IDX 0x0002
+
+/*
+ * FLR Support - bnx2x_pf_flr_clnup() is called during nic_load in the per
+ * function HW initialization.
+ */
+#define FLR_WAIT_USEC 1/* 10 msecs */
+#define FLR_WAIT_INTERVAL 50   /* usecs */
+#define FLR_POLL_CNT  (FLR_WAIT_USEC / FLR_WAIT_INTERVAL)  /* 200 */
+
+struct pbf_pN_buf_regs {
+   int pN;
+   uint32_t init_crd;
+   uint32_t crd;
+   uint32_t crd_freed;
+};
+
+struct pbf_pN_cmd_regs {
+   int pN;
+   uint32_t lines_occup;
+   uint32_t lines_freed;
+};
+
+/* resources needed for unloading a previously loaded device */
+
+#define BNX2X_PREV_WAIT_NEEDED 1
+rte_spinlock_t bnx2x_prev_mtx;
+struct bnx2x_prev_list_node {
+   LIST_ENTRY(bnx2x_prev_list_node) node;
+   uint8_t bus;
+   uint8_t slot;
+   uint8_t path;
+   uint8_t aer;
+   uint8_t undi;
+};
+
+static LIST_HEAD(, bnx2x_prev_list_node) bnx2x_prev_list
+   = LIST_HEAD_INITIALIZER(bnx2x_prev_list);
+
+static int load_count[2][3] = { { 0 } };
+   /* per-path: 0-common, 1-port0, 2-port1 */
+
+static void bnx2x_cmng_fns_init(struct bnx2x_softc *sc, uint8_t read_cfg,
+   uint8_t cmng_type);
+static int bnx2x_get_cmng_fns_mode(struct bnx2x_softc *sc);
+static void storm_memset_cmng(struct bnx2x_softc *sc, struct cmng_init *cmng,
+   

[dpdk-dev] [PATCH 1/4] eal: provide functions to access PCI config

[Stephen Hemminger]

From: Stephen Hemminger 

Some drivers need ability to access PCI config (for example for power
management). This adds an abstraction to do this for both Linux
and BSD.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_eal/bsdapp/eal/eal_pci.c | 83 +
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  2 +
 lib/librte_eal/common/include/rte_pci.h | 28 +
 lib/librte_eal/linuxapp/eal/eal_pci.c   | 50 +++
 lib/librte_eal/linuxapp/eal/eal_pci_init.h  | 11 
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c   | 14 +
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c  | 16 +
 lib/librte_eal/linuxapp/eal/rte_eal_version.map |  2 +
 8 files changed, 206 insertions(+)

diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c 
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 61e8921..bf6bc93 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -490,6 +490,89 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr, 
struct rte_pci_device *d
return 1;
 }

+/* Read PCI config space. */
+int rte_eal_pci_read_config(const struct rte_pci_device *dev,
+   void *buf, size_t len, off_t offset)
+{
+   int fd = -1;
+   struct pci_io pi = {
+   .pi_sel = {
+   .pc_domain = dev->addr.domain,
+   .pc_bus = dev->addr.bus,
+   .pc_dev = dev->addr.devid,
+   .pc_func = dev->addr.function,
+   },
+   .pi_reg = offset,
+   .pi_width = len,
+   };
+
+   if (len == 3 || len > sizeof(pi.pi_data)) {
+   RTE_LOG(ERR, EAL, "%s(): invalid pci read length\n", __func__);
+   goto error;
+   }
+
+   fd = open("/dev/pci", O_RDONLY);
+   if (fd < 0) {
+   RTE_LOG(ERR, EAL, "%s(): error opening /dev/pci\n", __func__);
+   goto error;
+   }
+
+   if (ioctl(fd, PCIOCREAD, &pi) < 0)
+   goto error;
+   close(fd);
+
+   memcpy(buf, &pi.pi_data, len);
+   return 0;
+
+ error:
+   if (fd >= 0)
+   close(fd);
+   return -1;
+}
+
+/* Write PCI config space. */
+int rte_eal_pci_write_config(const struct rte_pci_device *dev,
+const void *buf, size_t len, off_t offset)
+{
+   int fd = -1;
+
+   struct pci_io pi = {
+   .pi_sel = {
+   .pc_domain = dev->addr.domain,
+   .pc_bus = dev->addr.bus,
+   .pc_dev = dev->addr.devid,
+   .pc_func = dev->addr.function,
+   },
+   .pi_reg = offset,
+   .pi_data = *(u_int32_t *)buf,
+   .pi_width = len,
+   };
+
+   if (len == 3 || len > sizeof(pi.pi_data)) {
+   RTE_LOG(ERR, EAL, "%s(): invalid pci read length\n", __func__);
+   goto error;
+   }
+
+   memcpy(pi.pi_data, buf, len);
+
+   fd = open("/dev/pci", O_RDONLY);
+   if (fd < 0) {
+   RTE_LOG(ERR, EAL, "%s(): error opening /dev/pci\n", __func__);
+   goto error;
+   }
+
+   if (ioctl(fd, PCIOCWRITE, &pi) < 0)
+   goto error;
+
+   close(fd);
+   return 0;
+
+ error:
+   if (fd >= 0)
+   close(fd);
+   return -1;
+}
+
 /* Init the PCI EAL subsystem */
 int
 rte_eal_pci_init(void)
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map 
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 67b6a6c..6d2ee41 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -39,8 +39,10 @@ DPDK_2.0 {
rte_eal_mp_wait_lcore;
rte_eal_pci_dump;
rte_eal_pci_probe;
+   rte_eal_pci_read_config;
rte_eal_pci_register;
rte_eal_pci_unregister;
+   rte_eal_pci_write_config;
rte_eal_process_type;
rte_eal_remote_launch;
rte_eal_tailq_lookup;
diff --git a/lib/librte_eal/common/include/rte_pci.h 
b/lib/librte_eal/common/include/rte_pci.h
index b4f38bc..62fb0ea 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -394,6 +394,34 @@ void rte_eal_pci_register(struct rte_pci_driver *driver);
  */
 void rte_eal_pci_unregister(struct rte_pci_driver *driver);

+/**
+ * Read PCI config space.
+ *
+ * @param device
+ *   A pointer to a rte_pci_device structure describing the device
+ *   to use
+ * @param buf
+ *   A data buffer where the bytes should be read into
+ * @param size
+ *   The length of the data buffer.
+ */
+int rte_eal_pci_read_config(const struct rte_pci_device *device,
+   void *buf, size_t len, off_t offset);
+
+/**
+ * Write PCI config space.
+ *
+ * @param device
+ *   A pointer to a rte_pci_device structure describing the device
+ *   to use
+ * @param buf
+ *   A data buffer containing the bytes sh

[dpdk-dev] [PATCH 0/4 v5] bnx2x: poll mode driver

[Stephen Hemminger]

From: Stephen Hemminger 

Changes since last time:
 1. Support pci_config on BSD. Although since BSD probably doesn't
have same filesystem  (/lib/firmware) the driver won't work.
 2. Change location of driver to match new filesystem hierarchy

Stephen Hemminger (4):
  eal: provide functions to access PCI config
  bnx2x: driver core
  bnx2x: driver support routines
  bnx2x: enable PMD build

 MAINTAINERS | 3 +
 config/common_linuxapp  |10 +
 drivers/net/Makefile| 1 +
 drivers/net/bnx2x/Makefile  |28 +
 drivers/net/bnx2x/bnx2x.c   | 11821 +++
 drivers/net/bnx2x/bnx2x.h   |  1998 
 drivers/net/bnx2x/bnx2x_ethdev.c|   542 +
 drivers/net/bnx2x/bnx2x_ethdev.h|79 +
 drivers/net/bnx2x/bnx2x_logs.h  |51 +
 drivers/net/bnx2x/bnx2x_rxtx.c  |   487 +
 drivers/net/bnx2x/bnx2x_rxtx.h  |85 +
 drivers/net/bnx2x/bnx2x_stats.c |  1619 +++
 drivers/net/bnx2x/bnx2x_stats.h |   632 +
 drivers/net/bnx2x/bnx2x_vfpf.c  |   597 +
 drivers/net/bnx2x/bnx2x_vfpf.h  |   315 +
 drivers/net/bnx2x/debug.c   |   113 +
 drivers/net/bnx2x/ecore_fw_defs.h   |   422 +
 drivers/net/bnx2x/ecore_hsi.h   |  6348 ++
 drivers/net/bnx2x/ecore_init.h  |   841 ++
 drivers/net/bnx2x/ecore_init_ops.h  |   886 ++
 drivers/net/bnx2x/ecore_mfw_req.h   |   206 +
 drivers/net/bnx2x/ecore_reg.h   |  3663 ++
 drivers/net/bnx2x/ecore_sp.c|  5455 +
 drivers/net/bnx2x/ecore_sp.h|  1795 +++
 drivers/net/bnx2x/elink.c   | 13378 ++
 drivers/net/bnx2x/elink.h   |   609 +
 drivers/net/bnx2x/rte_pmd_bnx2x_version.map | 4 +
 lib/librte_eal/bsdapp/eal/eal_pci.c |83 +
 lib/librte_eal/bsdapp/eal/rte_eal_version.map   | 2 +
 lib/librte_eal/common/include/rte_pci.h |28 +
 lib/librte_eal/common/include/rte_pci_dev_ids.h |30 +
 lib/librte_eal/linuxapp/eal/eal_pci.c   |50 +
 lib/librte_eal/linuxapp/eal/eal_pci_init.h  |11 +
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c   |14 +
 lib/librte_eal/linuxapp/eal/eal_pci_vfio.c  |16 +
 lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 +
 mk/rte.app.mk   | 2 +
 37 files changed, 52226 insertions(+)
 create mode 100644 drivers/net/bnx2x/Makefile
 create mode 100644 drivers/net/bnx2x/bnx2x.c
 create mode 100644 drivers/net/bnx2x/bnx2x.h
 create mode 100644 drivers/net/bnx2x/bnx2x_ethdev.c
 create mode 100644 drivers/net/bnx2x/bnx2x_ethdev.h
 create mode 100644 drivers/net/bnx2x/bnx2x_logs.h
 create mode 100644 drivers/net/bnx2x/bnx2x_rxtx.c
 create mode 100644 drivers/net/bnx2x/bnx2x_rxtx.h
 create mode 100644 drivers/net/bnx2x/bnx2x_stats.c
 create mode 100644 drivers/net/bnx2x/bnx2x_stats.h
 create mode 100644 drivers/net/bnx2x/bnx2x_vfpf.c
 create mode 100644 drivers/net/bnx2x/bnx2x_vfpf.h
 create mode 100644 drivers/net/bnx2x/debug.c
 create mode 100644 drivers/net/bnx2x/ecore_fw_defs.h
 create mode 100644 drivers/net/bnx2x/ecore_hsi.h
 create mode 100644 drivers/net/bnx2x/ecore_init.h
 create mode 100644 drivers/net/bnx2x/ecore_init_ops.h
 create mode 100644 drivers/net/bnx2x/ecore_mfw_req.h
 create mode 100644 drivers/net/bnx2x/ecore_reg.h
 create mode 100644 drivers/net/bnx2x/ecore_sp.c
 create mode 100644 drivers/net/bnx2x/ecore_sp.h
 create mode 100644 drivers/net/bnx2x/elink.c
 create mode 100644 drivers/net/bnx2x/elink.h
 create mode 100644 drivers/net/bnx2x/rte_pmd_bnx2x_version.map

-- 
2.1.4

[dpdk-dev] [PATCH v3] kni: Add link status update

[Thomas Monjalon]

> > Implement .ndo_change_carrier to enable
> > DPDK applications to propagate link state changes to kni virtual interfaces
> > through sysfs
> > 
> > Signed-off-by: Vijayakumar Muthuvel Manickam 
> Acked-by: Helin Zhang 

Applied, thanks

[dpdk-dev] [PATCH 1/4] kni: add function to query the name of a kni object

[Thomas Monjalon]

> > When a KNI object is created, a name is assigned to it which is stored 
> > internally.
> > There is also an API function to look up a KNI object by name, but there is 
> > no API
> > to query the current name of an existing KNI object. This patch adds just 
> > such an
> > API.
> > 
> > Signed-off-by: Bruce Richardson 
> Acked-by: Helin Zhang 

The .map file change was not alphabetical (fixed on the fly).

Applied, thanks

[dpdk-dev] [PATCH 1/6] eal: add const in prefetch functions

[Bruce Richardson]

On Fri, Jun 05, 2015 at 03:33:19PM +0100, Pablo de Lara wrote:
> rte_prefetchX functions included volatile void *p as parameter,
> but the function does not modify it, so it should include the const keyword.
> 
> Signed-off-by: Pablo de Lara 

Acked-by: Bruce Richardson 

[dpdk-dev] Debugging SR-IOV related packet flow problem with DPDK

[Anjali Kulkarni]

Pls keep me on cc for response. Thanks!!

Hi,

I am observing that the SR-IOV enabled NIC does not increment any VF packet 
counters despite incoming packet flow. I have enabled some debug logs like 
CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX in config file.
Can someone point me to where these logs are being printed so I can try to 
figure out where packets are being dropped? Or how can I debug DPDK packet flow 
related issues (are there any stats I can look at)?

Thanks
Anjali

[dpdk-dev] [PATCH] ixgbe: fix x550 shutdown API issue

[Wenzhuo Lu]

For there're only laser ports on x550 before, we only considered laser
ports for the testpmd CLIs "port start/stop ...". Now we have new x550
devices which have copper ports. Use the API for copper to enable/disable
these ports.

And also let the testpmd CLI "set link-up/down ..." support copper
ports.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 44 +++-
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 7414a2e..ac7608e 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1522,8 +1522,13 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
goto error;
}

-   /* Turn on the laser */
-   ixgbe_enable_tx_laser(hw);
+   if (hw->mac.ops.get_media_type(hw) == ixgbe_media_type_copper) {
+   /* Turn on the copper */
+   ixgbe_set_phy_power(hw, true);
+   } else {
+   /* Turn on the laser */
+   ixgbe_enable_tx_laser(hw);
+   }

err = ixgbe_check_link(hw, &speed, &link_up, 0);
if (err)
@@ -1643,8 +1648,13 @@ ixgbe_dev_stop(struct rte_eth_dev *dev)
 vf < dev->pci_dev->max_vfs; vf++)
vfinfo[vf].clear_to_send = false;

-   /* Turn off the laser */
-   ixgbe_disable_tx_laser(hw);
+   if (hw->mac.ops.get_media_type(hw) == ixgbe_media_type_copper) {
+   /* Turn off the copper */
+   ixgbe_set_phy_power(hw, false);
+   } else {
+   /* Turn off the laser */
+   ixgbe_disable_tx_laser(hw);
+   }

ixgbe_dev_clear_queues(dev);

@@ -1670,7 +1680,7 @@ ixgbe_dev_stop(struct rte_eth_dev *dev)
 }

 /*
- * Set device link up: enable tx laser.
+ * Set device link up: enable tx.
  */
 static int
 ixgbe_dev_set_link_up(struct rte_eth_dev *dev)
@@ -1686,18 +1696,21 @@ ixgbe_dev_set_link_up(struct rte_eth_dev *dev)
return -ENOTSUP;
}
 #endif
+   }
+
+   if (hw->mac.ops.get_media_type(hw) == ixgbe_media_type_copper) {
+   /* Turn on the copper */
+   ixgbe_set_phy_power(hw, true);
+   } else {
/* Turn on the laser */
ixgbe_enable_tx_laser(hw);
-   return 0;
}

-   PMD_INIT_LOG(ERR, "Set link up is not supported by device id 0x%x",
-hw->device_id);
-   return -ENOTSUP;
+   return 0;
 }

 /*
- * Set device link down: disable tx laser.
+ * Set device link down: disable tx.
  */
 static int
 ixgbe_dev_set_link_down(struct rte_eth_dev *dev)
@@ -1713,14 +1726,17 @@ ixgbe_dev_set_link_down(struct rte_eth_dev *dev)
return -ENOTSUP;
}
 #endif
+   }
+
+   if (hw->mac.ops.get_media_type(hw) == ixgbe_media_type_copper) {
+   /* Turn off the copper */
+   ixgbe_set_phy_power(hw, false);
+   } else {
/* Turn off the laser */
ixgbe_disable_tx_laser(hw);
-   return 0;
}

-   PMD_INIT_LOG(ERR, "Set link down is not supported by device id 0x%x",
-hw->device_id);
-   return -ENOTSUP;
+   return 0;
 }

 /*
-- 
1.9.3

[dpdk-dev] [PATCH 1/3] pmd_ring: remove deprecated functions

[Stephen Hemminger]

On Tue, 16 Jun 2015 14:52:16 +0100
Bruce Richardson  wrote:

> On Mon, Jun 15, 2015 at 09:51:11AM -0700, Stephen Hemminger wrote:
> > From: Stephen Hemminger 
> > 
> > These were deprecated in 2.0 so remove them from 2.1
> > 
> > Signed-off-by: Stephen Hemminger 
> > ---
> >  drivers/net/ring/rte_eth_ring.c   | 55 
> > ---
> >  drivers/net/ring/rte_eth_ring_version.map |  4 +--
> >  2 files changed, 1 insertion(+), 58 deletions(-)
> >   
> [..snip..]
> > diff --git a/drivers/net/ring/rte_eth_ring_version.map 
> > b/drivers/net/ring/rte_eth_ring_version.map
> > index 8ad107d..5ee55d9 100644
> > --- a/drivers/net/ring/rte_eth_ring_version.map
> > +++ b/drivers/net/ring/rte_eth_ring_version.map
> > @@ -1,9 +1,7 @@
> > -DPDK_2.0 {
> > +DPDK_2.1 {
> > global:
> >  
> > rte_eth_from_rings;
> > -   rte_eth_ring_pair_attach;
> > -   rte_eth_ring_pair_create;
> >  
> > local: *;
> >  };  
> 
> [ABI newbie question] Is this how deprecating a fn is done? We no longer have 
> any DPDK_2.0 
> version listings in the .map file?

Notice the version # changed as well, so linker will generate a new version.
The function was marked deprecated in last version.

[dpdk-dev] [PATCH 0/6] Cuckoo hash

[Thomas Monjalon]

Hi Pablo,

2015-06-05 15:33, Pablo de Lara:
> Things left for v2:
> - Improve unit tests to show clearer performance numbers
> - Documentation changes

When do you plan to submit a v2?

[dpdk-dev] [PATCH] ixgbevf: fix link status for PF up/down events

[Sergio Gonzalez Monroy]

Current ixgbe VF base driver only really read the status register when:
 - get_link_status is true
 - link reset
 - mailbox timeout.

We only set get_link_status to true when we start the PF/VF, so
following calls to ixgbe_dev_link_update will just keep the old link
status unless the link has been reset.

Because of this behaviour, when the link status of the PF changes after
the VF has been initialized, we do not read the current status register
from the nic and instead we just keep the old link status.

Fix the problem by setting this field to true before calling
ixgbe_check_link function from base driver. We don't need to check after
this call for get_link_status anymore, so remove it.

Signed-off-by: Sergio Gonzalez Monroy 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 7414a2e..4affb01 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2128,11 +2128,14 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)
memset(&old, 0, sizeof(old));
rte_ixgbe_dev_atomic_read_link_status(dev, &old);

+   hw->mac.get_link_status = true;
+
/* check if it needs to wait to complete, if lsc interrupt is enabled */
if (wait_to_complete == 0 || dev->data->dev_conf.intr_conf.lsc != 0)
diag = ixgbe_check_link(hw, &link_speed, &link_up, 0);
else
diag = ixgbe_check_link(hw, &link_speed, &link_up, 1);
+
if (diag != 0) {
link.link_speed = ETH_LINK_SPEED_100;
link.link_duplex = ETH_LINK_HALF_DUPLEX;
@@ -2142,12 +2145,6 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)
return 0;
}

-   if (link_speed == IXGBE_LINK_SPEED_UNKNOWN &&
-   !hw->mac.get_link_status) {
-   memcpy(&link, &old, sizeof(link));
-   return -1;
-   }
-
if (link_up == 0) {
rte_ixgbe_dev_atomic_write_link_status(dev, &link);
if (link.link_status == old.link_status)
-- 
1.9.3

[dpdk-dev] [PATCH v3 00/10] Add a VXLAN sample

[Thomas Monjalon]

2015-06-16 12:49, Liu, Jijiang:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sorry, there are too many checkpatch errors to peacefully apply this series.
> 
> Dou you mean there are too many warnings or errors when using checkpatch.pl?
> 
> If you meant warnings, yes, there are some warnings that I have not removed 
> from patches.

Yes I mean warnings. Most of them should be removed.
Please try to comply with the established coding style.

> If you meant errors, I will double check.

[dpdk-dev] [PATCH v6 08/10] hash: remove duplicated code

[Thomas Monjalon]

2015-06-16 10:31, De Lara Guarch, Pablo:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > The following patch is needed and will be squashed to fix some doxygen
> > issues:
|...]
|> Thanks for spotting this!
> Are you going to do it yourself or you want me to do it and send a v7?

Already squashed with patch 7:
http://dpdk.org/browse/dpdk/commit/?id=8718219a8737b8

[dpdk-dev] [PATCH 1/3] pmd_ring: remove deprecated functions

[Bruce Richardson]

On Mon, Jun 15, 2015 at 09:51:11AM -0700, Stephen Hemminger wrote:
> From: Stephen Hemminger 
> 
> These were deprecated in 2.0 so remove them from 2.1
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  drivers/net/ring/rte_eth_ring.c   | 55 
> ---
>  drivers/net/ring/rte_eth_ring_version.map |  4 +--
>  2 files changed, 1 insertion(+), 58 deletions(-)
> 
[..snip..]
> diff --git a/drivers/net/ring/rte_eth_ring_version.map 
> b/drivers/net/ring/rte_eth_ring_version.map
> index 8ad107d..5ee55d9 100644
> --- a/drivers/net/ring/rte_eth_ring_version.map
> +++ b/drivers/net/ring/rte_eth_ring_version.map
> @@ -1,9 +1,7 @@
> -DPDK_2.0 {
> +DPDK_2.1 {
>   global:
>  
>   rte_eth_from_rings;
> - rte_eth_ring_pair_attach;
> - rte_eth_ring_pair_create;
>  
>   local: *;
>  };

[ABI newbie question] Is this how deprecating a fn is done? We no longer have 
any DPDK_2.0 
version listings in the .map file?

[dpdk-dev] [PATCH v4] doc: guidelines for library statistics

[Cristian Dumitrescu]

v4 changes
-more fixes for bullets

v3 changes
-fixed bullets for correct doc generation

v2 changes
-small text changes
-reordered sections to have guidelines at the top and motivation at the end
-broke lines at 80 characters

Signed-off-by: Cristian Dumitrescu 
---
 doc/guides/guidelines/index.rst  |1 +
 doc/guides/guidelines/statistics.rst |  104 ++
 2 files changed, 105 insertions(+), 0 deletions(-)
 create mode 100644 doc/guides/guidelines/statistics.rst

diff --git a/doc/guides/guidelines/index.rst b/doc/guides/guidelines/index.rst
index b2b0a92..c01f958 100644
--- a/doc/guides/guidelines/index.rst
+++ b/doc/guides/guidelines/index.rst
@@ -6,3 +6,4 @@ Guidelines
 :numbered:

 coding_style
+statistics
diff --git a/doc/guides/guidelines/statistics.rst 
b/doc/guides/guidelines/statistics.rst
new file mode 100644
index 000..bc91723
--- /dev/null
+++ b/doc/guides/guidelines/statistics.rst
@@ -0,0 +1,104 @@
+Library Statistics
+==
+
+Description
+---
+
+This document describes the guidelines for DPDK library-level statistics 
counter
+support. This includes guidelines for turning library statistics on and off and
+requirements for preventing ABI changes when implementing statistics.
+
+
+Mechanism to allow the application to turn library statistics on and off
+
+
+Each library that maintains statistics counters should provide a single build
+time flag that decides whether the statistics counter collection is enabled or
+not. This flag should be exposed as a variable within the DPDK configuration
+file. When this flag is set, all the counters supported by current library are
+collected for all the instances of every object type provided by the library.
+When this flag is cleared, none of the counters supported by the current 
library
+are collected for any instance of any object type provided by the library:
+
+.. code-block:: console
+
+   # DPDK file config/common_linuxapp, config/common_bsdapp, etc.
+   CONFIG_RTE__STATS_COLLECT=y/n
+
+The default value for this DPDK configuration file variable (either "yes" or
+"no") is decided by each library.
+
+
+Prevention of ABI changes due to library statistics support
+---
+
+The layout of data structures and prototype of functions that are part of the
+library API should not be affected by whether the collection of statistics
+counters is turned on or off for the current library. In practical terms, this
+means that space should always be allocated in the API data structures for
+statistics counters and the statistics related API functions are always built
+into the code, regardless of whether the statistics counter collection is 
turned
+on or off for the current library.
+
+When the collection of statistics counters for the current library is turned
+off, the counters retrieved through the statistics related API functions should
+have a default value of zero.
+
+
+Motivation to allow the application to turn library statistics on and off
+-
+
+It is highly recommended that each library provides statistics counters to 
allow
+an application to monitor the library-level run-time events. Typical counters
+are: number of packets received/dropped/transmitted, number of buffers
+allocated/freed, number of occurrences for specific events, etc.
+
+However, the resources consumed for library-level statistics counter collection
+have to be spent out of the application budget and the counters collected by
+some libraries might not be relevant to the current application. In order to
+avoid any unwanted waste of resources and/or performance impacts, the
+application should decide at build time whether the collection of library-level
+statistics counters should be turned on or off for each library individually.
+
+Library-level statistics counters can be relevant or not for specific
+applications:
+
+* For Application A, counters maintained by Library X are always relevant and
+  the application needs to use them to implement certain features, such as 
traffic
+  accounting, logging, application-level statistics, etc. In this case,
+  the application requires that collection of statistics counters for Library 
X is
+  always turned on.
+
+* For Application B, counters maintained by Library X are only useful during 
the
+  application debug stage and are not relevant once debug phase is over. In 
this
+  case, the application may decide to turn on the collection of Library X
+  statistics counters during the debug phase and at a later stage turn them 
off.
+
+* For Application C, counters maintained by Library X are not relevant at all.
+  It might be that the application maintains its own set of statistics counters
+  that monitor a different set of run-time events (e.g. number of connection

[dpdk-dev] [PATCH v3] doc: guidelines for library statistics

[Cristian Dumitrescu]

v3 changes
-fixed bullets for correct doc generation

v2 changes
-small text changes
-reordered sections to have guidelines at the top and motivation at the end
-broke lines at 80 characters

Signed-off-by: Cristian Dumitrescu 
---
 doc/guides/guidelines/index.rst  |1 +
 doc/guides/guidelines/statistics.rst |  104 ++
 2 files changed, 105 insertions(+), 0 deletions(-)
 create mode 100644 doc/guides/guidelines/statistics.rst

diff --git a/doc/guides/guidelines/index.rst b/doc/guides/guidelines/index.rst
index b2b0a92..c01f958 100644
--- a/doc/guides/guidelines/index.rst
+++ b/doc/guides/guidelines/index.rst
@@ -6,3 +6,4 @@ Guidelines
 :numbered:

 coding_style
+statistics
diff --git a/doc/guides/guidelines/statistics.rst 
b/doc/guides/guidelines/statistics.rst
new file mode 100644
index 000..bc91723
--- /dev/null
+++ b/doc/guides/guidelines/statistics.rst
@@ -0,0 +1,104 @@
+Library Statistics
+==
+
+Description
+---
+
+This document describes the guidelines for DPDK library-level statistics 
counter
+support. This includes guidelines for turning library statistics on and off and
+requirements for preventing ABI changes when implementing statistics.
+
+
+Mechanism to allow the application to turn library statistics on and off
+
+
+Each library that maintains statistics counters should provide a single build
+time flag that decides whether the statistics counter collection is enabled or
+not. This flag should be exposed as a variable within the DPDK configuration
+file. When this flag is set, all the counters supported by current library are
+collected for all the instances of every object type provided by the library.
+When this flag is cleared, none of the counters supported by the current 
library
+are collected for any instance of any object type provided by the library:
+
+.. code-block:: console
+
+   # DPDK file config/common_linuxapp, config/common_bsdapp, etc.
+   CONFIG_RTE__STATS_COLLECT=y/n
+
+The default value for this DPDK configuration file variable (either "yes" or
+"no") is decided by each library.
+
+
+Prevention of ABI changes due to library statistics support
+---
+
+The layout of data structures and prototype of functions that are part of the
+library API should not be affected by whether the collection of statistics
+counters is turned on or off for the current library. In practical terms, this
+means that space should always be allocated in the API data structures for
+statistics counters and the statistics related API functions are always built
+into the code, regardless of whether the statistics counter collection is 
turned
+on or off for the current library.
+
+When the collection of statistics counters for the current library is turned
+off, the counters retrieved through the statistics related API functions should
+have a default value of zero.
+
+
+Motivation to allow the application to turn library statistics on and off
+-
+
+It is highly recommended that each library provides statistics counters to 
allow
+an application to monitor the library-level run-time events. Typical counters
+are: number of packets received/dropped/transmitted, number of buffers
+allocated/freed, number of occurrences for specific events, etc.
+
+However, the resources consumed for library-level statistics counter collection
+have to be spent out of the application budget and the counters collected by
+some libraries might not be relevant to the current application. In order to
+avoid any unwanted waste of resources and/or performance impacts, the
+application should decide at build time whether the collection of library-level
+statistics counters should be turned on or off for each library individually.
+
+Library-level statistics counters can be relevant or not for specific
+applications:
+
+ * For Application A, counters maintained by Library X are always relevant and
+the application needs to use them to implement certain features, such as 
traffic
+accounting, logging, application-level statistics, etc. In this case,
+the application requires that collection of statistics counters for Library X 
is
+always turned on.
+
+ * For Application B, counters maintained by Library X are only useful during 
the
+application debug stage and are not relevant once debug phase is over. In this
+case, the application may decide to turn on the collection of Library X
+statistics counters during the debug phase and at a later stage turn them off.
+
+ * For Application C, counters maintained by Library X are not relevant at all.
+It might be that the application maintains its own set of statistics counters
+that monitor a different set of run-time events (e.g. number of connection
+requests, number of active users, etc). It might als

[dpdk-dev] [PATCH v2] doc: guidelines for library statistics

[Cristian Dumitrescu]

v3 changes
-fixed bullets for correct doc generation

v2 changes
-small text changes
-reordered sections to have guidelines at the top and motivation at the end
-broke lines at 80 characters

Signed-off-by: Cristian Dumitrescu 
---
 doc/guides/guidelines/index.rst  |1 +
 doc/guides/guidelines/statistics.rst |  104 ++
 2 files changed, 105 insertions(+), 0 deletions(-)
 create mode 100644 doc/guides/guidelines/statistics.rst

diff --git a/doc/guides/guidelines/index.rst b/doc/guides/guidelines/index.rst
index b2b0a92..c01f958 100644
--- a/doc/guides/guidelines/index.rst
+++ b/doc/guides/guidelines/index.rst
@@ -6,3 +6,4 @@ Guidelines
 :numbered:

 coding_style
+statistics
diff --git a/doc/guides/guidelines/statistics.rst 
b/doc/guides/guidelines/statistics.rst
new file mode 100644
index 000..bc91723
--- /dev/null
+++ b/doc/guides/guidelines/statistics.rst
@@ -0,0 +1,104 @@
+Library Statistics
+==
+
+Description
+---
+
+This document describes the guidelines for DPDK library-level statistics 
counter
+support. This includes guidelines for turning library statistics on and off and
+requirements for preventing ABI changes when implementing statistics.
+
+
+Mechanism to allow the application to turn library statistics on and off
+
+
+Each library that maintains statistics counters should provide a single build
+time flag that decides whether the statistics counter collection is enabled or
+not. This flag should be exposed as a variable within the DPDK configuration
+file. When this flag is set, all the counters supported by current library are
+collected for all the instances of every object type provided by the library.
+When this flag is cleared, none of the counters supported by the current 
library
+are collected for any instance of any object type provided by the library:
+
+.. code-block:: console
+
+   # DPDK file config/common_linuxapp, config/common_bsdapp, etc.
+   CONFIG_RTE__STATS_COLLECT=y/n
+
+The default value for this DPDK configuration file variable (either "yes" or
+"no") is decided by each library.
+
+
+Prevention of ABI changes due to library statistics support
+---
+
+The layout of data structures and prototype of functions that are part of the
+library API should not be affected by whether the collection of statistics
+counters is turned on or off for the current library. In practical terms, this
+means that space should always be allocated in the API data structures for
+statistics counters and the statistics related API functions are always built
+into the code, regardless of whether the statistics counter collection is 
turned
+on or off for the current library.
+
+When the collection of statistics counters for the current library is turned
+off, the counters retrieved through the statistics related API functions should
+have a default value of zero.
+
+
+Motivation to allow the application to turn library statistics on and off
+-
+
+It is highly recommended that each library provides statistics counters to 
allow
+an application to monitor the library-level run-time events. Typical counters
+are: number of packets received/dropped/transmitted, number of buffers
+allocated/freed, number of occurrences for specific events, etc.
+
+However, the resources consumed for library-level statistics counter collection
+have to be spent out of the application budget and the counters collected by
+some libraries might not be relevant to the current application. In order to
+avoid any unwanted waste of resources and/or performance impacts, the
+application should decide at build time whether the collection of library-level
+statistics counters should be turned on or off for each library individually.
+
+Library-level statistics counters can be relevant or not for specific
+applications:
+
+ * For Application A, counters maintained by Library X are always relevant and
+the application needs to use them to implement certain features, such as 
traffic
+accounting, logging, application-level statistics, etc. In this case,
+the application requires that collection of statistics counters for Library X 
is
+always turned on.
+
+ * For Application B, counters maintained by Library X are only useful during 
the
+application debug stage and are not relevant once debug phase is over. In this
+case, the application may decide to turn on the collection of Library X
+statistics counters during the debug phase and at a later stage turn them off.
+
+ * For Application C, counters maintained by Library X are not relevant at all.
+It might be that the application maintains its own set of statistics counters
+that monitor a different set of run-time events (e.g. number of connection
+requests, number of active users, etc). It might als

[dpdk-dev] [PATCH v4] doc: guidelines for library statistics

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cristian Dumitrescu
> Sent: Tuesday, June 16, 2015 2:36 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4] doc: guidelines for library statistics
> 
> v4 changes
> -more fixes for bullets
> 
> v3 changes
> -fixed bullets for correct doc generation
> 
> v2 changes
> -small text changes
> -reordered sections to have guidelines at the top and motivation at the
> end -broke lines at 80 characters
> 
> Signed-off-by: Cristian Dumitrescu 


Acked-by: John McNamara 

[dpdk-dev] [PATCH v3 00/10] Add a VXLAN sample

[Liu, Jijiang]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, June 16, 2015 9:32 PM
> To: Liu, Jijiang
> Cc: dev at dpdk.org; Zhang, Helin
> Subject: Re: [dpdk-dev] [PATCH v3 00/10] Add a VXLAN sample
> 
> 2015-06-16 12:49, Liu, Jijiang:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > Sorry, there are too many checkpatch errors to peacefully apply this 
> > > series.
> >
> > Dou you mean there are too many warnings or errors when using
> checkpatch.pl?
> >
> > If you meant warnings, yes, there are some warnings that I have not removed
> from patches.
> 
> Yes I mean warnings. Most of them should be removed.
> Please try to comply with the established coding style.
Thanks, I will fix these warnings in next version.

> > If you meant errors, I will double check.

[dpdk-dev] [PATCH v2] Add toeplitz hash algorithm used by RSS

[Bruce Richardson]

On Fri, May 08, 2015 at 10:58:12AM -0400, Vladimir Medvedkin wrote:
> Software implementation of the Toeplitz hash function used by RSS.
> Can be used either for packet distribution on single queue NIC
> or for simulating of RSS computation on specific NIC (for example
> after GRE header decapsulating).
> 
> v3 changes
> - Rework API to be more generic
> - Add sctp_tag into tuple
> 
> v2 changes
> - Add ipv6 support
> - Various style fixes
> 
> Signed-off-by: Vladimir Medvedkin 

Hi Vladimir,

first off, thanks for this patch, it looks like something we want into DPDK.
However, as Thomas has already pointed out, I think we could really do with
some unit tests for this code. As it stands right now, we don't even know if 
this
header compiles, as the header file is not used by any C file in DPDK.

Some other comments are inline below.

Regards,
/Bruce
> ---
>  lib/librte_hash/Makefile|   1 +
>  lib/librte_hash/rte_thash.h | 207 
> 
>  2 files changed, 208 insertions(+)
>  create mode 100644 lib/librte_hash/rte_thash.h
> 
> diff --git a/lib/librte_hash/Makefile b/lib/librte_hash/Makefile
> index 3696cb1..981230b 100644
> --- a/lib/librte_hash/Makefile
> +++ b/lib/librte_hash/Makefile
> @@ -49,6 +49,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_HASH) += rte_fbk_hash.c
>  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include := rte_hash.h
>  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_hash_crc.h
>  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_jhash.h
> +SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_thash.h
>  SYMLINK-$(CONFIG_RTE_LIBRTE_HASH)-include += rte_fbk_hash.h
>  
>  # this lib needs eal
> diff --git a/lib/librte_hash/rte_thash.h b/lib/librte_hash/rte_thash.h
> new file mode 100644
> index 000..5d5111b
> --- /dev/null
> +++ b/lib/librte_hash/rte_thash.h
> @@ -0,0 +1,207 @@
> +/*-
> + *   BSD LICENSE
> + *
> + *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.

Date and copyright owner look to need update here.

> + *   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.
> + * * Neither the name of Intel Corporation nor the names of its
> + *   contributors may be used to endorse or promote products derived
> + *   from this software without specific prior written permission.
> + *
> + *   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.
> + */
> +
> +#ifndef _RTE_THASH_H
> +#define _RTE_THASH_H
> +
> +/**
> + * @file
> + *
> + * toeplitz hash functions.
> + */
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> + * Software implementation of the Toeplitz hash function used by RSS.
> + * Can be used either for packet distribution on single queue NIC
> + * or for simulating of RSS computation on specific NIC (for example
> + * after GRE header decapsulating)
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#ifdef __SSE3__
> +static const __m128i bswap_mask = {0x0405060700010203, 0x0C0D0E0F08090A0B};
> +#endif

I think a more descriptive name for this might help. Yes, it's a mask for
byteswapping, but I think the name could do with being more descriptive. I see
below it's used for IPv6 IP extraction, so maybe that could be put in the name
somehow. A comment should also be added on what it is used for.
Finally, since this is a public symbol in the including C file, it should have
an rte_ prefix - or perhaps just an underscore prefix "_".

> +
> +#define RTE_THASH_V4_L3   2  /*calculate hash of ipv4 header only*/
> +#define RTE_THASH_V4_L4   3  /*calculate hash of ipv4 + transport 
> headers*/
> +#define RTE_THASH_V6_L3   8  /*calculate hash of ipv6 header only */
> +#define RTE_THASH_V6_L4   

[dpdk-dev] [PATCH v3 00/10] Add a VXLAN sample

[Liu, Jijiang]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, June 16, 2015 5:01 PM
> To: Liu, Jijiang
> Cc: dev at dpdk.org; Zhang, Helin
> Subject: Re: [dpdk-dev] [PATCH v3 00/10] Add a VXLAN sample
> 
> > Acked-by: Helin Zhang 
> 
> Sorry, there are too many checkpatch errors to peacefully apply this series.


Dou you mean there are too many warnings or errors when using checkpatch.pl?

If you meant warnings, yes, there are some warnings that I have not removed 
from patches.

If you meant errors, I will double check.

[dpdk-dev] [PATCH v2 2/3] fm10k: add MAC filter

[Qiu, Michael]

On 6/15/2015 9:25 AM, He, Shaopeng wrote:
> MAC filter function was newly added, each PF and VF can have up to 64 MAC
> addresses. VF filter needs support from PF host, which is not available now.
>
> Signed-off-by: Shaopeng He 

[.../...]

> @@ -820,6 +821,7 @@ static int
>  fm10k_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
>  {
>   s32 result;
> + uint16_t mac_num = 0;
>   uint32_t vid_idx, vid_bit, mac_index;
>   struct fm10k_hw *hw;
>   struct fm10k_macvlan_filter_info *macvlan;
> @@ -863,11 +865,17 @@ fm10k_vlan_filter_set(struct rte_eth_dev *dev, uint16_t 
> vlan_id, int on)
>   mac_index++) {
>   if (is_zero_ether_addr(&data->mac_addrs[mac_index]))
>   continue;
> + if (mac_num > macvlan->mac_num - 1) {
> + PMD_INIT_LOG(ERR, "MAC address number "
> + "not match");

It's  so strange why so many indentations here.

> + break;
> + }
>   fm10k_mbx_lock(hw);
>   result = fm10k_update_uc_addr(hw, hw->mac.dglort_map,
>   data->mac_addrs[mac_index].addr_bytes,
>   vlan_id, on, 0);
>   fm10k_mbx_unlock(hw);
> + mac_num++;
>   }
>   if (result != FM10K_SUCCESS) {
>   PMD_INIT_LOG(ERR, "MAC address update failed: %d", result);
> @@ -884,6 +892,72 @@ fm10k_vlan_filter_set(struct rte_eth_dev *dev, uint16_t 
> vlan_id, int on)
>   return 0;
>  }
>  
> +/* Add/Remove a MAC address, and update filters */
> +static void
> +fm10k_MAC_filter_set(struct rte_eth_dev *dev, const u8 *mac, bool add)
> +{
> + uint32_t i, j, k;
> + struct fm10k_hw *hw;
> + struct fm10k_macvlan_filter_info *macvlan;
> +
> + hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + macvlan = FM10K_DEV_PRIVATE_TO_MACVLAN(dev->data->dev_private);
> +
> + /* @todo - add support for the VF */
> + if (hw->mac.type != fm10k_mac_pf) {
> + PMD_INIT_LOG(ERR, "MAC filter not available on VF");
> + return;
> + }
> +
> + i = 0;
> + for (j = 0; j < FM10K_VFTA_SIZE; j++) {
> + if (macvlan->vfta[j]) {
> + for (k = 0; k < FM10K_UINT32_BIT_SIZE; k++) {
> + if (macvlan->vfta[j] & (1 << k)) {
> + if (i + 1 > macvlan->vlan_num) {
> + PMD_INIT_LOG(ERR, "vlan number "
> + "not match");
> + return;
> + }
> + fm10k_mbx_lock(hw);
> + fm10k_update_uc_addr(hw,
> + hw->mac.dglort_map, mac,
> + j * FM10K_UINT32_BIT_SIZE + k,
> + add, 0);
> + fm10k_mbx_unlock(hw);
> + i++;
> + }
> + }
> + }
> + }
> +
> + if (add)
> + macvlan->mac_num++;
> + else
> + macvlan->mac_num--;
> +}
> +
> +/* Add a MAC address, and update filters */
> +static void
> +fm10k_macaddr_add(struct rte_eth_dev *dev,
> +  struct ether_addr *mac_addr,
> +  __rte_unused uint32_t index,
> +  __rte_unused uint32_t pool)
> +{
> + fm10k_MAC_filter_set(dev, mac_addr->addr_bytes, TRUE);
> +}
> +
> +/* Remove a MAC address, and update filters */
> +static void
> +fm10k_macaddr_remove(struct rte_eth_dev *dev, uint32_t index)
> +{
> + struct rte_eth_dev_data *data = dev->data;
> +
> + if (index < FM10K_MAX_MACADDR_NUM)
> + fm10k_MAC_filter_set(dev, data->mac_addrs[index].addr_bytes,
> + FALSE);
> +}
> +
>  static inline int
>  check_nb_desc(uint16_t min, uint16_t max, uint16_t mult, uint16_t request)
>  {
> @@ -1736,6 +1810,8 @@ static const struct eth_dev_ops fm10k_eth_dev_ops = {
>   .link_update= fm10k_link_update,
>   .dev_infos_get  = fm10k_dev_infos_get,
>   .vlan_filter_set= fm10k_vlan_filter_set,
> + .mac_addr_add   = fm10k_macaddr_add,
> + .mac_addr_remove= fm10k_macaddr_remove,
>   .rx_queue_start = fm10k_dev_rx_queue_start,
>   .rx_queue_stop  = fm10k_dev_rx_queue_stop,
>   .tx_queue_start = fm10k_dev_tx_queue_start,
> @@ -1817,7 +1893,8 @@ eth_fm10k_dev_init(struct rte_eth_dev *dev)
>   }
>  
>   /* Initialize MAC address(es) */
> - dev->data->mac_addrs = rte_zmalloc("fm10k", ETHER_ADDR_LEN, 0);
> + dev->data->mac_addrs = rte_zmalloc("fm10k",
> + ETHER_ADDR_LEN * FM1

[dpdk-dev] Debugging SR-IOV related packet flow problem with DPDK

[Anjali Kulkarni]

Hi,

I am observing that the SR-IOV enabled NIC does not increment any VF packet 
counters despite incoming packet flow. I have enabled some debug logs like 
CONFIG_RTE_LIBRTE_IXGBE_DEBUG_RX in config file.
Can someone point me to where these logs are being printed so I can try to 
figure out where packets are being dropped? Or how can I debug DPDK packet flow 
related issues (are there any stats I can look at)?

Thanks
Anjali

[dpdk-dev] [PATCH v3 2/2] virtio: check vq parameter

[Bernard Iremonger]

If vq is NULL, there is a segmentation fault.

Signed-off-by: Bernard Iremonger 
---
 drivers/net/virtio/virtqueue.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/virtio/virtqueue.c b/drivers/net/virtio/virtqueue.c
index 8a3005f..7f60e3e 100644
--- a/drivers/net/virtio/virtqueue.c
+++ b/drivers/net/virtio/virtqueue.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -60,11 +60,13 @@ virtqueue_detatch_unused(struct virtqueue *vq)
struct rte_mbuf *cookie;
int idx;

-   for (idx = 0; idx < vq->vq_nentries; idx++) {
-   if ((cookie = vq->vq_descx[idx].cookie) != NULL) {
-   vq->vq_descx[idx].cookie = NULL;
-   return cookie;
+   if (vq != NULL)
+   for (idx = 0; idx < vq->vq_nentries; idx++) {
+   cookie = vq->vq_descx[idx].cookie;
+   if (cookie != NULL) {
+   vq->vq_descx[idx].cookie = NULL;
+   return cookie;
+   }
}
-   }
return NULL;
 }
-- 
1.7.4.1

[dpdk-dev] [PATCH v3 1/2] virtio: add support for PCI Port Hotplug

[Bernard Iremonger]

This patch depends on the Port Hotplug Framework.
It implements the eth_dev_uninit_t() function for virtio pmd.

Signed-off-by: Bernard Iremonger 
---
 drivers/net/virtio/virtio_ethdev.c |   83 +---
 1 files changed, 76 insertions(+), 7 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index fe5f9a1..cb35220 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -51,6 +51,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -63,6 +64,7 @@


 static int eth_virtio_dev_init(struct rte_eth_dev *eth_dev);
+static int eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev);
 static int  virtio_dev_configure(struct rte_eth_dev *dev);
 static int  virtio_dev_start(struct rte_eth_dev *dev);
 static void virtio_dev_stop(struct rte_eth_dev *dev);
@@ -324,8 +326,12 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
mz = rte_memzone_reserve_aligned(vq_name, vq->vq_ring_size,
socket_id, 0, VIRTIO_PCI_VRING_ALIGN);
if (mz == NULL) {
-   rte_free(vq);
-   return -ENOMEM;
+   if (rte_errno == EEXIST)
+   mz = rte_memzone_lookup(vq_name);
+   if (mz == NULL) {
+   rte_free(vq);
+   return -ENOMEM;
+   }
}

/*
@@ -358,8 +364,13 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
vq_size * hw->vtnet_hdr_size,
socket_id, 0, RTE_CACHE_LINE_SIZE);
if (vq->virtio_net_hdr_mz == NULL) {
-   rte_free(vq);
-   return -ENOMEM;
+   if (rte_errno == EEXIST)
+   vq->virtio_net_hdr_mz =
+   rte_memzone_lookup(vq_name);
+   if (vq->virtio_net_hdr_mz == NULL) {
+   rte_free(vq);
+   return -ENOMEM;
+   }
}
vq->virtio_net_hdr_mem =
vq->virtio_net_hdr_mz->phys_addr;
@@ -372,8 +383,13 @@ int virtio_dev_queue_setup(struct rte_eth_dev *dev,
vq->virtio_net_hdr_mz = rte_memzone_reserve_aligned(vq_name,
PAGE_SIZE, socket_id, 0, RTE_CACHE_LINE_SIZE);
if (vq->virtio_net_hdr_mz == NULL) {
-   rte_free(vq);
-   return -ENOMEM;
+   if (rte_errno == EEXIST)
+   vq->virtio_net_hdr_mz =
+   rte_memzone_lookup(vq_name);
+   if (vq->virtio_net_hdr_mz == NULL) {
+   rte_free(vq);
+   return -ENOMEM;
+   }
}
vq->virtio_net_hdr_mem =
vq->virtio_net_hdr_mz->phys_addr;
@@ -1250,12 +1266,63 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
return 0;
 }

+static int
+eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
+{
+   struct rte_pci_device *pci_dev;
+   struct virtio_hw *hw = eth_dev->data->dev_private;
+   unsigned int i;
+
+   PMD_INIT_FUNC_TRACE();
+
+   if (rte_eal_process_type() == RTE_PROC_SECONDARY)
+   return -EPERM;
+
+   if (hw->started == 1) {
+   virtio_dev_stop(eth_dev);
+   virtio_dev_close(eth_dev);
+   }
+   pci_dev = eth_dev->pci_dev;
+
+   eth_dev->dev_ops = NULL;
+   eth_dev->tx_pkt_burst = NULL;
+   eth_dev->rx_pkt_burst = NULL;
+
+   rte_free(hw->cvq);
+   hw->cvq = NULL;
+
+   for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
+   rte_free(eth_dev->data->rx_queues[i]);
+   eth_dev->data->rx_queues[i] = NULL;
+   }
+
+   for (i = 0; i < eth_dev->data->nb_tx_queues; i++) {
+   rte_free(eth_dev->data->tx_queues[i]);
+   eth_dev->data->tx_queues[i] = NULL;
+   }
+
+   rte_free(eth_dev->data->mac_addrs);
+   eth_dev->data->mac_addrs = NULL;
+
+   /* reset interrupt callback  */
+   if (pci_dev->driver->drv_flags & RTE_PCI_DRV_INTR_LSC)
+   rte_intr_callback_unregister(&pci_dev->intr_handle,
+   virtio_interrupt_handler,
+   eth_dev);
+
+   PMD_INIT_LOG(DEBUG, "dev_uninit completed");
+
+   return 0;
+}
+
 static struct eth_driver rte_virtio_pmd = {
.pci_drv = {
.name = "rte_virtio_pmd",
  

[dpdk-dev] [PATCH v2 0/2] virtio: PCI Port Hotplug

[Bernard Iremonger]

This patchset contains changes to add support for
PCI port hotplug.
It  also contains a fix to virtqueuq_detach_unused().

Bernard Iremonger (2):
  virtio: add support for PCI Port Hotplug
  virtio: check vq parameter

 drivers/net/virtio/virtio_ethdev.c |   83 +---
 drivers/net/virtio/virtqueue.c |   14 +++---
 2 files changed, 84 insertions(+), 13 deletions(-)

-- 
1.7.4.1

[dpdk-dev] [PATCH v2 0/3] fm10k: Add promiscuous mode support

[Qiu, Michael]

Tested-by: Michael Qiu 

- OS: Fedora20  3.11.10-301
- GCC: gcc version 4.8.3 2014911
- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
- NIC: Ethernet controller: Intel Corporation Device 15a4 (rev 01)
- Default x86_64-native-linuxapp-gcc configuration

Test Case: Set promiscuous mode off
Test Case: Set promiscuous mode on

On 6/12/2015 3:07 PM, Chen, Jing D wrote:
> From: "Chen Jing D(Mark)" 
>
> v2:
>   Add debug messages in allmulticast enable/disable functions.
>
> The patch set add promiscuous mode configuration and 2 bug fixes.
>
> Chen Jing D(Mark) (3):
>   fm10k: Add promiscuous mode support
>   fm10k: remove mbuf size sanity check
>   fm10k: Fix improper max queue number for VF
>
>  drivers/net/fm10k/fm10k_ethdev.c |  133 +++--
>  1 files changed, 125 insertions(+), 8 deletions(-)
>

[dpdk-dev] [PATCH v6 00/10] update jhash function

[Thomas Monjalon]

2015-06-12 11:37, Bruce Richardson:
> On Wed, Jun 10, 2015 at 04:25:17PM +0100, Pablo de Lara wrote:
> > Jenkins hash function was developed originally in 1996,
> > and was integrated in first versions of DPDK.
> > The function has been improved in 2006,
> > achieving up to 35% better performance, compared to the original one.
> > 
> > This patchset updates the current jhash in DPDK,
> > including two new functions that generate two hashes from a single key.
> > 
> > It also separates the existing hash function performance tests to
> > another file, to make it quicker to run, and add new unit tests.
> > 
> > changes in v6:
> > - Use RTE_DIM macro, so it saves lines of code
> > - Correct mistaken performance improvement
> > - Add deprecated attribute, instead of printing a message calling it
> > - Add note stating the changes in release notes
> > 
> > changes in v5:
> > - Add functional tests (mainly to test that all functions 
> >   return the expected hash values)
> > - Modify range of key sizes to test
> > - Change order of output for perf tests, so it is clearer
> >   to compare different hash functions for same key size/initial value
> > - Add new initial value to test in the hash functions
> > - Fix some errors caught by checkpatch
> >  
> > changes in v4:
> > - Simplify key alignment checks
> > - Include missing x86 arch check
> > 
> > changes in v3:
> > 
> > - Update rte_jhash_1word, rte_jhash_2words and rte_jhash_3words
> >   functions
> > 
> > changes in v2:
> > 
> > - Split single commit in three commits, one that updates the existing 
> > functions
> >   and another that adds two new functions and use one of those functions
> >   as a base to be called by the other ones.
> > - Remove some unnecessary ifdefs in the code.
> > - Add new macros to help on the reutilization of constants
> > - Separate hash function performance tests to another file
> >   and improve cycle measurements.
> > - Rename existing function rte_jhash2 to rte_jhash_32b
> >   (something more meaninful) and mark rte_jhash2 as
> >   deprecated
> >
> Thanks for the all the work, and rework, Pablo.
> 
> Series Acked-by: Bruce Richardson 

Applied, thanks
Some doxygen typos has been fixed on the fly.

[dpdk-dev] [PATCH v2 0/3] fm10k: Add promiscuous mode support

[Qiu, Michael]

On 6/12/2015 3:07 PM, Chen, Jing D wrote:
> From: "Chen Jing D(Mark)" 
>
> v2:
>   Add debug messages in allmulticast enable/disable functions.
>
> The patch set add promiscuous mode configuration and 2 bug fixes.
>
> Chen Jing D(Mark) (3):
>   fm10k: Add promiscuous mode support
>   fm10k: remove mbuf size sanity check
>   fm10k: Fix improper max queue number for VF
>
>  drivers/net/fm10k/fm10k_ethdev.c |  133 +++--
>  1 files changed, 125 insertions(+), 8 deletions(-)
>
Acked-by: Michael Qiu 

[dpdk-dev] [PATCH 5/6] fm10k: Do sanity check on mac address

[Qiu, Michael]

Tested-by: Michael Qiu 

- OS: Fedora20  3.11.10-301
- GCC: gcc version 4.8.3 2014911
- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
- NIC: Ethernet controller: Intel Corporation Device 15a4 (rev 01)
- Default x86_64-native-linuxapp-gcc configuration


On 5/29/2015 4:11 PM, Chen, Jing D wrote:
> From: "Chen Jing D(Mark)" 
>
> After acquiring MAC address from HW, it's necessary to validate
> MAC address before use.
>
> Signed-off-by: Chen Jing D(Mark) 
> ---
>  drivers/net/fm10k/fm10k_ethdev.c |   24 ++--
>  1 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c 
> b/drivers/net/fm10k/fm10k_ethdev.c
> index dedfbb4..b6e82e3 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -1756,24 +1756,20 @@ eth_fm10k_dev_init(struct rte_eth_dev *dev)
>   }
>  
>   diag = fm10k_read_mac_addr(hw);
> - if (diag != FM10K_SUCCESS) {
> - /*
> -  * TODO: remove special handling on VF. Need shared code to
> -  * fix first.
> -  */
> - if (hw->mac.type == fm10k_mac_pf) {
> - PMD_INIT_LOG(ERR, "Read MAC addr failed: %d", diag);
> - return -EIO;
> - } else {
> - /* Generate a random addr */
> - eth_random_addr(hw->mac.addr);
> - memcpy(hw->mac.perm_addr, hw->mac.addr, ETH_ALEN);
> - }
> - }
>  
>   ether_addr_copy((const struct ether_addr *)hw->mac.addr,
>   &dev->data->mac_addrs[0]);
>  
> + if (diag != FM10K_SUCCESS ||
> + !is_valid_assigned_ether_addr(dev->data->mac_addrs)) {
> +
> + /* Generate a random addr */
> + eth_random_addr(hw->mac.addr);
> + memcpy(hw->mac.perm_addr, hw->mac.addr, ETH_ALEN);
> + ether_addr_copy((const struct ether_addr *)hw->mac.addr,
> + &dev->data->mac_addrs[0]);
> + }
> +
>   /* Reset the hw statistics */
>   fm10k_stats_reset(dev);
>  

[dpdk-dev] [PATCH 3/6] fm10k: Fix data integrity issue with multi-segment frame

[Qiu, Michael]

Tested-by: Michael Qiu 

- OS: Fedora20  3.11.10-301
- GCC: gcc version 4.8.3 2014911
- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
- NIC: Ethernet controller: Intel Corporation Device 15a4 (rev 01)
- Default x86_64-native-linuxapp-gcc configuration

- Total 5 cases, 5 passed, 0 failed

- Case: Normal frames with no jumbo frame support
- Case: Jumbo frames with no jumbo frame support
- Case: Normal frames with jumbo frame support
- Case: Jumbo frames with jumbo frame support
- Case: Frames bigger than jumbo frames, wwith jumbo frame support


On 5/29/2015 4:11 PM, Chen, Jing D wrote:
> From: "Chen Jing D(Mark)" 
>
> In TX side, bit FM10K_TXD_FLAG_LAST in TX descriptor only is set
> in the last descriptor for multi-segment packets. But current
> implementation didn't set all the fields of TX descriptor, which
> will cause descriptors processed now to re-use fields set in last
> scroll. If FM10K_TXD_FLAG_LAST bit was set in the last round and
> it happened this is not the last descriptor of a multi-segnment
> packet, HW will send out the incomplete packet out and leads to
> data intergrity issue.
>
> Signed-off-by: Chen Jing D(Mark) 
> ---
>  drivers/net/fm10k/fm10k_rxtx.c |   15 +--
>  1 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
> index 56df6cd..f5d1ad0 100644
> --- a/drivers/net/fm10k/fm10k_rxtx.c
> +++ b/drivers/net/fm10k/fm10k_rxtx.c
> @@ -402,9 +402,9 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, 
> struct rte_mbuf *mb)
>   q->nb_used = q->nb_used + mb->nb_segs;
>   }
>  
> - q->hw_ring[last_id].flags = flags;
>   q->nb_free -= mb->nb_segs;
>  
> + q->hw_ring[q->next_free].flags = 0;
>   /* set checksum flags on first descriptor of packet. SCTP checksum
>* offload is not supported, but we do not explicitly check for this
>* case in favor of greatly simplified processing. */
> @@ -415,16 +415,27 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue 
> *q, struct rte_mbuf *mb)
>   if (mb->ol_flags & PKT_TX_VLAN_PKT)
>   q->hw_ring[q->next_free].vlan = mb->vlan_tci;
>  
> + q->sw_ring[q->next_free] = mb;
> + q->hw_ring[q->next_free].buffer_addr =
> + rte_cpu_to_le_64(MBUF_DMA_ADDR(mb));
> + q->hw_ring[q->next_free].buflen =
> + rte_cpu_to_le_16(rte_pktmbuf_data_len(mb));
> + if (++q->next_free == q->nb_desc)
> + q->next_free = 0;
> +
>   /* fill up the rings */
> - for (; mb != NULL; mb = mb->next) {
> + for (mb = mb->next; mb != NULL; mb = mb->next) {
>   q->sw_ring[q->next_free] = mb;
>   q->hw_ring[q->next_free].buffer_addr =
>   rte_cpu_to_le_64(MBUF_DMA_ADDR(mb));
>   q->hw_ring[q->next_free].buflen =
>   rte_cpu_to_le_16(rte_pktmbuf_data_len(mb));
> + q->hw_ring[q->next_free].flags = 0;
>   if (++q->next_free == q->nb_desc)
>   q->next_free = 0;
>   }
> +
> + q->hw_ring[last_id].flags = flags;
>  }
>  
>  uint16_t

[dpdk-dev] doxygen warnings in QoS API

[Thomas Monjalon]

Hi,

There are many errors when generating doxygen documentation.
It would be good to remove them for the release 2.1.

Cristian, please, could you help to clean the QoS API comments?
Half of the warnings come from rte_sched and rte_meter:
make doc-api-html 2>&1 | grep 'rte_\(meter\|sched\).*warning:'

Thanks

[dpdk-dev] [PATCH 1/6] fm10k: Fix improper RX buffer size assignment

[Qiu, Michael]

Tested-by: Michael Qiu 

- OS: Fedora20  3.11.10-301
- GCC: gcc version 4.8.3 2014911
- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
- NIC: Ethernet controller: Intel Corporation Device 15a4 (rev 01)
- Default x86_64-native-linuxapp-gcc configuration


On 5/29/2015 4:11 PM, Chen, Jing D wrote:
> From: "Chen Jing D(Mark)" 
>
> As RX buffer is aligned to 512B within mbuf, some bytes are reserved
> for this purpose, and the worst case could be 511B. But SRR reg
> assumes all buffers have the same size. In order to fill the gap,
> we'll have to consider the worsst case and assume 512B is reserved.
> If we don't do so, it's possible for HW to overwrite data to next
> mbuf.
>
> Signed-off-by: Chen Jing D(Mark) 
> ---
>  drivers/net/fm10k/fm10k.h|5 +++--
>  drivers/net/fm10k/fm10k_ethdev.c |   12 ++--
>  2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/fm10k/fm10k.h b/drivers/net/fm10k/fm10k.h
> index 0e31796..ad7a7d1 100644
> --- a/drivers/net/fm10k/fm10k.h
> +++ b/drivers/net/fm10k/fm10k.h
> @@ -191,7 +191,8 @@ struct fm10k_tx_queue {
>  
>  /* enforce 512B alignment on default Rx DMA addresses */
>  #define MBUF_DMA_ADDR_DEFAULT(mb) \
> - ((uint64_t) RTE_ALIGN(((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM), 512))
> + ((uint64_t) RTE_ALIGN(((mb)->buf_physaddr + RTE_PKTMBUF_HEADROOM),\
> + FM10K_RX_DATABUF_ALIGN))
>  
>  static inline void fifo_reset(struct fifo *fifo, uint32_t len)
>  {
> @@ -263,7 +264,7 @@ fm10k_addr_alignment_valid(struct rte_mbuf *mb)
>   uint64_t boundary1, boundary2;
>  
>   /* 512B aligned? */
> - if (RTE_ALIGN(addr, 512) == addr)
> + if (RTE_ALIGN(addr, FM10K_RX_DATABUF_ALIGN) == addr)
>   return 1;
>  
>   /* 8B aligned, and max Ethernet frame would not cross a 4KB boundary? */
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c 
> b/drivers/net/fm10k/fm10k_ethdev.c
> index 275c19c..a5e09a0 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -41,7 +41,6 @@
>  #include "fm10k.h"
>  #include "base/fm10k_api.h"
>  
> -#define FM10K_RX_BUFF_ALIGN 512
>  /* Default delay to acquire mailbox lock */
>  #define FM10K_MBXLOCK_DELAY_US 20
>  #define UINT64_LOWER_32BITS_MASK 0xULL
> @@ -426,6 +425,15 @@ fm10k_dev_rx_init(struct rte_eth_dev *dev)
>   /* Configure the Rx buffer size for one buff without split */
>   buf_size = (uint16_t)(rte_pktmbuf_data_room_size(rxq->mp) -
>   RTE_PKTMBUF_HEADROOM);
> + /* As RX buffer is aligned to 512B within mbuf, some bytes are
> +  * reserved for this purpose, and the worst case could be 511B.
> +  * But SRR reg assumes all buffers have the same size. In order
> +  * to fill the gap, we'll have to consider the worst case and
> +  * assume 512B is reserved. If we don't do so, it's possible
> +  * for HW to overwrite data to next mbuf.
> +  */
> + buf_size -= FM10K_RX_DATABUF_ALIGN;
> +
>   FM10K_WRITE_REG(hw, FM10K_SRRCTL(i),
>   buf_size >> FM10K_SRRCTL_BSIZEPKT_SHIFT);
>  
> @@ -909,7 +917,7 @@ mempool_element_size_valid(struct rte_mempool *mp)
>   RTE_PKTMBUF_HEADROOM;
>  
>   /* account for up to 512B of alignment */
> - min_size -= FM10K_RX_BUFF_ALIGN;
> + min_size -= FM10K_RX_DATABUF_ALIGN;
>  
>   /* sanity check for overflow */
>   if (min_size > mp->elt_size)

[dpdk-dev] [PATCH v2] fm10k: fix PF/VF MAC address register and clean up bug

[Qiu, Michael]

Tested-by: Michael Qiu 

- OS: Fedora20  3.11.10-301
- GCC: gcc version 4.8.3 2014911
- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
- NIC: Ethernet controller: Intel Corporation Device 15a4 (rev 01)
- Default x86_64-native-linuxapp-gcc configuration
- Total 1 cases, 1 passed, 0 failed


On 6/15/2015 9:26 AM, He, Shaopeng wrote:
> v2 changes:
>  - rebase this patch onto the HEAD
>  - add more description for this patch
>
> This patch includes 3 changes related to MAC/VLAN address table
> when the system(e.g. testpmd) is started and closed:
>  - remove default MAC address with fixed VLAN 0 which was for the
>debug purpose before the MAC/VLAN filter function was implemented.
>  - enable VF MAC/VLAN filter for the first valid MAC address
>and first valid VLAN ID. This is needed for system(e.g. testpmd)
>to setup default MAC address and default VLAN for VF.
>Later attempt to change these default value will be refused by
>under layer shared code and PF host functions.
>  - un-register any combination of VLAN and MAC address from fm10k
>switch side MAC table when the system(e.g. testpmd) is closed.
>
> Signed-off-by: Shaopeng He 
> ---
>  drivers/net/fm10k/fm10k_ethdev.c | 42 
> ++--
>  1 file changed, 23 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c 
> b/drivers/net/fm10k/fm10k_ethdev.c
> index 802a930..625fd31 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -58,6 +58,8 @@ static int
>  fm10k_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on);
>  static void
>  fm10k_MAC_filter_set(struct rte_eth_dev *dev, const u8 *mac, bool add);
> +static void
> +fm10k_MACVLAN_remove_all(struct rte_eth_dev *dev);
>  
>  static void
>  fm10k_mbx_initlock(struct fm10k_hw *hw)
> @@ -703,6 +705,8 @@ fm10k_dev_close(struct rte_eth_dev *dev)
>  
>   PMD_INIT_FUNC_TRACE();
>  
> + fm10k_MACVLAN_remove_all(dev);
> +
>   /* Stop mailbox service first */
>   fm10k_close_mbx_service(hw);
>   fm10k_dev_stop(dev);
> @@ -832,12 +836,6 @@ fm10k_vlan_filter_set(struct rte_eth_dev *dev, uint16_t 
> vlan_id, int on)
>   hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>   macvlan = FM10K_DEV_PRIVATE_TO_MACVLAN(dev->data->dev_private);
>  
> - /* @todo - add support for the VF */
> - if (hw->mac.type != fm10k_mac_pf) {
> - PMD_INIT_LOG(ERR, "VLAN filter not available on VF");
> - return -ENOTSUP;
> - }
> -
>   if (vlan_id > ETH_VLAN_ID_MAX) {
>   PMD_INIT_LOG(ERR, "Invalid vlan_id: must be < 4096");
>   return (-EINVAL);
> @@ -926,12 +924,6 @@ fm10k_MAC_filter_set(struct rte_eth_dev *dev, const u8 
> *mac, bool add)
>   hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>   macvlan = FM10K_DEV_PRIVATE_TO_MACVLAN(dev->data->dev_private);
>  
> - /* @todo - add support for the VF */
> - if (hw->mac.type != fm10k_mac_pf) {
> - PMD_INIT_LOG(ERR, "MAC filter not available on VF");
> - return;
> - }
> -
>   i = 0;
>   for (j = 0; j < FM10K_VFTA_SIZE; j++) {
>   if (macvlan->vfta[j]) {
> @@ -981,6 +973,25 @@ fm10k_macaddr_remove(struct rte_eth_dev *dev, uint32_t 
> index)
>   FALSE);
>  }
>  
> +/* Remove all VLAN and MAC address table entries */
> +static void
> +fm10k_MACVLAN_remove_all(struct rte_eth_dev *dev)
> +{
> + uint32_t j, k;
> + struct fm10k_macvlan_filter_info *macvlan;
> +
> + macvlan = FM10K_DEV_PRIVATE_TO_MACVLAN(dev->data->dev_private);
> + for (j = 0; j < FM10K_VFTA_SIZE; j++) {
> + if (macvlan->vfta[j]) {
> + for (k = 0; k < FM10K_UINT32_BIT_SIZE; k++) {
> + if (macvlan->vfta[j] & (1 << k))
> + fm10k_vlan_filter_set(dev,
> + j * FM10K_UINT32_BIT_SIZE + k, 
> false);
> + }
> + }
> + }
> +}
> +
>  static inline int
>  check_nb_desc(uint16_t min, uint16_t max, uint16_t mult, uint16_t request)
>  {
> @@ -2008,13 +2019,6 @@ eth_fm10k_dev_init(struct rte_eth_dev *dev)
>   /* Enable port first */
>   hw->mac.ops.update_lport_state(hw, hw->mac.dglort_map, 1, 1);
>  
> - /*
> -  * Add default mac. glort is assigned by SM for PF, while is
> -  * unused for VF. PF will assign correct glort for VF.
> -  */
> - hw->mac.ops.update_uc_addr(hw, hw->mac.dglort_map, hw->mac.addr,
> - 0, 1, 0);
> -
>   /* Set unicast mode by default. App can change to other mode in other
>* API func.
>*/

[dpdk-dev] [PATCH] doc: update port attach and detach in Testpmd Runtime Functions chapter

[Tetsuya Mukawa]

On 2015/06/11 23:33, Bernard Iremonger wrote:
> Signed-off-by: Bernard Iremonger 
> ---
>  doc/guides/testpmd_app_ug/testpmd_funcs.rst |   96 
> +++
>  1 files changed, 82 insertions(+), 14 deletions(-)
>
> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> index 761172e..fef3ceb 100644
> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> @@ -1,5 +1,5 @@
>  ..  BSD LICENSE
> -Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
> +Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
>  All rights reserved.
>  
>  Redistribution and use in source and binary forms, with or without
> @@ -866,31 +866,61 @@ Attach a port specified by pci address or virtual 
> device args.
>  To attach a new pci device, the device should be recognized by kernel first.
>  Then it should be moved under DPDK management.
>  Finally the port can be attached to testpmd.
> -On the other hand, to attach a port created by virtual device, above steps 
> are not needed.
> +
> +For example, to move a pci device using ixgbe under DPDK management:
> +
> +.. code-block:: console
> +
> +./tools/dpdk_nic_bind.py --status
> +
> +Network devices using DPDK-compatible driver
> +
> +
> +
> +Network devices using kernel driver
> +===
> +:0a:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' if=eth2 
> drv=ixgbe unused=
> +
> +./tools/dpdk_nic_bind.py -b igb_uio :0a:00.0
> +./tools/dpdk_nic_bind.py --status
> +
> +Network devices using DPDK-compatible driver
> +
> +:0a:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' 
> drv=igb_uio unused=
> +
> +To attach a port created by virtual device, above steps are not needed.
>  
>  port attach (identifier)
>  
> -For example, to attach a port whose pci address is :02:00.0.
> +For example, to attach a port whose pci address is :0a:00.0.
>  
>  .. code-block:: console
>  
> -testpmd> port attach :02:00.0
> +testpmd> port attach :0a:00.0
>  Attaching a new port...
> -... snip ...
> +EAL: PCI device :0a:00.0 on NUMA socket -1
> +EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
> +EAL:   PCI memory mapped at 0x7f83bfa0
> +EAL:   PCI memory mapped at 0x7f83bfa8
> +PMD: eth_ixgbe_dev_init(): MAC: 2, PHY: 18, SFP+: 5
> +PMD: eth_ixgbe_dev_init(): port 0 vendorID=0x8086 deviceID=0x10fb
>  Port 0 is attached. Now total ports is 1
>  Done
> +testpmd>
>  
>  For example, to attach a port created by pcap PMD.
>  
>  .. code-block:: console
>  
> -testpmd> port attach eth_pcap0,iface=eth0
> +testpmd> port attach eth_pcap0
>  Attaching a new port...
> -... snip ...
> +PMD: Initializing pmd_pcap for eth_pcap0
> +PMD: Creating pcap-backed ethdev on numa socket 0
>  Port 0 is attached. Now total ports is 1
>  Done
> +testpmd>
>  
> -In this case, identifier is "eth_pcap0,iface=eth0".
> +In this case, identifier is "eth_pcap0".
>  This identifier format is the same as "--vdev" format of DPDK applications.
>  
>  port detach
> @@ -899,21 +929,59 @@ port detach
>  Detach a specific port.
>  
>  Before detaching a port, the port should be closed.
> -Also to remove a pci device completely from the system, first detach the 
> port from testpmd.
> -Then the device should be moved under kernel management.
> -Finally the device can be removed using kernel pci hotplug functionality.
> -On the other hand, to remove a port created by a virtual device, above steps 
> are not needed.
>  
>  port detach (port_id)
>  
> -For example, to detach a port 0.
> +For example, to detach a pci device port 0.
> +
> +.. code-block:: console
> +
> +testpmd> port close 0
> +Closing ports...
> +Done
> +testpmd> port detach 0
> +Detaching a port...
> +EAL: PCI device :0a:00.0 on NUMA socket -1
> +EAL:   remove driver: 8086:10fb rte_ixgbe_pmd
> +EAL:   PCI memory unmapped at 0x7f83bfa0
> +EAL:   PCI memory unmapped at 0x7f83bfa8
> +Done
> +testpmd>
> +
> +For example, to detach a virtual device port 0.
>  
>  .. code-block:: console
>  
> +testpmd> port close 0
> +Closing ports...
> +Done
>  testpmd> port detach 0
>  Detaching a port...
> -... snip ...
> +PMD: Closing pcap ethdev on numa socket 0
> +Port 'eth_pcap0' is detached. Now total ports is 0
>  Done
> +testpmd>
> +
> +To remove a pci device completely from the system, first detach the port 
> from testpmd.
> +Then the device should be moved under kernel management.
> +Finally the device can be removed using kernel pci hotplug functionality.
> +
> +For example, to move a pci device under kernel management:
> +
> +.. code-block:: console
> +
> +  

[dpdk-dev] [PATCH v2 4/4] doc: extend commands in testpmd

[Jingjing Wu]

Modify the doc about flow director commands to support l2_payload flow type.

Signed-off-by: Jingjing Wu 
---
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst 
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 761172e..9aa5397 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1537,6 +1537,9 @@ flow_director_filter (port_id) (add|del|update) flow 
(ipv4-sctp|ipv6-sctp)
 src (src_ip_address) (src_port) dst (dst_ip_address) (dst_port) tag 
(verification_tag)
 vlan (vlan_value) flexbytes (flexbytes_value) (drop|fwd) queue (queue_id) 
fd_id (fd_id_value)

+flow_director_filter (port_id) (add|del|update) flow l2_payload
+ether (ethertype) flexbytes (flexbytes_value) (drop|fwd) queue (queue_id) 
fd_id (fd_id_value)
+
 For example, to add an ipv4-udp flow type filter:

 .. code-block:: console
@@ -1582,7 +1585,7 @@ flow_director_flex_mask
 set masks of flow director's flexible payload based on certain flow type:

 flow_director_flex_mask (port_id) flow 
(none|ipv4-other|ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|
-ipv6-other|ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|all) (mask)
+ipv6-other|ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|l2_payload|all) (mask)

 Example, to set flow director's flex mask for all flow type on port 0:

-- 
1.9.3

[dpdk-dev] [PATCH v2 3/4] testpmd: extend commands

[Jingjing Wu]

This patch extends flow director commands to support l2_payload flow type.

Signed-off-by: Jingjing Wu 
---
 app/test-pmd/cmdline.c | 48 +---
 1 file changed, 45 insertions(+), 3 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f01db2a..9659464 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -652,6 +652,12 @@ static void cmd_help_long_parsed(void *parsed_result,
" queue (queue_id) fd_id (fd_id_value)\n"
"Add/Del a SCTP type flow director filter.\n\n"

+   "flow_director_filter (port_id) (add|del|update)"
+   " flow l2_payload ether (ethertype)"
+   " flexbytes (flexbytes_value) (drop|fwd)"
+   " queue (queue_id) fd_id (fd_id_value)\n"
+   "Add/Del a l2 payload type flow director 
filter.\n\n"
+
"flush_flow_director (port_id)\n"
"Flush all flow director entries of a device.\n\n"

@@ -662,7 +668,7 @@ static void cmd_help_long_parsed(void *parsed_result,

"flow_director_flex_mask (port_id)"
" flow 
(none|ipv4-other|ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|"
-   "ipv6-other|ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|all)"
+   
"ipv6-other|ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|l2_payload|all)"
" (mask)\n"
"Configure mask of flex payload.\n\n"

@@ -7653,6 +7659,8 @@ struct cmd_flow_director_result {
cmdline_fixed_string_t ops;
cmdline_fixed_string_t flow;
cmdline_fixed_string_t flow_type;
+   cmdline_fixed_string_t ether;
+   uint16_t ether_type;
cmdline_fixed_string_t src;
cmdline_ipaddr_t ip_src;
uint16_t port_src;
@@ -7837,6 +7845,10 @@ cmd_flow_director_filter_parsed(void *parsed_result,
entry.input.flow.sctp6_flow.verify_tag =
rte_cpu_to_be_32(res->verify_tag_value);
break;
+   case RTE_ETH_FLOW_L2_PAYLOAD:
+   entry.input.flow.l2_flow.ether_type =
+   rte_cpu_to_be_16(res->ether_type);
+   break;
default:
printf("invalid parameter.\n");
return;
@@ -7885,7 +7897,13 @@ cmdline_parse_token_string_t cmd_flow_director_flow =
 cmdline_parse_token_string_t cmd_flow_director_flow_type =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
flow_type, "ipv4-other#ipv4-frag#ipv4-tcp#ipv4-udp#ipv4-sctp#"
-   "ipv6-other#ipv6-frag#ipv6-tcp#ipv6-udp#ipv6-sctp");
+   "ipv6-other#ipv6-frag#ipv6-tcp#ipv6-udp#ipv6-sctp#l2_payload");
+cmdline_parse_token_string_t cmd_flow_director_ether =
+   TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
+ether, "ether");
+cmdline_parse_token_num_t cmd_flow_director_ether_type =
+   TOKEN_NUM_INITIALIZER(struct cmd_flow_director_result,
+ ether_type, UINT16);
 cmdline_parse_token_string_t cmd_flow_director_src =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_result,
 src, "src");
@@ -8025,6 +8043,29 @@ cmdline_parse_inst_t cmd_add_del_sctp_flow_director = {
},
 };

+cmdline_parse_inst_t cmd_add_del_l2_flow_director = {
+   .f = cmd_flow_director_filter_parsed,
+   .data = NULL,
+   .help_str = "add or delete a L2 flow director entry on NIC",
+   .tokens = {
+   (void *)&cmd_flow_director_filter,
+   (void *)&cmd_flow_director_port_id,
+   (void *)&cmd_flow_director_ops,
+   (void *)&cmd_flow_director_flow,
+   (void *)&cmd_flow_director_flow_type,
+   (void *)&cmd_flow_director_ether,
+   (void *)&cmd_flow_director_ether_type,
+   (void *)&cmd_flow_director_flexbytes,
+   (void *)&cmd_flow_director_flexbytes_value,
+   (void *)&cmd_flow_director_drop,
+   (void *)&cmd_flow_director_queue,
+   (void *)&cmd_flow_director_queue_id,
+   (void *)&cmd_flow_director_fd_id,
+   (void *)&cmd_flow_director_fd_id_value,
+   NULL,
+   },
+};
+
 struct cmd_flush_flow_director_result {
cmdline_fixed_string_t flush_flow_director;
uint8_t port_id;
@@ -8278,7 +8319,7 @@ cmdline_parse_token_string_t 
cmd_flow_director_flexmask_flow =
 cmdline_parse_token_string_t cmd_flow_director_flexmask_flow_type =
TOKEN_STRING_INITIALIZER(struct cmd_flow_director_flex_mask_result,
flow_type, 
"none#ipv4-other#ipv4-frag#ipv4-tcp#ipv4-udp#ipv4-sctp#"
-   "ipv6-other#ipv6-frag#ipv6-tcp#ipv6-udp#ipv6-sctp#all");
+   
"ipv6-other#ipv6-frag#ipv6-tcp#ipv6-ud

[dpdk-dev] [PATCH v2 2/4] i40e: extend flow diretcor to support l2_payload flow type

[Jingjing Wu]

This patch extends flow diretcor to support l2_payload flow
type in i40e driver.

Signed-off-by: Jingjing Wu 
---
 drivers/net/i40e/i40e_fdir.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c
index 4bf98d0..8b81ca3 100644
--- a/drivers/net/i40e/i40e_fdir.c
+++ b/drivers/net/i40e/i40e_fdir.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -104,7 +105,8 @@
(1 << RTE_ETH_FLOW_NONFRAG_IPV6_UDP) | \
(1 << RTE_ETH_FLOW_NONFRAG_IPV6_TCP) | \
(1 << RTE_ETH_FLOW_NONFRAG_IPV6_SCTP) | \
-   (1 << RTE_ETH_FLOW_NONFRAG_IPV6_OTHER))
+   (1 << RTE_ETH_FLOW_NONFRAG_IPV6_OTHER) | \
+   (1 << RTE_ETH_FLOW_L2_PAYLOAD))

 #define I40E_FLEX_WORD_MASK(off) (0x80 >> (off))

@@ -366,7 +368,9 @@ i40e_init_flx_pld(struct i40e_pf *pf)

/* initialize the masks */
for (pctype = I40E_FILTER_PCTYPE_NONF_IPV4_UDP;
-pctype <= I40E_FILTER_PCTYPE_FRAG_IPV6; pctype++) {
+pctype <= I40E_FILTER_PCTYPE_L2_PAYLOAD; pctype++) {
+   if (!I40E_VALID_PCTYPE((enum i40e_filter_pctype)pctype))
+   continue;
pf->fdir.flex_mask[pctype].word_mask = 0;
I40E_WRITE_REG(hw, I40E_PRTQF_FD_FLXINSET(pctype), 0);
for (i = 0; i < I40E_FDIR_BITMASK_NUM_WORD; i++) {
@@ -704,6 +708,9 @@ i40e_fdir_fill_eth_ip_head(const struct rte_eth_fdir_input 
*fdir_input,
};

switch (fdir_input->flow_type) {
+   case RTE_ETH_FLOW_L2_PAYLOAD:
+   ether->ether_type = fdir_input->flow.l2_flow.ether_type;
+   break;
case RTE_ETH_FLOW_NONFRAG_IPV4_TCP:
case RTE_ETH_FLOW_NONFRAG_IPV4_UDP:
case RTE_ETH_FLOW_NONFRAG_IPV4_SCTP:
@@ -866,6 +873,17 @@ i40e_fdir_construct_pkt(struct i40e_pf *pf,
  sizeof(struct ipv6_hdr);
set_idx = I40E_FLXPLD_L3_IDX;
break;
+   case RTE_ETH_FLOW_L2_PAYLOAD:
+   payload = raw_pkt + sizeof(struct ether_hdr);
+   /*
+* ARP packet is a special case on which the payload
+* starts after the whole ARP header
+*/
+   if (fdir_input->flow.l2_flow.ether_type ==
+   rte_cpu_to_be_16(ETHER_TYPE_ARP))
+   payload += sizeof(struct arp_hdr);
+   set_idx = I40E_FLXPLD_L2_IDX;
+   break;
default:
PMD_DRV_LOG(ERR, "unknown flow type %u.", 
fdir_input->flow_type);
return -EINVAL;
@@ -1218,7 +1236,7 @@ i40e_fdir_info_get_flex_mask(struct i40e_pf *pf,
uint16_t off_bytes, mask_tmp;

for (i = I40E_FILTER_PCTYPE_NONF_IPV4_UDP;
-i <= I40E_FILTER_PCTYPE_FRAG_IPV6;
+i <= I40E_FILTER_PCTYPE_L2_PAYLOAD;
 i++) {
mask =  &pf->fdir.flex_mask[i];
if (!I40E_VALID_PCTYPE((enum i40e_filter_pctype)i))
-- 
1.9.3

[dpdk-dev] [PATCH v2 1/4] ethdev: add struct rte_eth_l2_flow to support l2_payload flow type

[Jingjing Wu]

This patch adds a new struct rte_eth_l2_flow to support l2_payload flow type

Signed-off-by: Jingjing Wu 
---
 lib/librte_ether/rte_eth_ctrl.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 498fc85..0e30dd9 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -298,6 +298,13 @@ struct rte_eth_tunnel_filter_conf {
 #define RTE_ETH_FDIR_MAX_FLEXLEN 16 /** < Max length of flexbytes. */

 /**
+ * A structure used to define the input for L2 flow
+ */
+struct rte_eth_l2_flow {
+   uint16_t ether_type;  /**< Ether type to match */
+};
+
+/**
  * A structure used to define the input for IPV4 flow
  */
 struct rte_eth_ipv4_flow {
@@ -369,6 +376,7 @@ struct rte_eth_sctpv6_flow {
  * An union contains the inputs for all types of flow
  */
 union rte_eth_fdir_flow {
+   struct rte_eth_l2_flow l2_flow;
struct rte_eth_udpv4_flow  udp4_flow;
struct rte_eth_tcpv4_flow  tcp4_flow;
struct rte_eth_sctpv4_flow sctp4_flow;
-- 
1.9.3

[dpdk-dev] [PATCH v2 0/4] extend flow director to support L2_paylod type

[Jingjing Wu]

This patch set extends flow director to support L2_paylod type in i40e driver.

v2 change:
 - remove the flow director VF filtering from this patch to avoid breaking ABI.

Jingjing Wu (4):
  ethdev: add struct rte_eth_l2_flow to support l2_payload flow type
  i40e: extend flow diretcor to support l2_payload flow type
  testpmd: extend commands
  doc: extend commands in testpmd

 app/test-pmd/cmdline.c  | 48 +++--
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  5 ++-
 drivers/net/i40e/i40e_fdir.c| 24 +--
 lib/librte_ether/rte_eth_ctrl.h |  8 +
 4 files changed, 78 insertions(+), 7 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH v2] Add toeplitz hash algorithm used by RSS

[Bruce Richardson]

On Tue, Jun 16, 2015 at 11:07:28AM +0200, Thomas Monjalon wrote:
> 2015-06-03 16:07, Thomas Monjalon:
> > 2015-05-08 10:58, Vladimir Medvedkin:
> > > Software implementation of the Toeplitz hash function used by RSS.
> > > Can be used either for packet distribution on single queue NIC
> > > or for simulating of RSS computation on specific NIC (for example
> > > after GRE header decapsulating).
> > > 
> > > v3 changes
> > > - Rework API to be more generic
> > > - Add sctp_tag into tuple
> > > 
> > > v2 changes
> > > - Add ipv6 support
> > > - Various style fixes
> > > 
> > > Signed-off-by: Vladimir Medvedkin 
> > > ---
> > >  lib/librte_hash/Makefile|   1 +
> > >  lib/librte_hash/rte_thash.h | 207 
> > > 
> > 
> > Without any comment, it seems this v3 is approved.
> > Maybe that this patch would be even better by implementing some unit tests.
> > I wonder if the hash chapter of the prog guide could list the different
> > algorithms and why/when use them?
> 
> Bruce, any opinion?
> Don't you think that unit tests are required?

Sorry, I missed this patch set. I'll take a look at it today.

/Bruce

[dpdk-dev] [PATCH v6 08/10] hash: remove duplicated code

[Thomas Monjalon]

The following patch is needed and will be squashed to fix some doxygen issues:

--- a/lib/librte_hash/rte_jhash.h
+++ b/lib/librte_hash/rte_jhash.h
@@ -306,13 +306,13 @@ rte_jhash2(const uint32_t *k, uint32_t length, uint32_t 
initval)
  * with seeds. If you pass in (*pb)=0, the output (*pc) will be
  * the same as the return value from rte_jhash.
  *
- * @param k
+ * @param key
  *   Key to calculate hash of.
  * @param length
  *   Length of key in bytes.
  * @param pc
  *   IN: seed OUT: primary hash value.
- * @param pc
+ * @param pb
  *   IN: second seed OUT: secondary hash value.
  */
 static inline void
@@ -464,7 +464,7 @@ rte_jhash_2hashes(const void *key, uint32_t length, 
uint32_t *pc, uint32_t *pb)
  *   Length of key in units of 4 bytes.
  * @param pc
  *   IN: seed OUT: primary hash value.
- * @param pc
+ * @param pb
  *   IN: second seed OUT: secondary hash value.
  */
 static inline void

[dpdk-dev] [PATCH v2] Add toeplitz hash algorithm used by RSS

[Thomas Monjalon]

2015-06-03 16:07, Thomas Monjalon:
> 2015-05-08 10:58, Vladimir Medvedkin:
> > Software implementation of the Toeplitz hash function used by RSS.
> > Can be used either for packet distribution on single queue NIC
> > or for simulating of RSS computation on specific NIC (for example
> > after GRE header decapsulating).
> > 
> > v3 changes
> > - Rework API to be more generic
> > - Add sctp_tag into tuple
> > 
> > v2 changes
> > - Add ipv6 support
> > - Various style fixes
> > 
> > Signed-off-by: Vladimir Medvedkin 
> > ---
> >  lib/librte_hash/Makefile|   1 +
> >  lib/librte_hash/rte_thash.h | 207 
> > 
> 
> Without any comment, it seems this v3 is approved.
> Maybe that this patch would be even better by implementing some unit tests.
> I wonder if the hash chapter of the prog guide could list the different
> algorithms and why/when use them?

Bruce, any opinion?
Don't you think that unit tests are required?

[dpdk-dev] [PATCH v3 00/10] Add a VXLAN sample

[Thomas Monjalon]

> Acked-by: Helin Zhang 

Sorry, there are too many checkpatch errors to peacefully apply this series.

[dpdk-dev] [PATCH v6 08/10] hash: remove duplicated code

[De Lara Guarch, Pablo]

Hi Thomas,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, June 16, 2015 10:33 AM
> To: De Lara Guarch, Pablo
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 08/10] hash: remove duplicated code
> 
> The following patch is needed and will be squashed to fix some doxygen
> issues:
> 
> --- a/lib/librte_hash/rte_jhash.h
> +++ b/lib/librte_hash/rte_jhash.h
> @@ -306,13 +306,13 @@ rte_jhash2(const uint32_t *k, uint32_t length,
> uint32_t initval)
>   * with seeds. If you pass in (*pb)=0, the output (*pc) will be
>   * the same as the return value from rte_jhash.
>   *
> - * @param k
> + * @param key
>   *   Key to calculate hash of.
>   * @param length
>   *   Length of key in bytes.
>   * @param pc
>   *   IN: seed OUT: primary hash value.
> - * @param pc
> + * @param pb
>   *   IN: second seed OUT: secondary hash value.
>   */
>  static inline void
> @@ -464,7 +464,7 @@ rte_jhash_2hashes(const void *key, uint32_t length,
> uint32_t *pc, uint32_t *pb)
>   *   Length of key in units of 4 bytes.
>   * @param pc
>   *   IN: seed OUT: primary hash value.
> - * @param pc
> + * @param pb
>   *   IN: second seed OUT: secondary hash value.
>   */
>  static inline void

Thanks for spotting this!
Are you going to do it yourself or you want me to do it and send a v7?

Pablo

[dpdk-dev] [PATCH v2 3/3] test scaling of HTM lock elision protecting rte_hash

[Roman Dementiev]

This patch adds a new auto-test for testing the scaling
of concurrent inserts into rte_hash when protected by
the normal spinlock vs. the spinlock with HTM lock
elision. The test also benchmarks single-threaded
access without any locks.

Signed-off-by: Roman Dementiev 
---
 app/test/Makefile|   1 +
 app/test/test_hash_scaling.c | 223 +++
 2 files changed, 224 insertions(+)
 create mode 100644 app/test/test_hash_scaling.c

diff --git a/app/test/Makefile b/app/test/Makefile
index 3c777bf..6ffe539 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -83,6 +83,7 @@ SRCS-y += test_memcpy_perf.c

 SRCS-$(CONFIG_RTE_LIBRTE_HASH) += test_hash.c
 SRCS-$(CONFIG_RTE_LIBRTE_HASH) += test_hash_perf.c
+SRCS-$(CONFIG_RTE_LIBRTE_HASH) += test_hash_scaling.c

 SRCS-$(CONFIG_RTE_LIBRTE_LPM) += test_lpm.c
 SRCS-$(CONFIG_RTE_LIBRTE_LPM) += test_lpm6.c
diff --git a/app/test/test_hash_scaling.c b/app/test/test_hash_scaling.c
new file mode 100644
index 000..682ae94
--- /dev/null
+++ b/app/test/test_hash_scaling.c
@@ -0,0 +1,223 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2015 Intel Corporation. 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.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "test.h"
+
+/*
+ * Check condition and return an error if true. Assumes that "handle" is the
+ * name of the hash structure pointer to be freed.
+ */
+#define RETURN_IF_ERROR(cond, str, ...) do {   \
+   if (cond) { \
+   printf("ERROR line %d: " str "\n", __LINE__,\
+   ##__VA_ARGS__); \
+   if (handle) \
+   rte_hash_free(handle);  \
+   return -1;  \
+   }   \
+} while (0)
+
+enum locking_mode_t {
+   NORMAL_LOCK,
+   LOCK_ELISION,
+   NULL_LOCK
+};
+
+struct {
+   uint32_t num_iterations;
+   struct rte_hash *h;
+   rte_spinlock_t *lock;
+   int locking_mode;
+} tbl_scaling_test_params;
+
+static rte_atomic64_t gcycles;
+
+static int test_hash_scaling_worker(__attribute__((unused)) void *arg)
+{
+   uint64_t i, key;
+   uint32_t thr_id = rte_sys_gettid();
+   uint64_t begin, cycles = 0;
+
+   switch (tbl_scaling_test_params.locking_mode) {
+
+   case NORMAL_LOCK:
+
+   for (i = 0; i < tbl_scaling_test_params.num_iterations; i++) {
+   /*  different threads get different keys because
+   we use the thread-id in the key computation
+*/
+   key = rte_hash_crc(&i, sizeof(i), thr_id);
+   begin = rte_rdtsc_precise();
+   rte_spinlock_lock(tbl_scaling_test_params.lock);
+   rte_hash_add_key(tbl_scaling_test_params.h, &key);
+   rte_spinlock_unlock(tbl_scaling_test_params.lock);
+   cycles += rte_rdtsc_precise() - begin;
+   }
+   break;
+
+   case LOCK_ELISION:
+
+   for (i = 0; i < tbl_scaling_test_params.num_iterations; i++) {
+ 

[dpdk-dev] [PATCH v2 2/3] rwlock: add support for HTM lock elision for x86

[Roman Dementiev]

This patch adds methods that use hardware memory transactions (HTM) on
fast-path for rwlock (a.k.a. lock elision). Here the methods are implemented
for x86 using Restricted Transactional Memory instructions (Intel(r)
Transactional Synchronization Extensions). The implementation fall-backs to
the normal rwlock if HTM is not available or memory transactions fail. This is
not a replacement for all rwlock usages since not all critical sections
protected by locks are friendly to HTM. For example, an attempt to perform
a HW I/O operation inside a hardware memory transaction always aborts
the transaction since the CPU is not able to roll-back should the transaction
fail. Therefore, hardware transactional locks are not advised to be used around
rte_eth_rx_burst() and rte_eth_tx_burst() calls.

Signed-off-by: Roman Dementiev 
---
 lib/librte_eal/common/Makefile |   4 +-
 .../common/include/arch/ppc_64/rte_rwlock.h|  38 
 .../common/include/arch/x86/rte_rwlock.h   |  82 
 lib/librte_eal/common/include/generic/rte_rwlock.h | 208 +
 lib/librte_eal/common/include/rte_rwlock.h | 158 
 5 files changed, 330 insertions(+), 160 deletions(-)
 create mode 100644 lib/librte_eal/common/include/arch/ppc_64/rte_rwlock.h
 create mode 100644 lib/librte_eal/common/include/arch/x86/rte_rwlock.h
 create mode 100644 lib/librte_eal/common/include/generic/rte_rwlock.h
 delete mode 100644 lib/librte_eal/common/include/rte_rwlock.h

diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index 3ea3bbf..38772d4 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -35,7 +35,7 @@ INC := rte_branch_prediction.h rte_common.h
 INC += rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h
 INC += rte_log.h rte_memory.h rte_memzone.h rte_pci.h
 INC += rte_pci_dev_ids.h rte_per_lcore.h rte_random.h
-INC += rte_rwlock.h rte_tailq.h rte_interrupts.h rte_alarm.h
+INC += rte_tailq.h rte_interrupts.h rte_alarm.h
 INC += rte_string_fns.h rte_version.h
 INC += rte_eal_memconfig.h rte_malloc_heap.h
 INC += rte_hexdump.h rte_devargs.h rte_dev.h
@@ -46,7 +46,7 @@ INC += rte_warnings.h
 endif

 GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h
-GENERIC_INC += rte_spinlock.h rte_memcpy.h rte_cpuflags.h
+GENERIC_INC += rte_spinlock.h rte_memcpy.h rte_cpuflags.h rte_rwlock.h
 # defined in mk/arch/$(RTE_ARCH)/rte.vars.mk
 ARCH_DIR ?= $(RTE_ARCH)
 ARCH_INC := $(notdir $(wildcard 
$(RTE_SDK)/lib/librte_eal/common/include/arch/$(ARCH_DIR)/*.h))
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_rwlock.h 
b/lib/librte_eal/common/include/arch/ppc_64/rte_rwlock.h
new file mode 100644
index 000..de8af19
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_rwlock.h
@@ -0,0 +1,38 @@
+#ifndef _RTE_RWLOCK_PPC_64_H_
+#define _RTE_RWLOCK_PPC_64_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "generic/rte_rwlock.h"
+
+static inline void
+rte_rwlock_read_lock_tm(rte_rwlock_t *rwl)
+{
+   rte_rwlock_read_lock(rwl);
+}
+
+static inline void
+rte_rwlock_read_unlock_tm(rte_rwlock_t *rwl)
+{
+   rte_rwlock_read_unlock(rwl);
+}
+
+static inline void
+rte_rwlock_write_lock_tm(rte_rwlock_t *rwl)
+{
+   rte_rwlock_write_lock(rwl);
+}
+
+static inline void
+rte_rwlock_write_unlock_tm(rte_rwlock_t *rwl)
+{
+   rte_rwlock_write_unlock(rwl);
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_RWLOCK_PPC_64_H_ */
diff --git a/lib/librte_eal/common/include/arch/x86/rte_rwlock.h 
b/lib/librte_eal/common/include/arch/x86/rte_rwlock.h
new file mode 100644
index 000..afd1c3c
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/x86/rte_rwlock.h
@@ -0,0 +1,82 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2015 Intel Corporation. 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.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   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 A

[dpdk-dev] [PATCH v2 1/3] spinlock: add support for HTM lock elision for x86

[Roman Dementiev]

This patch adds methods that use hardware memory transactions (HTM) on fast-path
for spinlocks (a.k.a. lock elision). Here the methods are implemented for x86
using Restricted Transactional Memory instructions (Intel(r) Transactional
Synchronization Extensions). The implementation fall-backs to the normal
spinlock if HTM is not available or memory transactions fail. This is not
a replacement for all spinlock usages since not all critical sections protected
by spinlocks are friendly to HTM. For example, an attempt to perform a HW I/O
operation inside a hardware memory transaction always aborts the transaction
since the CPU is not able to roll-back should the transaction fail.
Therefore, hardware transactional locks are not advised to be used around
rte_eth_rx_burst() and rte_eth_tx_burst() calls.

Signed-off-by: Roman Dementiev 
---
 .../common/include/arch/ppc_64/rte_spinlock.h  |  41 
 lib/librte_eal/common/include/arch/x86/rte_rtm.h   |  73 ++
 .../common/include/arch/x86/rte_spinlock.h | 107 +
 .../common/include/generic/rte_spinlock.h  |  99 +++
 4 files changed, 320 insertions(+)
 create mode 100644 lib/librte_eal/common/include/arch/x86/rte_rtm.h

diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_spinlock.h 
b/lib/librte_eal/common/include/arch/ppc_64/rte_spinlock.h
index cf8b81a..3336435 100644
--- a/lib/librte_eal/common/include/arch/ppc_64/rte_spinlock.h
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_spinlock.h
@@ -66,6 +66,47 @@ rte_spinlock_trylock(rte_spinlock_t *sl)

 #endif

+static inline int rte_tm_supported(void)
+{
+   return 0;
+}
+
+static inline void
+rte_spinlock_lock_tm(rte_spinlock_t *sl)
+{
+   rte_spinlock_lock(sl); /* fall-back */
+}
+
+static inline int
+rte_spinlock_trylock_tm(rte_spinlock_t *sl)
+{
+   return rte_spinlock_trylock(sl);
+}
+
+static inline void
+rte_spinlock_unlock_tm(rte_spinlock_t *sl)
+{
+   rte_spinlock_unlock(sl);
+}
+
+static inline void
+rte_spinlock_recursive_lock_tm(rte_spinlock_recursive_t *slr)
+{
+   rte_spinlock_recursive_lock(slr); /* fall-back */
+}
+
+static inline void
+rte_spinlock_recursive_unlock_tm(rte_spinlock_recursive_t *slr)
+{
+   rte_spinlock_recursive_unlock(slr);
+}
+
+static inline int
+rte_spinlock_recursive_trylock_tm(rte_spinlock_recursive_t *slr)
+{
+   return rte_spinlock_recursive_trylock(slr);
+}
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_eal/common/include/arch/x86/rte_rtm.h 
b/lib/librte_eal/common/include/arch/x86/rte_rtm.h
new file mode 100644
index 000..d935641
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/x86/rte_rtm.h
@@ -0,0 +1,73 @@
+#ifndef _RTE_RTM_H_
+#define _RTE_RTM_H_ 1
+
+/*
+ * Copyright (c) 2012,2013 Intel Corporation
+ * Author: Andi Kleen
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that: (1) source code distributions
+ * retain the above copyright notice and this paragraph in its entirety, (2)
+ * distributions including binary code include the above copyright notice and
+ * this paragraph in its entirety in the documentation or other materials
+ * provided with the distribution
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+/* Official RTM intrinsics interface matching gcc/icc, but works
+   on older gcc compatible compilers and binutils. */
+
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+
+#define RTE_XBEGIN_STARTED (~0u)
+#define RTE_XABORT_EXPLICIT(1 << 0)
+#define RTE_XABORT_RETRY   (1 << 1)
+#define RTE_XABORT_CONFLICT(1 << 2)
+#define RTE_XABORT_CAPACITY(1 << 3)
+#define RTE_XABORT_DEBUG   (1 << 4)
+#define RTE_XABORT_NESTED  (1 << 5)
+#define RTE_XABORT_CODE(x) (((x) >> 24) & 0xff)
+
+static __attribute__((__always_inline__)) inline
+unsigned int rte_xbegin(void)
+{
+   unsigned int ret = RTE_XBEGIN_STARTED;
+
+   asm volatile(".byte 0xc7,0xf8 ; .long 0" : "+a" (ret) :: "memory");
+   return ret;
+}
+
+static __attribute__((__always_inline__)) inline
+void rte_xend(void)
+{
+asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+}
+
+static __attribute__((__always_inline__)) inline
+void rte_xabort(const unsigned int status)
+{
+   asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory");
+}
+
+static __attribute__((__always_inline__)) inline
+int rte_xtest(void)
+{
+   unsigned char out;
+
+   asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" :
+   "=r" (out) :: "memory");
+   return out;
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_RTM_H_ */
diff --git a/lib/librte_eal/common/include/arch/x86/rte_spinlock.h 
b/lib/librte_eal/common/include/arch/x86/rte_spinlock.h
i

[dpdk-dev] [PATCH v2 0/3] add support for HTM lock elision for x86

[Roman Dementiev]

This series of patches adds methods that use hardware memory transactions (HTM)
on fast-path for DPDK locks (a.k.a. lock elision). Here the methods are
implemented for x86 using Restricted Transactional Memory instructions (Intel(r)
Transactional Synchronization Extensions). The implementation fall-backs to
the normal DPDK lock if HTM is not available or memory transactions fail. This
is not a replacement for ALL lock usages since not all critical sections
protected by locks are friendly to HTM. For example, an attempt to perform
a HW I/O operation inside a hardware memory transaction always aborts
the transaction since the CPU is not able to roll-back should the transaction
fail. Therefore, hardware transactional locks are not advised to be used around
rte_eth_rx_burst() and rte_eth_tx_burst() calls.

v2 changes
-added a documentation note about hardware limitations

Roman Dementiev (3):
  spinlock: add support for HTM lock elision for x86
  rwlock: add support for HTM lock elision for x86
  test scaling of HTM lock elision protecting rte_hash

 app/test/Makefile  |   1 +
 app/test/test_hash_scaling.c   | 223 +
 lib/librte_eal/common/Makefile |   4 +-
 .../common/include/arch/ppc_64/rte_rwlock.h|  38 
 .../common/include/arch/ppc_64/rte_spinlock.h  |  41 
 lib/librte_eal/common/include/arch/x86/rte_rtm.h   |  73 +++
 .../common/include/arch/x86/rte_rwlock.h   |  82 
 .../common/include/arch/x86/rte_spinlock.h | 107 ++
 lib/librte_eal/common/include/generic/rte_rwlock.h | 208 +++
 .../common/include/generic/rte_spinlock.h  |  99 +
 lib/librte_eal/common/include/rte_rwlock.h | 158 ---
 11 files changed, 874 insertions(+), 160 deletions(-)
 create mode 100644 app/test/test_hash_scaling.c
 create mode 100644 lib/librte_eal/common/include/arch/ppc_64/rte_rwlock.h
 create mode 100644 lib/librte_eal/common/include/arch/x86/rte_rtm.h
 create mode 100644 lib/librte_eal/common/include/arch/x86/rte_rwlock.h
 create mode 100644 lib/librte_eal/common/include/generic/rte_rwlock.h
 delete mode 100644 lib/librte_eal/common/include/rte_rwlock.h

-- 
1.9.5.msysgit.0

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

[dpdk-dev] [PATCH] abi: Announce abi changes plan for vhost-user multiple queues

[Ouyang Changchun]

It announces the planned ABI changes for vhost-user multiple queues feature on 
v2.2.

Signed-off-by: Changchun Ouyang 
---
 doc/guides/rel_notes/abi.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/rel_notes/abi.rst b/doc/guides/rel_notes/abi.rst
index f00a6ee..dc1b0eb 100644
--- a/doc/guides/rel_notes/abi.rst
+++ b/doc/guides/rel_notes/abi.rst
@@ -38,3 +38,4 @@ Examples of Deprecation Notices

 Deprecation Notices
 ---
+* The ABI changes are planned for struct virtio_net in order to support 
vhost-user multiple queues feature. The upcoming release 2.1 will not contain 
these ABI changes, but release 2.2 will, and no backwards compatibility is 
planed due to the vhost-user multiple queues feature enabling. Binaries using 
this library build prior to version 2.2 will require updating and recompilation.
-- 
1.8.4.2

[dpdk-dev] rte_mbuf.next in 2nd cacheline

[Bruce Richardson]

On Mon, Jun 15, 2015 at 01:47:26PM -0700, Stephen Hemminger wrote:
> On Mon, 15 Jun 2015 18:34:13 +
> "Ananyev, Konstantin"  wrote:
> 
> > 
> > 
> > > -Original Message-
> > > From: Richardson, Bruce
> > > Sent: Monday, June 15, 2015 5:23 PM
> > > To: Ananyev, Konstantin
> > > Cc: Olivier MATZ; dev at dpdk.org; Damjan Marion (damarion)
> > > Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
> > > 
> > > On Mon, Jun 15, 2015 at 05:10:44PM +0100, Ananyev, Konstantin wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Richardson, Bruce
> > > > > Sent: Monday, June 15, 2015 5:02 PM
> > > > > To: Ananyev, Konstantin
> > > > > Cc: Olivier MATZ; dev at dpdk.org; Damjan Marion (damarion)
> > > > > Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
> > > > >
> > > > > On Mon, Jun 15, 2015 at 04:59:55PM +0100, Ananyev, Konstantin wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > As I can see, vector TX is the only one that calls 
> > > > > > __rte_pktmbuf_prefree_seg() directly.
> > > > > > All others use rte_pktmbuf_free_seg(), that does ' m->next = NULL' 
> > > > > > anyway.
> > > > > > For vector TX - yes, need to verify that it would not introduce a 
> > > > > > slowdown.
> > > > > > Konstantin
> > > > > >
> > > > >
> > > > > But if the function is only directly called from one place, and that 
> > > > > doesn't
> > > > > have a problem, why would we bother making any change at all?
> > > >
> > > >
> > > > For future usages?
> > > > But sure, if you believe that we can safely remove 'm->next = NULL' at 
> > > > RX path,
> > > > without any changes in the __rte_pktmbuf_prefree_seg() -
> > > > that seems fine to me.
> > > > Konstantin
> > > >
> > > 
> > > If we find it's not safe, we can add in the change to 
> > > __rte_pktmbuf_prefree_seg
> > > as you suggest.
> > > 
> > > One other question: based on this, do you think it's safe to also remove 
> > > the
> > > assignment to NULL from the pktmbuf_alloc function? I suspect it should 
> > > be safe, and
> > > that should help any traffic-generator type applications that use that 
> > > function
> > > extensively.
> > 
> > So it will be setup to NULL, either by:
> > - mbuf constructor.
> > - TX full-path free descriptors code.
> > - upper layer code that uses 'next' pointer explicitly.
> > ?
> > 
> > I can't come-up with some breakage scenario off-hand.
> > But that means that we have to should avoid resetting tx_offload in 
> > pktmbuf_alloc() too, right?
> > Otherwise there probably wouldn't be any real gain.
> > Konstantin
> > 
> > > 
> > > /Bruce
> > 
> > 
> 
> The issue is when mbuf is used once by something and it sets it to non-NULL
> packet is sent then freed.
> then the free packet is picked up by one of the drivers using "fast path" Rx 
> code.
> 
> IMHO the "fast path" Rx code has to go away. All the special allocation code
> should call rte_pktmuf_reset and then only set the fields that are special
> for the received packet.  The compiler should be able to remove the redundant
> stores, and it would prevent bugs I am seeing where some fields are not set
> in some drivers.

Is the better option here not to just fix the drivers rather than making the
fast-path RX code go away? Can you give us a report out on what fields are not
getting correctly set, and when using what drivers, and we can look and see 
where our gaps in coverage are?

/Bruce

[dpdk-dev] [PATCH v3] kni: Add link status update

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vijayakumar Muthuvel
> Manickam
> Sent: Tuesday, June 16, 2015 2:40 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v3] kni: Add link status update
> 
> Implement .ndo_change_carrier to enable
> DPDK applications to propagate link state changes to kni virtual interfaces
> through sysfs
> 
> Signed-off-by: Vijayakumar Muthuvel Manickam 
Acked-by: Helin Zhang 

> ---
> Added kernel version check as .ndo_change_carrier is available only in kernel
> versions 3.9 and after
> 
>  lib/librte_eal/linuxapp/kni/kni_net.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/lib/librte_eal/linuxapp/kni/kni_net.c
> b/lib/librte_eal/linuxapp/kni/kni_net.c
> index dd95db5..9f9022b 100644
> --- a/lib/librte_eal/linuxapp/kni/kni_net.c
> +++ b/lib/librte_eal/linuxapp/kni/kni_net.c
> @@ -632,6 +632,17 @@ static int kni_net_set_mac(struct net_device *netdev,
> void *p)
>   return 0;
>  }
> 
> +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 9, 0)) static int
> +kni_net_change_carrier(struct net_device *dev, bool new_carrier) {
> + if (new_carrier)
> + netif_carrier_on(dev);
> + else
> + netif_carrier_off(dev);
> + return 0;
> +}
> +#endif
> +
>  static const struct header_ops kni_net_header_ops = {
>   .create  = kni_net_header,
>   .rebuild = kni_net_rebuild_header,
> @@ -648,6 +659,9 @@ static const struct net_device_ops kni_net_netdev_ops =
> {
>   .ndo_get_stats = kni_net_stats,
>   .ndo_tx_timeout = kni_net_tx_timeout,
>   .ndo_set_mac_address = kni_net_set_mac,
> +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 9, 0))
> + .ndo_change_carrier = kni_net_change_carrier, #endif
>  };
> 
>  void
> --
> 1.8.1.4

[dpdk-dev] How to get net_device and use struct ethtool_cmd at DPDK enverinment?

[Choi, Sy Jong]

Hi Scott,

You can review DPDK KNI sample app, there's ethtool support using a vEth device 
interfacing to DPDK PMD.

Pure DPDK PMD require programming to display the information in ethtool. The 
interfacing is demonstrate on KNI sample app.

Regards,
Choi, Sy Jong
Platform Application Engineer

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of "Scott.Jhuang (???) : 6309"
Sent: Monday, June 15, 2015 6:35 PM
To: dev at dpdk.org
Subject: [dpdk-dev] How to get net_device and use struct ethtool_cmd at DPDK 
enverinment?

Hi,

I want to get etherport's net_device structs and using ethtool_cmd to get some 
information of etherports.
Are these capabilitys igb_uio driver also provided?

If not, how can I get net_devices and use ethtool_cmd capabilitys?

--

Best Regards,
Scott Jhuang

Software Engineering Dept.
Software Engineer
CASwell
238 ?242?8?
8F, No.242, Bo-Ai St., Shu-Lin Dist, New Taipei City 238, Taiwan
Tel?+886-2-7705- # 6309
Fax?+886-2-7731-9988
E-mail?scott.jhuang at cas-well.com
CASWELL Inc.  http://www.cas-well.com


? This email may contain 
confidential information. Please do not use or disclose it in any way and 
delete it if you are not the intended recipient.

[dpdk-dev] [PATCH v2] fm10k: fix PF/VF MAC address register and clean up bug

[Chen, Jing D]

Hi,

> -Original Message-
> From: He, Shaopeng
> Sent: Monday, June 15, 2015 9:26 AM
> To: dev at dpdk.org
> Cc: Chen, Jing D; Qiu, Michael; He, Shaopeng
> Subject: [PATCH v2] fm10k: fix PF/VF MAC address register and clean up bug
> 
> v2 changes:
>  - rebase this patch onto the HEAD
>  - add more description for this patch
> 
> This patch includes 3 changes related to MAC/VLAN address table
> when the system(e.g. testpmd) is started and closed:
>  - remove default MAC address with fixed VLAN 0 which was for the
>debug purpose before the MAC/VLAN filter function was implemented.
>  - enable VF MAC/VLAN filter for the first valid MAC address
>and first valid VLAN ID. This is needed for system(e.g. testpmd)
>to setup default MAC address and default VLAN for VF.
>Later attempt to change these default value will be refused by
>under layer shared code and PF host functions.
>  - un-register any combination of VLAN and MAC address from fm10k
>switch side MAC table when the system(e.g. testpmd) is closed.
> 
> Signed-off-by: Shaopeng He 
> ---
>  drivers/net/fm10k/fm10k_ethdev.c | 42 ++
> --
>  1 file changed, 23 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c
> b/drivers/net/fm10k/fm10k_ethdev.c
> index 802a930..625fd31 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -58,6 +58,8 @@ static int
>  fm10k_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on);
>  static void
>  fm10k_MAC_filter_set(struct rte_eth_dev *dev, const u8 *mac, bool add);
> +static void
> +fm10k_MACVLAN_remove_all(struct rte_eth_dev *dev);
> 
>  static void
>  fm10k_mbx_initlock(struct fm10k_hw *hw)
> @@ -703,6 +705,8 @@ fm10k_dev_close(struct rte_eth_dev *dev)
> 
>   PMD_INIT_FUNC_TRACE();
> 
> + fm10k_MACVLAN_remove_all(dev);
> +
>   /* Stop mailbox service first */
>   fm10k_close_mbx_service(hw);
>   fm10k_dev_stop(dev);
> @@ -832,12 +836,6 @@ fm10k_vlan_filter_set(struct rte_eth_dev *dev,
> uint16_t vlan_id, int on)
>   hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>   macvlan = FM10K_DEV_PRIVATE_TO_MACVLAN(dev->data-
> >dev_private);
> 
> - /* @todo - add support for the VF */
> - if (hw->mac.type != fm10k_mac_pf) {
> - PMD_INIT_LOG(ERR, "VLAN filter not available on VF");
> - return -ENOTSUP;
> - }
> -
>   if (vlan_id > ETH_VLAN_ID_MAX) {
>   PMD_INIT_LOG(ERR, "Invalid vlan_id: must be < 4096");
>   return (-EINVAL);
> @@ -926,12 +924,6 @@ fm10k_MAC_filter_set(struct rte_eth_dev *dev,
> const u8 *mac, bool add)
>   hw = FM10K_DEV_PRIVATE_TO_HW(dev->data->dev_private);
>   macvlan = FM10K_DEV_PRIVATE_TO_MACVLAN(dev->data-
> >dev_private);
> 
> - /* @todo - add support for the VF */
> - if (hw->mac.type != fm10k_mac_pf) {
> - PMD_INIT_LOG(ERR, "MAC filter not available on VF");
> - return;
> - }
> -
>   i = 0;
>   for (j = 0; j < FM10K_VFTA_SIZE; j++) {
>   if (macvlan->vfta[j]) {
> @@ -981,6 +973,25 @@ fm10k_macaddr_remove(struct rte_eth_dev *dev,
> uint32_t index)
>   FALSE);
>  }
> 
> +/* Remove all VLAN and MAC address table entries */
> +static void
> +fm10k_MACVLAN_remove_all(struct rte_eth_dev *dev)
> +{
> + uint32_t j, k;
> + struct fm10k_macvlan_filter_info *macvlan;
> +
> + macvlan = FM10K_DEV_PRIVATE_TO_MACVLAN(dev->data-
> >dev_private);
> + for (j = 0; j < FM10K_VFTA_SIZE; j++) {
> + if (macvlan->vfta[j]) {
> + for (k = 0; k < FM10K_UINT32_BIT_SIZE; k++) {
> + if (macvlan->vfta[j] & (1 << k))
> + fm10k_vlan_filter_set(dev,
> + j * FM10K_UINT32_BIT_SIZE
> + k, false);
> + }
> + }
> + }
> +}
> +
>  static inline int
>  check_nb_desc(uint16_t min, uint16_t max, uint16_t mult, uint16_t request)
>  {
> @@ -2008,13 +2019,6 @@ eth_fm10k_dev_init(struct rte_eth_dev *dev)
>   /* Enable port first */
>   hw->mac.ops.update_lport_state(hw, hw->mac.dglort_map, 1, 1);
> 
> - /*
> -  * Add default mac. glort is assigned by SM for PF, while is
> -  * unused for VF. PF will assign correct glort for VF.
> -  */
> - hw->mac.ops.update_uc_addr(hw, hw->mac.dglort_map, hw-
> >mac.addr,
> - 0, 1, 0);
> -
>   /* Set unicast mode by default. App can change to other mode in
> other
>* API func.
>*/
> --
> 1.9.3

Acked-by : Jing Chen 

[dpdk-dev] [PATCH] abi: Announce abi changes plan for vhost-user multiple queues

[Neil Horman]

On Tue, Jun 16, 2015 at 09:38:43AM +0800, Ouyang Changchun wrote:
> It announces the planned ABI changes for vhost-user multiple queues feature 
> on v2.2.
> 
> Signed-off-by: Changchun Ouyang 
> ---
>  doc/guides/rel_notes/abi.rst | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/doc/guides/rel_notes/abi.rst b/doc/guides/rel_notes/abi.rst
> index f00a6ee..dc1b0eb 100644
> --- a/doc/guides/rel_notes/abi.rst
> +++ b/doc/guides/rel_notes/abi.rst
> @@ -38,3 +38,4 @@ Examples of Deprecation Notices
>  
>  Deprecation Notices
>  ---
> +* The ABI changes are planned for struct virtio_net in order to support 
> vhost-user multiple queues feature. The upcoming release 2.1 will not contain 
> these ABI changes, but release 2.2 will, and no backwards compatibility is 
> planed due to the vhost-user multiple queues feature enabling. Binaries using 
> this library build prior to version 2.2 will require updating and 
> recompilation.
> -- 
> 1.8.4.2
> 
> 

Acked-by: Neil Horman 

[dpdk-dev] [PATCH v3] kni: Add link status update

[Vijayakumar Muthuvel Manickam]

Implement .ndo_change_carrier to enable
DPDK applications to propagate link state changes to
kni virtual interfaces through sysfs

Signed-off-by: Vijayakumar Muthuvel Manickam 
---
Added kernel version check as .ndo_change_carrier is available only in kernel 
versions 3.9 and after

 lib/librte_eal/linuxapp/kni/kni_net.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/lib/librte_eal/linuxapp/kni/kni_net.c 
b/lib/librte_eal/linuxapp/kni/kni_net.c
index dd95db5..9f9022b 100644
--- a/lib/librte_eal/linuxapp/kni/kni_net.c
+++ b/lib/librte_eal/linuxapp/kni/kni_net.c
@@ -632,6 +632,17 @@ static int kni_net_set_mac(struct net_device *netdev, void 
*p)
return 0;
 }

+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 9, 0))
+static int kni_net_change_carrier(struct net_device *dev, bool new_carrier)
+{
+   if (new_carrier)
+   netif_carrier_on(dev);
+   else
+   netif_carrier_off(dev);
+   return 0;
+}
+#endif
+
 static const struct header_ops kni_net_header_ops = {
.create  = kni_net_header,
.rebuild = kni_net_rebuild_header,
@@ -648,6 +659,9 @@ static const struct net_device_ops kni_net_netdev_ops = {
.ndo_get_stats = kni_net_stats,
.ndo_tx_timeout = kni_net_tx_timeout,
.ndo_set_mac_address = kni_net_set_mac,
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 9, 0))
+   .ndo_change_carrier = kni_net_change_carrier,
+#endif
 };

 void
-- 
1.8.1.4

[dpdk-dev] [PATCH] e1000: enable allmulticast support for VF

[Lu, Wenzhuo]

Hi Yury,
I have comments. I think the function name " igbvf_allmulticast_disable" is a 
little misleading. Because this function will disable not only multicast but 
also unicast, right?
Thanks.

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yury Kylulin
Sent: Thursday, May 28, 2015 10:47 PM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH] e1000: enable allmulticast support for VF

Add support to enable and disable reception of all multicast packets by the VF 
using standard API rte_eth_allmulticast_enable()/rte_eth_allmulticast_disable().

Signed-off-by: Yury Kylulin 
---
 drivers/net/e1000/igb_ethdev.c |   20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c 
index e4b370d..5196bd5 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -135,6 +135,8 @@ static int igbvf_dev_configure(struct rte_eth_dev *dev);  
static int igbvf_dev_start(struct rte_eth_dev *dev);  static void 
igbvf_dev_stop(struct rte_eth_dev *dev);  static void igbvf_dev_close(struct 
rte_eth_dev *dev);
+static void igbvf_allmulticast_enable(struct rte_eth_dev *dev); static 
+void igbvf_allmulticast_disable(struct rte_eth_dev *dev);
 static int eth_igbvf_link_update(struct e1000_hw *hw);  static void 
eth_igbvf_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *rte_stats);  
static void eth_igbvf_stats_reset(struct rte_eth_dev *dev); @@ -280,6 +282,8 @@ 
static const struct eth_dev_ops igbvf_eth_dev_ops = {
.dev_start= igbvf_dev_start,
.dev_stop = igbvf_dev_stop,
.dev_close= igbvf_dev_close,
+   .allmulticast_enable  = igbvf_allmulticast_enable,
+   .allmulticast_disable = igbvf_allmulticast_disable,
.link_update  = eth_igb_link_update,
.stats_get= eth_igbvf_stats_get,
.stats_reset  = eth_igbvf_stats_reset,
@@ -2272,6 +2276,22 @@ igbvf_dev_close(struct rte_eth_dev *dev)
igbvf_dev_stop(dev);
 }

+static void
+igbvf_allmulticast_enable(struct rte_eth_dev *dev) {
+   struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   e1000_promisc_set_vf(hw, e1000_promisc_multicast); }
+
+static void
+igbvf_allmulticast_disable(struct rte_eth_dev *dev) {
+   struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+   e1000_promisc_set_vf(hw, e1000_promisc_disabled); }
+
 static int igbvf_set_vfta(struct e1000_hw *hw, uint16_t vid, bool on)  {
struct e1000_mbx_info *mbx = &hw->mbx;
--
1.7.9.5

[dpdk-dev] [PATCH] ixgbe: fix TSO in IPv6

[Zhang, Helin]

I have replied with its original mail, with minor comment.

- Helin

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, June 15, 2015 5:46 PM
> To: Zhang, Helin; Ananyev, Konstantin
> Cc: dev at dpdk.org; David Marchand
> Subject: Re: [dpdk-dev] [PATCH] ixgbe: fix TSO in IPv6
> 
> Any comment?
> 
> > When TSO is used with IPv6, generated frames are incorrect.
> > L4 frame is OK, but length field of IPv6 header was not populated correctly.
> >
> > Signed-off-by: Didier Pallard 

[dpdk-dev] [PATCH] ixgbe: fix TSO in IPv6

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand
> Sent: Monday, June 1, 2015 8:11 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] ixgbe: fix TSO in IPv6
> 
> From: Didier Pallard 
> 
> When TSO is used with IPv6, generated frames are incorrect.
> L4 frame is OK, but length field of IPv6 header was not populated correctly.
> 
> Signed-off-by: Didier Pallard 
> ---
>  drivers/net/ixgbe/ixgbe_rxtx.c |   13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index 4f9ab22..d123612 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -375,10 +375,15 @@ ixgbe_set_xmit_ctx(struct ixgbe_tx_queue *txq,
> 
>   /* check if TCP segmentation required for this packet */
>   if (ol_flags & PKT_TX_TCP_SEG) {
> - /* implies IP cksum and TCP cksum */
> - type_tucmd_mlhl = IXGBE_ADVTXD_TUCMD_IPV4 |
> - IXGBE_ADVTXD_TUCMD_L4T_TCP |
> - IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
> + /* implies IP cksum in IPv4 */
> + if (ol_flags & PKT_TX_IP_CKSUM)
> + type_tucmd_mlhl = IXGBE_ADVTXD_TUCMD_IPV4 |
> + IXGBE_ADVTXD_TUCMD_L4T_TCP |
> + IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
> + else
> + type_tucmd_mlhl =
I'd prefer to put 'IXGBE_ADVTXD_TUCMD_IPV6' here to indicate it has set for 
IPV6 specifically,
though they are the same. It is clearer for future readers.

- Helin

> + IXGBE_ADVTXD_TUCMD_L4T_TCP |
> + IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
> 
>   tx_offload_mask.l2_len |= ~0;
>   tx_offload_mask.l3_len |= ~0;
> --
> 1.7.10.4

[dpdk-dev] [PATCH 1/3] kni: minor opto

[Zhang, Helin]

Hi Jay

From: Jay Rolette [mailto:role...@infiniteio.com]
Sent: Monday, June 15, 2015 8:43 PM
To: Zhang, Helin
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/3] kni: minor opto

On Sun, Jun 14, 2015 at 9:07 PM, Zhang, Helin mailto:helin.zhang at intel.com>> wrote:
Would it be better to modify the similar thing in kni_ioctl_create()?

That one doesn't need to use the "safe" version of list_for_each_entry() 
either, but it isn't in the packet processing path so the minor performance 
improvement doesn't really matter.
Yes, your patches are OK for me. I have acked it.


-  Helin


- Helin

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On 
> Behalf Of Jay Rolette
> Sent: Thursday, June 4, 2015 3:19 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/3] kni: minor opto
>
> Don't need the 'safe' version of list_for_each_entry() if you aren't deleting 
> from
> the list as you iterate over it
>
> Signed-off-by: Jay Rolette mailto:rolette at 
> infiniteio.com>>
> ---
>  lib/librte_eal/linuxapp/kni/kni_misc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c
> b/lib/librte_eal/linuxapp/kni/kni_misc.c
> index 1935d32..312f196 100644
> --- a/lib/librte_eal/linuxapp/kni/kni_misc.c
> +++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
> @@ -213,13 +213,12 @@ static int
>  kni_thread_single(void *unused)
>  {
>   int j;
> - struct kni_dev *dev, *n;
> + struct kni_dev *dev;
>
>   while (!kthread_should_stop()) {
>   down_read(&kni_list_lock);
>   for (j = 0; j < KNI_RX_LOOP_NUM; j++) {
> - list_for_each_entry_safe(dev, n,
> - &kni_list_head, list) {
> + list_for_each_entry(dev, &kni_list_head, list) {
>  #ifdef RTE_KNI_VHOST
>   kni_chk_vhost_rx(dev);
>  #else
> --
> 2.3.2 (Apple Git-55)

[dpdk-dev] [PATCH 2/3] kni: minor opto

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
> Sent: Thursday, June 4, 2015 3:08 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 2/3] kni: minor opto
> 
> No reason to check out many entries are in kni->rx_q prior to actually pulling
> them from the fifo. You can't dequeue more than are there anyway. Max entries
> to dequeue is either the max batch size or however much space is available on
> kni->free_q (lesser of the two)
> 
> Signed-off-by: Jay Rolette 
Acked-by: Helin Zhang 

> ---
>  lib/librte_eal/linuxapp/kni/kni_net.c | 21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/kni/kni_net.c
> b/lib/librte_eal/linuxapp/kni/kni_net.c
> index dd95db5..13ccbb8 100644
> --- a/lib/librte_eal/linuxapp/kni/kni_net.c
> +++ b/lib/librte_eal/linuxapp/kni/kni_net.c
> @@ -131,7 +131,7 @@ kni_net_rx_normal(struct kni_dev *kni)  {
>   unsigned ret;
>   uint32_t len;
> - unsigned i, num, num_rq, num_fq;
> + unsigned i, num, num_fq;
>   struct rte_kni_mbuf *kva;
>   struct rte_kni_mbuf *va[MBUF_BURST_SZ];
>   void * data_kva;
> @@ -139,24 +139,19 @@ kni_net_rx_normal(struct kni_dev *kni)
>   struct sk_buff *skb;
>   struct net_device *dev = kni->net_dev;
> 
> - /* Get the number of entries in rx_q */
> - num_rq = kni_fifo_count(kni->rx_q);
> -
>   /* Get the number of free entries in free_q */
> - num_fq = kni_fifo_free_count(kni->free_q);
> -
> - /* Calculate the number of entries to dequeue in rx_q */
> - num = min(num_rq, num_fq);
> - num = min(num, (unsigned)MBUF_BURST_SZ);
> -
> - /* Return if no entry in rx_q and no free entry in free_q */
> - if (num == 0)
> + if ((num_fq = kni_fifo_free_count(kni->free_q)) == 0) {
> + /* No room on the free_q, bail out */
>   return;
> + }
> +
> + /* Calculate the number of entries to dequeue from rx_q */
> + num = min(num_fq, (unsigned)MBUF_BURST_SZ);
> 
>   /* Burst dequeue from rx_q */
>   ret = kni_fifo_get(kni->rx_q, (void **)va, num);
>   if (ret == 0)
> - return; /* Failing should not happen */
> + return;
> 
>   /* Transfer received packets to netif */
>   for (i = 0; i < num; i++) {
> --
> 2.3.2 (Apple Git-55)

[dpdk-dev] [PATCH 1/3] kni: minor opto

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
> Sent: Thursday, June 4, 2015 3:08 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/3] kni: minor opto
> 
> Don't need the 'safe' version of list_for_each_entry() if you aren't deleting 
> from
> the list as you iterate over it
> 
> Signed-off-by: Jay Rolette 
Acked-by: Helin Zhang 

> ---
>  lib/librte_eal/linuxapp/kni/kni_misc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/librte_eal/linuxapp/kni/kni_misc.c
> b/lib/librte_eal/linuxapp/kni/kni_misc.c
> index 1935d32..312f196 100644
> --- a/lib/librte_eal/linuxapp/kni/kni_misc.c
> +++ b/lib/librte_eal/linuxapp/kni/kni_misc.c
> @@ -213,13 +213,12 @@ static int
>  kni_thread_single(void *unused)
>  {
>   int j;
> - struct kni_dev *dev, *n;
> + struct kni_dev *dev;
> 
>   while (!kthread_should_stop()) {
>   down_read(&kni_list_lock);
>   for (j = 0; j < KNI_RX_LOOP_NUM; j++) {
> - list_for_each_entry_safe(dev, n,
> - &kni_list_head, list) {
> + list_for_each_entry(dev, &kni_list_head, list) {
>  #ifdef RTE_KNI_VHOST
>   kni_chk_vhost_rx(dev);
>  #else
> --
> 2.3.2 (Apple Git-55)

[dpdk-dev] [RFC PATCH V2 2/2] drivers/net/virtio: check vq parameter

[Ouyang, Changchun]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bernard Iremonger
> Sent: Thursday, May 28, 2015 12:01 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [RFC PATCH V2 2/2] drivers/net/virtio: check vq
> parameter
> 
> If vq is NULL, there is a segmentation fault.
> 
> Signed-off-by: Bernard 

Acked-by: Changchun Ouyang 

[dpdk-dev] [PATCH v7 0/4] Fix vhost enqueue/dequeue issue

[Ouyang, Changchun]

Hi, Thomas


> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, June 15, 2015 5:43 PM
> To: Ouyang, Changchun
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 0/4] Fix vhost enqueue/dequeue issue
> 
> 2015-06-09 09:03, Ouyang Changchun:
> > Fix enqueue/dequeue can't handle chained vring descriptors; Remove
> > unnecessary vring descriptor length updating; Add support copying
> > scattered mbuf to vring;
> >
> > Changchun Ouyang (4):
> >   lib_vhost: Fix enqueue/dequeue can't handle chained vring descriptors
> >   lib_vhost: Refine code style
> >   lib_vhost: Extract function
> >   lib_vhost: Remove unnecessary vring descriptor length updating
> 
> What changed in v7?
> Is this test report still valuable for v7?
>   http://dpdk.org/ml/archives/dev/2015-June/018610.html
> 
Nothing really changed from v6 to v7, 
In V6, signed-off-by root, 
In v7, signed-off-by myself.
Yes, test report is still valuable.

> Note: it's really convenient to put the relevant changelog in each commit,
> and it would be nicer to have a changelog summary in this cover letter.