[dpdk-dev] [PATCH 0/3] mk: fix link options

[Thomas Monjalon]

2014-12-17 22:59, Thomas Monjalon:
> When trying to fix the use of combined library, some bugs have been
> raised. This patchset fix and clean some link options.
> 
> Thomas Monjalon (3):
>   mk: fix link examples to combined library
>   mk: forbid multiple definitions
>   mk: fix link with CC

Applied quickly to validate building before the release.

-- 
Thomas

[dpdk-dev] ethdev: fix out of date comment

[Thomas Monjalon]

2014-12-16 21:47, Stephen Hemminger:
> max_frame_size was replaced with mtu by earlier commit
> 
> Signed-off-by: Stephen Hemminger 

Acked-by: Thomas Monjalon 

Applied with this log:

ethdev: fix mtu comment

In commit 59d0ecdbf0e1d6350 ("MTU accessors"),
max_frame_size was replaced with mtu.
Default size is ETHER_MTU = 1500.

Thanks
-- 
Thomas

[dpdk-dev] [PATCH] kni: fix build on RHEL6.5

[Thomas Monjalon]

2014-12-17 11:26, Jincheng Miao:
> On 12/16/2014 11:21 PM, Thomas Monjalon wrote:
> > 2014-12-11 13:27, Jincheng Miao:
> >> RHEL6.5 kernel is based on 2.6.32. But there are two changing
> >> from 2.6.35:
> >> 1. socket struct is changed
> >> It wrappered previous wait_queue_head_t of socket to
> >> struct socket_wq. So for the kernel older than 2.6.35, we should
> >> directly use socket->wait instead.
> >>
> >> 2. new function sk_sleep()
> >> This function is implemented from 2.6.35 to obtain wait queue
> >> from struct sock. This patch adds a macro in kni/compat.h
> >> to be compatible with older kernels.
> > I don't understand the relation between RHEL-6.5 and the kernel 2.6.35.
> > The patch seems not related to RHEL at all.
> > Please start your explanations by describing what is the problem
> > you want to solve.
> 
> Hi Thomas,
> 
> This patch is working for resolving the problem I found on RHEL6.5:
> http://dpdk.org/ml/archives/dev/2014-December/009827.html
> 
> Because the root cause is socket struct change from 2.6.35, so this
> patch also fits for all kernels older than 2.6.35.
> 
> Sorry for the ambiguous description, I think the title should be:
> "kni: more compatibility for kernel older than 2.6.35"

Applied with title "kni: fix build with kernel < 2.6.35 and vhost debug enabled"
and error log.

Thanks
-- 
Thomas

[dpdk-dev] [PATCH] i40e: fix of compile errors

[Thomas Monjalon]

> Compile warning which is treated as error occurs on Oracle Linux
> (kernel 2.6.39, gcc 4.4.7) as below. Aliasing
> 'struct i40e_aqc_debug_reg_read_write' should be avoided. Use the
> elements inside that structure directly can fix the issue.
> 
> lib/librte_pmd_i40e/i40e_ethdev.c: In function 'eth_i40e_dev_init':
> lib/librte_pmd_i40e/i40e_ethdev.c:5318: error: dereferencing pointer
>   'cmd' does break strict-aliasing rules
> lib/librte_pmd_i40e/i40e_ethdev.c:5314: note: initialized from here
> 
> Signed-off-by: Helin Zhang 

Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH v3 0/3] bond: static analysis issues fix

[Thomas Monjalon]

> -v3:
> Split patches 
> 
> -v2:
> Incorporates Pawel's comments regarding assertion's check on activate_slave 
> array indexing
> 
> Fixes for link bonding library identified by static analysis tool
> 
> - Overflow assert for active_slaves array in activate_slave function
> - Allocation check of pci_id_table in rte_eth_bond_create
> - Use of eth_dev pointer in mac_address_get/set before NULL check
> 
> 
> Declan Doherty (3):
>   bond: add bounds check before assigning active slave count value
>   bond: fix pci_id_table allocation check in rte_eth_bond_create
>   bond: eth_dev parameter used before NULL check mac_address_get/set

Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH 0/5] fix compilation issues seen with clang-3.5

[Thomas Monjalon]

> This series are compilation fixes seen with clang-3.5 on linux.
> 
> Olivier Matz (5):
>   test-devargs: fix misplaced braces in strncmp call
>   examples/l3fwd: fix compilation with clang 3.5
>   examples/netmap: fix overflow in ioctl operation
>   examples/vm_power_manager: move -lvirt in LDLIBS
>   examples/vm_power_manager: fix initialization of cmdline token

Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH] test: fix macro by adding in missing "do" in do-while

[Thomas Monjalon]

2014-12-17 17:06, Bruce Richardson:
> One of the test assertion macros was missing the "do" part of the
> do-while. This issue was picked up by clang reporting an empty while
> loop body for the closing while of the do-while pair.
> 
> Signed-off-by: Bruce Richardson 

Applied

Thanks
-- 
Thomas

[dpdk-dev] [PATCH] examples/vhost: Fix vlan offload issue

[Thomas Monjalon]

2014-12-17 11:04, Thomas Monjalon:
> 2014-12-17 00:51, Ouyang, Changchun:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > 2014-12-12 12:15, Ouyang Changchun:
> > > > The following commit break vm2vm hard mode test cases:
> > > > commit db4014f2b65cb31bf209cadd5bcec778ca137fe2
> > > > Author: Huawei Xie 
> > > > Date:   Thu Nov 13 06:34:07 2014 +0800
> > > > examples/vhost: use factorized default Rx/Tx configuration
> > > >
> > > > Investigation show that it needs enabling vlan offload since it is
> > > > turn off by default, and Tx need it, especially when vm2vm is in hard 
> > > > mode.
> > > 
> > > I missed something here. Where VLAN offload is disabled by default?
> > > Could you point the code, please?
> > 
> > Inside the function ixgbe_dev_info_get()
> > The txq_flags is assigned value of 
> > "ETH_TXQ_FLAGS_MULTISEGS|ETH_TXQ_FLAGS_NOOFFLOADS",
> > The ETH_TXQ_FLAGS_NOOFFLOADS  contain  ETH_TXQ_FLAGS_NOVLANOFFL.
> > so VLAN offload is disabled.
> > 
> > Do you think any incorrect in my original description?
> 
> Yes. You say VLAN offload is turned off by default.
> But it's the case only for ixgbe, i40e and vmxnet3.

Applied with this log change "turn off by default in some drivers"

Thanks
-- 
Thomas

[dpdk-dev] [dpdk-announce] release candidate 1.8.0-rc6

[Thomas Monjalon]

A new DPDK release candidate is ready for testing:
http://dpdk.org/browse/dpdk/tag/?id=v1.8.0-rc6

This release candidate is only 1 day younger than the rc5 and include
some major build fixes around combined library linking.
Please test your applications with various build configurations
(static/shared combined/separated libraries) and various toolchains.

Changelog (main changes since rc5)
- fixes for:
* building
* bond
* unit tests
* examples

Many bugs have been seen with static analyzers.
This kind of tool must definitively be automated in next months.

We are approaching the hard deadline for the release.
Except documentation, the last pending patches are about:
- new Rx error flags
- enic VFIO
- ixgbevf link status
- Xen PMD build
- AF_packet PMD checks
Please review them to help closing these bugs.

Thank you
-- 
Thomas

[dpdk-dev] DPDK RSS support for ixgbevf PMD

[Ouyang, Changchun]

Hi

> -Original Message-
> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
> Sent: Wednesday, December 17, 2014 4:47 PM
> To: Ouyang, Changchun; Thomas Monjalon
> Cc: dev at dpdk.org; Avi Kivity; Gleb Natapov
> Subject: Re: [dpdk-dev] DPDK RSS support for ixgbevf PMD
> 
> 
> On 12/17/14 03:03, Ouyang, Changchun wrote:
> > Hi ,
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
> >> Sent: Tuesday, December 16, 2014 11:36 PM
> >> To: Thomas Monjalon
> >> Cc: dev at dpdk.org; Avi Kivity; Gleb Natapov
> >> Subject: Re: [dpdk-dev] DPDK RSS support for ixgbevf PMD
> >>
> >>
> >> On 12/15/14 22:33, Thomas Monjalon wrote:
> >>> 2014-12-15 21:11, Vladislav Zolotarov:
>  Hi,
>  I'm running an ixgbevf PMD on an AWS guests with extended
>  networking (SR-IOV functions of 82599 Intel's NIC) and noticed that
>  even in the current git tree there is no support for a multi-queue in 
>  this
> PMD:
>  reta size returned by rte_eth_dev_info_get() call is 0, while
>  max_rx_queues and max_tx_queues are both 4.
> 
>  Linux ixgbevf-2.15.3 driver on the other hand successfully
>  initializes 2 RSS queues: for some reason it always limits the
>  number of
> >> RSS queues by 2.
>  ixgbevf_main.c: line 2539
>  u16 rss = min_t(u16, num_online_cpus(), 2);
> 
>  The above is strange since if MRQE is set to 1010b there are 4 RSS
>  queues available which seems to be the case in my AWS Guest.
> 
>  However, let's get back to DPDK. As I've mentioned above the SR-IOV
>  function i have is RSS capable (to be 100% sure I've verified both
>  queues are receiving packets in a multi-socket TCP test). And it's
>  a shame I can't utilize it with a DPDK.
> >>> Yes, it is not yet supported.
> >>> But a patch was recently sent:
> >>>   http://dpdk.org/ml/archives/dev/2014-December/010028.html
> >> Applying this patchset seems to break the NIC fast path functionality
> >> of a AWS Guest NIC.
> >> I'm still debugging it - will update u as soon as I have more specific 
> >> info.
> 
> Hi, thanks for tips but I have a question below.
> 
> > Pls make sure enabling and using 4 queues on guest
> 
> Why should I enable all 4? Won't any number below or equal 4 work if (!)
> 4 queues are available?
> Note that there is a 82599 mode when only 2 RSS queues are available per
> VF: MRQE=1011b.
> 

Yes you are right, it could be 2 queues, the actual queue number per VF depends 
on the number of VF:
VF number from 1~32: 4 queues per VF;
VF number from 33~64:   2 queues per VF;
The queue number is determined by the vf number at the pf init stage,
If pf setup 4 queues for each vf and distribute packets to 4 queues, but vf 
only poll 1 or 2 queue,
Then packets in other queues will be lost.
You can try to poll 4 queues firstly to debug your issue.
Thanks
Changchun

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Cao, Waterman]

Hi Neil,

Can you let me know what configuration you used for XEN Domain U?
Do you able to run some test cases on XEN Domain U?
So far, we met some issues on xenvirt (Domain U). 

Thanks

Waterman 

[dpdk-dev] [PATCH] ixgbe_vf: Fix getting link state

[Choonho Son]

DPDK pmd code should have the consistency with original network device
driver code.

Linux kernel driver---> DPDK pmd driver
---
ixgbevf_check_mac_link_vf()ixgbe_check_mac_link_vf()
 at ixgbevf/vf.cat
librte_pmd_ixgbe/ixgbe/ixgbe_vf.c

ixgbevf_get_settings()  ixgbe_dev_link_update()
 at ixgbevf/ethtool.cat librte_pmd_ixgbe/ixgbe_ethdev.c


In a original device driver, detection link status called by
ixgbevf_get_settings()

hw->mac.get_link_status = 1;
hw->mac.ops.check_link(hw, &link_speed, &link_up, false);

Changing ixgbevf_check_mac_link_vf() will break consistency with original
code.



@ {Linux kernel}/drivers/net/ethernet/intel/ixgbevf/vf.c
static s32 ixgbevf_check_mac_link_vf(struct ixgbe_hw *hw,
 ixgbe_link_speed *speed,
 bool *link_up,
 bool autoneg_wait_to_complete)
{
struct ixgbe_mbx_info *mbx = &hw->mbx;
struct ixgbe_mac_info *mac = &hw->mac;
s32 ret_val = 0;
u32 links_reg;
u32 in_msg = 0;

/* If we were hit with a reset drop the link */
if (!mbx->ops.check_for_rst(hw) || !mbx->timeout)
mac->get_link_status = true;

if (!mac->get_link_status)
goto out;



@ {DPDK}/lib/librte_pmd_ixgbe/ixgbe/ixgbe_vf.c
s32 ixgbe_check_mac_link_vf(struct ixgbe_hw *hw, ixgbe_link_speed *speed,
bool *link_up, bool autoneg_wait_to_complete)
{
struct ixgbe_mbx_info *mbx = &hw->mbx;
struct ixgbe_mac_info *mac = &hw->mac;
s32 ret_val = IXGBE_SUCCESS;
u32 links_reg;
u32 in_msg = 0;
UNREFERENCED_1PARAMETER(autoneg_wait_to_complete);

/* If we were hit with a reset drop the link */
if (!mbx->ops.check_for_rst(hw, 0) || !mbx->timeout)
mac->get_link_status = true;

if (!mac->get_link_status)
goto out;



@ {Linux kernel}/drivers/net/ethernet/intel/ixgbevf/ethtool.c
static int ixgbevf_get_settings(struct net_device *netdev,
struct ethtool_cmd *ecmd)
{
struct ixgbevf_adapter *adapter = netdev_priv(netdev);
struct ixgbe_hw *hw = &adapter->hw;
u32 link_speed = 0;
bool link_up;

ecmd->supported = SUPPORTED_1baseT_Full;
ecmd->autoneg = AUTONEG_DISABLE;
ecmd->transceiver = XCVR_DUMMY1;
ecmd->port = -1;

hw->mac.get_link_status = 1;
hw->mac.ops.check_link(hw, &link_speed, &link_up, false);

if (link_up) {
__u32 speed = SPEED_1;
switch (link_speed) {



@ {DPDK}/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
/* return 0 means link status changed, -1 means not changed */
static int
ixgbe_dev_link_update(struct rte_eth_dev *dev, int wait_to_complete)
{
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_eth_link link, old;
ixgbe_link_speed link_speed;
int link_up;
int diag;

link.link_status = 0;
link.link_speed = 0;
link.link_duplex = 0;
memset(&old, 0, sizeof(old));
rte_ixgbe_dev_atomic_read_link_status(dev, &old);

/* 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;





2014-12-17 22:24 GMT+09:00 Thomas Monjalon :
>
> 2014-12-17 13:22, Balazs Nemeth:
> > This patch fixes checking the link state of a virtual function. If the
> > state has already been checked, it does not need to be checked
> > again. Previously, get_link_status in the ixgbe_hw struct was
> > used to track if the information had already been updated, but this
> > field was always set to false.
> >
> > Signed-off-by: Balazs Nemeth 
>
> This is the third patch about link status fix in ixgbevf.
> Please comment the other ones in the respective mailing threads:
> http://dpdk.org/dev/patchwork/patch/1079
> http://dpdk.org/dev/patchwork/patch/1224
> Are they superseded by yours?
>
> --
> Thomas
>

[dpdk-dev] [PATCH] kni: fix build for CentOS 6.6

[Jincheng Miao]

>From CentOS 6.6, function skb_set_hash is introduced, this breaks
the previous assumption. So modify RHEL_RELEASE_VERSION from 7.0
to 6.6 to fix build for rte_kni.ko.

Related mail from Barak Enat:
http://dpdk.org/ml/archives/dev/2014-December/010124.html

building error likes:
  CC [M]  
/root/dpdk-source/build/build/lib/librte_eal/linuxapp/kni/e1000_82575.o
In file included from 
/root/dpdk-source/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_osdep.h:41,
 from 
/root/dpdk-source/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_hw.h:31,
 from 
/root/dpdk-source/lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_api.h:31,
 from 
/root/dpdk-source/build/build/lib/librte_eal/linuxapp/kni/e1000_82575.c:38:
/root/dpdk-source/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3870: 
error: conflicting types for ?skb_set_hash?
include/linux/skbuff.h:620: note: previous definition of ?skb_set_hash? was here
make[8]: *** 
[/root/dpdk-source/build/build/lib/librte_eal/linuxapp/kni/e1000_82575.o] Error 
1

Signed-off-by: Jincheng Miao 
---
 lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h 
b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
index 3dbc07a..1213cc6 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
@@ -3860,7 +3860,7 @@ static inline struct sk_buff 
*__kc__vlan_hwaccel_put_tag(struct sk_buff *skb,
 #endif /* >= 3.10.0 */

 #if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,14,0) )
-#if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,0)))
+#if (!(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(6,6)))
 #if (!(UBUNTU_KERNEL_CODE >= UBUNTU_KERNEL_VERSION(3,13,0,30,54) \
 && (UBUNTU_RELEASE_CODE == UBUNTU_RELEASE_VERSION(12,4) \
  || UBUNTU_RELEASE_CODE == UBUNTU_RELEASE_VERSION(14,4
-- 
1.7.1

[dpdk-dev] Symmetric RSS Hashing in DPDK

[Jim Thompson]

The issues are outlined in this paper: 
http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf

> On Dec 17, 2014, at 7:28 PM, Kamraan Nasim  
> wrote:
> 
> Hi DPDK community,
> 
> Any better RSS hash keys out there?
> 
> --Kam
> 
> On Wed, Dec 17, 2014 at 2:12 PM, Kamraan Nasim  sidebandnetworks.com>
> wrote:
>> 
>> Thank you Jeriel. 0x00 0x01 works and I can get bi-directional symmetry
>> but you are right, it compromises the packet distribution. I am seeing
>> vastly different 5 tuples hashed with the same value.
>> 
>> Will let you know if I find a better alternative.
>> 
>> --Kam
>> 
>> On Tue, Dec 16, 2014 at 5:17 PM, Jeriel Smith  wrote:
>>> 
>>> Hi Kamraan,
>>>  Even i noticed it with "0x6d5a". Currently, I use a continuous
>>> pattern of "0x00 0x01" which helps in getting a symmetrical hashing. But,
>>> the packet spraying is not that good as "0x6d5a". Please let me know if you
>>> find a alternative.
>>> Thanks,
>>> Jeriel
>>> 
>>> 
 -- Forwarded message --
 From: Kamraan Nasim 
 Date: Tue, Dec 16, 2014 at 11:52 AM
 Subject: [dpdk-dev] Symmetric RSS Hashing in DPDK
 To: dev at dpdk.org
 Cc: Steve Noble , Jun Du <
 jdu at sidebandnetworks.com>, Ashish Juneja >>> sidebandnetworks.com>
 
 Hello,
 
 My DPDK application requires bidirectional TCP flows to have the same RSS
 hash however default RSS hashing is *asymmetric*.
 
 
 There are posts such as:
 http://dpdk.info/ml/archives/dev/2014-February/001460.html
 
 which point to a symmetric RSS key(0x6d5a). I have tried using it but it
 is
 still hashing bi-directional flows separately. I am using an 82599 NIC.
 
 Have others come across this? What other options are available(I presume
 S/W hashing)?
 
 Appreciate any help I can get on this :)
 
 #define RSS_HASH_KEY_LENGTH 40
 static uint8_t hash_key[RSS_HASH_KEY_LENGTH] = {
0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
 };
 // ethernet rx config
 static struct rte_eth_conf port_conf = {
.rxmode = {
.mq_mode= ETH_MQ_RX_RSS,
.split_hdr_size = 0,
.header_split   = 0, /**< Header Split disabled */
.hw_ip_checksum = 1, /**< IP checksum offload enabled */
.hw_vlan_filter = 0, /**< VLAN filtering disabled */
.jumbo_frame= 0, /**< Jumbo Frame Support disabled */
.hw_strip_crc   = 0, /**< CRC stripped by hardware */
},
.rx_adv_conf = {
.rss_conf = {
.rss_key = hash_key,
.rss_hf  = ETH_RSS_PROTO_MASK,
},
},
.txmode = {
.mq_mode = ETH_MQ_TX_NONE,
},
 };
 
 
 Thanks,
 Kam
 
>>> 

[dpdk-dev] Symmetric RSS Hashing in DPDK

[Zhang, Helin]

Hi guys

I40e has hardware offload of symmetric hashing. Patch set has been sent out 
during R1.8 time slot, but it will be in R2.0.

Regards,
Helin

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jim Thompson
> Sent: Thursday, December 18, 2014 2:56 PM
> To: Kamraan Nasim
> Cc: dev at dpdk.org; Steve Noble; Jeriel Smith
> Subject: Re: [dpdk-dev] Symmetric RSS Hashing in DPDK
> 
> 
> The issues are outlined in this paper:
> http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf
> 
> > On Dec 17, 2014, at 7:28 PM, Kamraan Nasim
>  wrote:
> >
> > Hi DPDK community,
> >
> > Any better RSS hash keys out there?
> >
> > --Kam
> >
> > On Wed, Dec 17, 2014 at 2:12 PM, Kamraan Nasim
> > 
> > wrote:
> >>
> >> Thank you Jeriel. 0x00 0x01 works and I can get bi-directional
> >> symmetry but you are right, it compromises the packet distribution. I
> >> am seeing vastly different 5 tuples hashed with the same value.
> >>
> >> Will let you know if I find a better alternative.
> >>
> >> --Kam
> >>
> >> On Tue, Dec 16, 2014 at 5:17 PM, Jeriel Smith  
> >> wrote:
> >>>
> >>> Hi Kamraan,
> >>>  Even i noticed it with "0x6d5a". Currently, I use a continuous
> >>> pattern of "0x00 0x01" which helps in getting a symmetrical hashing.
> >>> But, the packet spraying is not that good as "0x6d5a". Please let me
> >>> know if you find a alternative.
> >>> Thanks,
> >>> Jeriel
> >>>
> >>>
>  -- Forwarded message --
>  From: Kamraan Nasim 
>  Date: Tue, Dec 16, 2014 at 11:52 AM
>  Subject: [dpdk-dev] Symmetric RSS Hashing in DPDK
>  To: dev at dpdk.org
>  Cc: Steve Noble , Jun Du <
>  jdu at sidebandnetworks.com>, Ashish Juneja
>  
> 
>  Hello,
> 
>  My DPDK application requires bidirectional TCP flows to have the
>  same RSS hash however default RSS hashing is *asymmetric*.
> 
> 
>  There are posts such as:
>  http://dpdk.info/ml/archives/dev/2014-February/001460.html
> 
>  which point to a symmetric RSS key(0x6d5a). I have tried using it
>  but it is still hashing bi-directional flows separately. I am using
>  an 82599 NIC.
> 
>  Have others come across this? What other options are available(I
>  presume S/W hashing)?
> 
>  Appreciate any help I can get on this :)
> 
>  #define RSS_HASH_KEY_LENGTH 40
>  static uint8_t hash_key[RSS_HASH_KEY_LENGTH] = {
> 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
> 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
> 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
> 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
> 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A, }; //
>  ethernet rx config static struct rte_eth_conf port_conf = {
> .rxmode = {
> .mq_mode= ETH_MQ_RX_RSS,
> .split_hdr_size = 0,
> .header_split   = 0, /**< Header Split disabled */
> .hw_ip_checksum = 1, /**< IP checksum offload enabled */
> .hw_vlan_filter = 0, /**< VLAN filtering disabled */
> .jumbo_frame= 0, /**< Jumbo Frame Support disabled */
> .hw_strip_crc   = 0, /**< CRC stripped by hardware */
> },
> .rx_adv_conf = {
> .rss_conf = {
> .rss_key = hash_key,
> .rss_hf  = ETH_RSS_PROTO_MASK,
> },
> },
> .txmode = {
> .mq_mode = ETH_MQ_TX_NONE,
> },
>  };
> 
> 
>  Thanks,
>  Kam
> 
> >>>

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Olivier MATZ]

Hi Neil,

On 12/17/2014 06:03 PM, Neil Horman wrote:
> Back in:
> 
> commit aaa662e75c23c61a1d79bd4d1f9f35b4967c39db
> Author: Alan Carew 
> Date:   Fri Dec 5 15:19:07 2014 +0100
> 
> cmdline: fix overflow on bsd
> 
> The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  This
> patch makes the needed correction to avoid a build break
> 
> Signed-off-by: Neil Horman 

Sorry, I missed that one, thank you for fixing it.

Acked-by: Olivier Matz 

[dpdk-dev] Symmetric RSS Hashing in DPDK

[Franck Baudin]

On 12/18/14 07:55, Jim Thompson wrote:
> The issues are outlined in this paper: 
> http://www.ndsl.kaist.edu/~shinae/papers/TR-symRSS.pdf

If the RSS scope is limited to IP addresses (2-tuple instead of a 
5-tuple), do we have a symmetric distribution with the default RSS key 
provided by DPDK with 82599 NICs?

Thanks,
Franck

[dpdk-dev] [PATCH] enic: remove code under VFIO_PRESENT and use eal code for interrupts

[Sujith Sankar]

This patch removes the interrupt registration code which was under the flag 
VFIO_PRESENT 
and relies on the rte_lib code for the same.  This also ignores the initial 
trigger of
ISR from the lib.

Signed-off-by: Sujith Sankar 
---
 lib/librte_pmd_enic/enic_main.c | 117 
 1 file changed, 117 deletions(-)

diff --git a/lib/librte_pmd_enic/enic_main.c b/lib/librte_pmd_enic/enic_main.c
index e4f43c5..8ab8e44 100644
--- a/lib/librte_pmd_enic/enic_main.c
+++ b/lib/librte_pmd_enic/enic_main.c
@@ -567,7 +567,6 @@ enic_intr_handler(__rte_unused struct rte_intr_handle 
*handle,
 {
struct enic *enic = pmd_priv((struct rte_eth_dev *)arg);

-   dev_err(enic, "Err intr.\n");
vnic_intr_return_all_credits(&enic->intr);

enic_log_q_error(enic);
@@ -605,13 +604,11 @@ int enic_enable(struct enic *enic)

vnic_dev_enable_wait(enic->vdev);

-#ifndef VFIO_PRESENT
/* Register and enable error interrupt */
rte_intr_callback_register(&(enic->pdev->intr_handle),
enic_intr_handler, (void *)enic->rte_dev);

rte_intr_enable(&(enic->pdev->intr_handle));
-#endif
vnic_intr_unmask(&enic->intr);

return 0;
@@ -969,31 +966,6 @@ int enic_setup_finish(struct enic *enic)
return 0;
 }

-#ifdef VFIO_PRESENT
-static void enic_eventfd_init(struct enic *enic)
-{
-   enic->eventfd = enic->pdev->intr_handle.fd;
-}
-
-void *enic_err_intr_handler(void *arg)
-{
-   struct enic *enic = (struct enic *)arg;
-   unsigned int intr = enic_msix_err_intr(enic);
-   ssize_t size;
-   uint64_t data;
-
-   while (1) {
-   size = read(enic->eventfd, &data, sizeof(data));
-   dev_err(enic, "Err intr.\n");
-   vnic_intr_return_all_credits(&enic->intr);
-
-   enic_log_q_error(enic);
-   }
-
-   return NULL;
-}
-#endif
-
 void enic_add_packet_filter(struct enic *enic)
 {
/* Args -> directed, multicast, broadcast, promisc, allmulti */
@@ -1006,87 +978,12 @@ int enic_get_link_status(struct enic *enic)
return vnic_dev_link_status(enic->vdev);
 }

-
-#ifdef VFIO_PRESENT
-static int enic_create_err_intr_thread(struct enic *enic)
-{
-   pthread_attr_t intr_attr;
-
-   /* create threads for error interrupt handling */
-   pthread_attr_init(&intr_attr);
-   pthread_attr_setstacksize(&intr_attr, 0x10);
-
-   /* ERR */
-   if (pthread_create(&enic->err_intr_thread, &intr_attr,
-   enic_err_intr_handler, (void *)enic)) {
-   dev_err(enic, "Failed to create err interrupt handler 
threads\n");
-   return -1;
-   }
-
-   pthread_attr_destroy(&intr_attr);
-
-   return 0;
-}
-
-
-static int enic_set_intr_mode(struct enic *enic)
-{
-   struct vfio_irq_set *irq_set;
-   int *fds;
-   int size;
-   int ret = -1;
-   int index;
-
-   if (enic->intr_count < 1) {
-   dev_err(enic, "Unsupported resource conf.\n");
-   return -1;
-   }
-   vnic_dev_set_intr_mode(enic->vdev, VNIC_DEV_INTR_MODE_MSIX);
-
-   enic->intr_count = 1;
-
-   enic_eventfd_init(enic);
-   size = sizeof(*irq_set) + (sizeof(int));
-
-   irq_set = rte_zmalloc("enic_vfio_irq", size, 0);
-   irq_set->argsz = size;
-   irq_set->index = VFIO_PCI_MSIX_IRQ_INDEX;
-   irq_set->start = 0;
-   irq_set->count = 1; /* For error interrupt only */
-   irq_set->flags = VFIO_IRQ_SET_DATA_EVENTFD |
-   VFIO_IRQ_SET_ACTION_TRIGGER;
-   fds = (int *)&irq_set->data;
-
-   fds[0] = enic->eventfd;
-
-   ret = ioctl(enic->pdev->intr_handle.vfio_dev_fd,
-   VFIO_DEVICE_SET_IRQS, irq_set);
-   rte_free(irq_set);
-   if (ret) {
-   dev_err(enic, "Failed to set eventfds for interrupts\n");
-   return -1;
-   }
-
-   enic_create_err_intr_thread(enic);
-   return 0;
-}
-
-static void enic_clear_intr_mode(struct enic *enic)
-{
-   vnic_dev_set_intr_mode(enic->vdev, VNIC_DEV_INTR_MODE_UNKNOWN);
-}
-#endif
-
 static void enic_dev_deinit(struct enic *enic)
 {
struct rte_eth_dev *eth_dev = enic->rte_dev;

if (eth_dev->data->mac_addrs)
rte_free(eth_dev->data->mac_addrs);
-
-#ifdef VFIO_PRESENT
-   enic_clear_intr_mode(enic);
-#endif
 }


@@ -1139,20 +1036,6 @@ static int enic_dev_init(struct enic *enic)
*/
enic_get_res_counts(enic);

-#ifdef VFIO_PRESENT
-   /* Set interrupt mode based on resource counts and system
-* capabilities
-*/
-   err = enic_set_intr_mode(enic);
-   if (err) {
-   rte_free(eth_dev->data->mac_addrs);
-   enic_clear_intr_mode(enic);
-   dev_err(dev, "Failed to set intr mode based on resource "\
-   "counts and system capabilities, aborting\n");
-   return err;
-   }
-#endif
-
vnic_dev_set_reset_fla

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Olivier MATZ]

Hi,

On 12/18/2014 09:40 AM, Olivier MATZ wrote:
> Hi Neil,
> 
> On 12/17/2014 06:03 PM, Neil Horman wrote:
>> Back in:
>>
>> commit aaa662e75c23c61a1d79bd4d1f9f35b4967c39db
>> Author: Alan Carew 
>> Date:   Fri Dec 5 15:19:07 2014 +0100
>>
>> cmdline: fix overflow on bsd
>>
>> The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  
>> This
>> patch makes the needed correction to avoid a build break
>>
>> Signed-off-by: Neil Horman 
> 
> Sorry, I missed that one, thank you for fixing it.
> 
> Acked-by: Olivier Matz 

Hmm, I agree with Thomas that sizeof(dict->addr) would be better
as it explicitly uses the length of the field we write into.

Regards,
Olivier

[dpdk-dev] [PATCH 5/6] ixgbe: Config VF RSS

[Vlad Zolotarov]

On 12/18/14 11:58, Vlad Zolotarov wrote:
> From: Changchun Ouyang 
>
> It needs config RSS and IXGBE_MRQC and IXGBE_VFPSRTYPE to enable VF RSS.
>
> Signed-off-by: Changchun Ouyang 
> ---
>   lib/librte_pmd_ixgbe/ixgbe_pf.c   | 15 +
>   lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 66 
> +--
>   2 files changed, 71 insertions(+), 10 deletions(-)
>
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_pf.c b/lib/librte_pmd_ixgbe/ixgbe_pf.c
> index cbb0145..9c9dad8 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_pf.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_pf.c
> @@ -187,6 +187,21 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
>   IXGBE_WRITE_REG(hw, IXGBE_MPSAR_LO(hw->mac.num_rar_entries), 0);
>   IXGBE_WRITE_REG(hw, IXGBE_MPSAR_HI(hw->mac.num_rar_entries), 0);
>
> + /*
> +  * VF RSS can support at most 4 queues for each VF, even if
> +  * 8 queues are available for each VF, it need refine to 4
> +  * queues here due to this limitation, otherwise no queue
> +  * will receive any packet even RSS is enabled.
> +  */
> + if (eth_dev->data->dev_conf.rxmode.mq_mode == ETH_MQ_RX_VMDQ_RSS) {
> + if (RTE_ETH_DEV_SRIOV(eth_dev).nb_q_per_pool == 8) {
> + RTE_ETH_DEV_SRIOV(eth_dev).active = ETH_32_POOLS;
> + RTE_ETH_DEV_SRIOV(eth_dev).nb_q_per_pool = 4;
> + RTE_ETH_DEV_SRIOV(eth_dev).def_pool_q_idx =
> + dev_num_vf(eth_dev) * 4;
> + }
> + }
> +
>   /* set VMDq map to default PF pool */
>   hw->mac.ops.set_vmdq(hw, 0, RTE_ETH_DEV_SRIOV(eth_dev).def_vmdq_idx);
>
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c 
> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> index f58f98e..5d071b4 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> @@ -3327,6 +3327,39 @@ ixgbe_alloc_rx_queue_mbufs(struct igb_rx_queue *rxq)
>   }
>
>   static int
> +ixgbe_config_vf_rss(struct rte_eth_dev *dev)
> +{
> + struct ixgbe_hw *hw;
> + uint32_t mrqc;
> +
> + ixgbe_rss_configure(dev);
> +
> + hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> + /* MRQC: enable VF RSS */
> + mrqc = IXGBE_READ_REG(hw, IXGBE_MRQC);
> + mrqc &= ~IXGBE_MRQC_MRQE_MASK;
> + switch (RTE_ETH_DEV_SRIOV(dev).active) {
> + case ETH_64_POOLS:
> + mrqc |= IXGBE_MRQC_VMDQRSS64EN;
> + break;
> +
> + case ETH_32_POOLS:
> + case ETH_16_POOLS:
> + mrqc |= IXGBE_MRQC_VMDQRSS32EN;
> + break;
> +
> + default:
> + PMD_INIT_LOG(ERR, "Invalid pool number in IOV mode");
> + return -EINVAL;
> + }
> +
> + IXGBE_WRITE_REG(hw, IXGBE_MRQC, mrqc);
> +
> + return 0;
> +}
> +
> +static int
>   ixgbe_dev_mq_rx_configure(struct rte_eth_dev *dev)
>   {
>   struct ixgbe_hw *hw =
> @@ -3358,24 +3391,34 @@ ixgbe_dev_mq_rx_configure(struct rte_eth_dev *dev)
>   default: ixgbe_rss_disable(dev);
>   }
>   } else {
> - switch (RTE_ETH_DEV_SRIOV(dev).active) {
>   /*
>* SRIOV active scheme
>* FIXME if support DCB/RSS together with VMDq & SRIOV
>*/
> - case ETH_64_POOLS:
> - IXGBE_WRITE_REG(hw, IXGBE_MRQC, IXGBE_MRQC_VMDQEN);
> + switch (dev->data->dev_conf.rxmode.mq_mode) {
> + case ETH_MQ_RX_RSS:
> + case ETH_MQ_RX_VMDQ_RSS:
> + ixgbe_config_vf_rss(dev);
>   break;
>
> - case ETH_32_POOLS:
> - IXGBE_WRITE_REG(hw, IXGBE_MRQC, IXGBE_MRQC_VMDQRT4TCEN);
> - break;
> + default:
> + switch (RTE_ETH_DEV_SRIOV(dev).active) {
> + case ETH_64_POOLS:
> + IXGBE_WRITE_REG(hw, IXGBE_MRQC, 
> IXGBE_MRQC_VMDQEN);
> + break;
>
> - case ETH_16_POOLS:
> - IXGBE_WRITE_REG(hw, IXGBE_MRQC, IXGBE_MRQC_VMDQRT8TCEN);
> + case ETH_32_POOLS:
> + IXGBE_WRITE_REG(hw, IXGBE_MRQC, 
> IXGBE_MRQC_VMDQRT4TCEN);
> + break;
> +
> + case ETH_16_POOLS:
> + IXGBE_WRITE_REG(hw, IXGBE_MRQC, 
> IXGBE_MRQC_VMDQRT8TCEN);
> + break;
> + default:
> + PMD_INIT_LOG(ERR, "invalid pool number in IOV 
> mode");
> + break;
> + }
>   break;
> - default:
> - PMD_INIT_LOG(ERR, "invalid pool number in IOV mode");
>   }
>   }
>
> @@ -4094,6 +4137,9 @@ ixgbevf_dev_rx_init(struct rte_eth_dev *dev)
>   IXGBE_PSRTYPE_IPV6HDR;
>   #endif
>
> + /* Set RQPL for VF RSS according to 

[dpdk-dev] [PATCH] ixgbe: fix segmentation fault when start secondary process

[Michael Qiu]

EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
EAL:   PCI memory mapped at 0x7f18c2a0
EAL:   PCI memory mapped at 0x7f18c2a8
Segmentation fault (core dumped)

This is introduced by commit: 46bc9d75
ixgbe: fix multi-process support
When start primary process with command line:
./app/test/test -n 1 -c  -m 64
then start the second one:
./app/test/test -n 1 --proc-type=secondary --file-prefix=rte
This segment-fault will occur.

Root cause is test app on primary process only starts device, but
the queue need initialized by manually command line.
So the tx queue is still NULL when secondary process startup.

Reported-by: Yong Liu 
Signed-off-by: Michael Qiu 
---
 lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c 
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
index 9401916..87ed6ee 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
@@ -749,9 +749,19 @@ eth_ixgbe_dev_init(__attribute__((unused)) struct 
eth_driver *eth_drv,
 */
if (rte_eal_process_type() != RTE_PROC_PRIMARY){
struct igb_tx_queue *txq;
-   /* TX queue function in primary, set by last queue initialized 
*/
-   txq = eth_dev->data->tx_queues[eth_dev->data->nb_tx_queues-1];
-   set_tx_function(eth_dev, txq);
+   /* TX queue function in primary, set by last queue initialized
+* Tx queue may not initialized by primary process
+* */
+   if (eth_dev->data->tx_queues) {
+   txq = 
eth_dev->data->tx_queues[eth_dev->data->nb_tx_queues-1];
+   set_tx_function(eth_dev, txq);
+   } else {
+   /* Shall we exit this process if we get here? */
+   PMD_INIT_LOG(INFO, "Last tx queue initialized fail in "
+"secondary process, please verify if tx "
+"queues were initialized in primary "
+"process!\n");
+   }

if (eth_dev->data->scattered_rx)
eth_dev->rx_pkt_burst = ixgbe_recv_scattered_pkts;
-- 
1.9.3

[dpdk-dev] [PATCH] ixgbe: fix segmentation fault when start secondary process

[Qiu, Michael]

On 12/18/2014 6:17 PM, Qiu, Michael wrote:
> EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
> EAL:   PCI memory mapped at 0x7f18c2a0
> EAL:   PCI memory mapped at 0x7f18c2a8
> Segmentation fault (core dumped)
>
> This is introduced by commit: 46bc9d75
>   ixgbe: fix multi-process support
> When start primary process with command line:
> ./app/test/test -n 1 -c  -m 64
> then start the second one:
> ./app/test/test -n 1 --proc-type=secondary --file-prefix=rte
> This segment-fault will occur.
>
> Root cause is test app on primary process only starts device, but
> the queue need initialized by manually command line.
> So the tx queue is still NULL when secondary process startup.
>
> Reported-by: Yong Liu 
> Signed-off-by: Michael Qiu 
> ---
>  lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c 
> b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> index 9401916..87ed6ee 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> @@ -749,9 +749,19 @@ eth_ixgbe_dev_init(__attribute__((unused)) struct 
> eth_driver *eth_drv,
>*/
>   if (rte_eal_process_type() != RTE_PROC_PRIMARY){
>   struct igb_tx_queue *txq;
> - /* TX queue function in primary, set by last queue initialized 
> */
> - txq = eth_dev->data->tx_queues[eth_dev->data->nb_tx_queues-1];
> - set_tx_function(eth_dev, txq);
> + /* TX queue function in primary, set by last queue initialized
> +  * Tx queue may not initialized by primary process
> +  * */
> + if (eth_dev->data->tx_queues) {
> + txq = 
> eth_dev->data->tx_queues[eth_dev->data->nb_tx_queues-1];
> + set_tx_function(eth_dev, txq);
> + } else {
> + /* Shall we exit this process if we get here? */

I'm just not sure if it is better to terminated when Tx queues are NULL
in secondary process.

Thanks
Michael
> + PMD_INIT_LOG(INFO, "Last tx queue initialized fail in "
> +  "secondary process, please verify if tx "
> +  "queues were initialized in primary "
> +  "process!\n");
> + }
>  
>   if (eth_dev->data->scattered_rx)
>   eth_dev->rx_pkt_burst = ixgbe_recv_scattered_pkts;

[dpdk-dev] [PATCH] ixgbe: fix segmentation fault when start secondary process

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qiu, Michael
> Sent: Thursday, December 18, 2014 10:22 AM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] ixgbe: fix segmentation fault when start
> secondary process
> 
> On 12/18/2014 6:17 PM, Qiu, Michael wrote:
> > EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
> > EAL:   PCI memory mapped at 0x7f18c2a0
> > EAL:   PCI memory mapped at 0x7f18c2a8
> > Segmentation fault (core dumped)
> >
> > This is introduced by commit: 46bc9d75
> > ixgbe: fix multi-process support
> > When start primary process with command line:
> > ./app/test/test -n 1 -c  -m 64
> > then start the second one:
> > ./app/test/test -n 1 --proc-type=secondary --file-prefix=rte
> > This segment-fault will occur.
> >
> > Root cause is test app on primary process only starts device, but
> > the queue need initialized by manually command line.
> > So the tx queue is still NULL when secondary process startup.
> >
> > Reported-by: Yong Liu 
> > Signed-off-by: Michael Qiu 
> > ---
> >  lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 16 +---
> >  1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> > index 9401916..87ed6ee 100644
> > --- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> > +++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> > @@ -749,9 +749,19 @@ eth_ixgbe_dev_init(__attribute__((unused))
> struct eth_driver *eth_drv,
> >  */
> > if (rte_eal_process_type() != RTE_PROC_PRIMARY){
> > struct igb_tx_queue *txq;
> > -   /* TX queue function in primary, set by last queue initialized
> */
> > -   txq = eth_dev->data->tx_queues[eth_dev->data-
> >nb_tx_queues-1];
> > -   set_tx_function(eth_dev, txq);
> > +   /* TX queue function in primary, set by last queue initialized
> > +* Tx queue may not initialized by primary process
> > +* */
> > +   if (eth_dev->data->tx_queues) {
> > +   txq = eth_dev->data->tx_queues[eth_dev->data-
> >nb_tx_queues-1];
> > +   set_tx_function(eth_dev, txq);
> > +   } else {
> > +   /* Shall we exit this process if we get here? */
> 
> I'm just not sure if it is better to terminated when Tx queues are NULL
> in secondary process.
> 
Well, in case of test app, it does not need any ports, so it should work anyway.
Probably it does not make much sense to run two test processes in general,
although it is used in multiprocess unit test.

So, I would say that app should not terminate.
> Thanks
> Michael
> > +   PMD_INIT_LOG(INFO, "Last tx queue initialized fail in
> "
> > +"secondary process, please verify if tx "
> > +"queues were initialized in primary "
> > +"process!\n");
> > +   }
> >
> > if (eth_dev->data->scattered_rx)
> > eth_dev->rx_pkt_burst =
> ixgbe_recv_scattered_pkts;

[dpdk-dev] [PATCH] ixgbe: fix segmentation fault when start secondary process

[Bruce Richardson]

On Thu, Dec 18, 2014 at 10:22:28AM +, Qiu, Michael wrote:
> On 12/18/2014 6:17 PM, Qiu, Michael wrote:
> > EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
> > EAL:   PCI memory mapped at 0x7f18c2a0
> > EAL:   PCI memory mapped at 0x7f18c2a8
> > Segmentation fault (core dumped)
> >
> > This is introduced by commit: 46bc9d75
> > ixgbe: fix multi-process support
> > When start primary process with command line:
> > ./app/test/test -n 1 -c  -m 64
> > then start the second one:
> > ./app/test/test -n 1 --proc-type=secondary --file-prefix=rte
> > This segment-fault will occur.
> >
> > Root cause is test app on primary process only starts device, but
> > the queue need initialized by manually command line.
> > So the tx queue is still NULL when secondary process startup.
> >
> > Reported-by: Yong Liu 
> > Signed-off-by: Michael Qiu 
> > ---
> >  lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 16 +---
> >  1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c 
> > b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> > index 9401916..87ed6ee 100644
> > --- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> > +++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> > @@ -749,9 +749,19 @@ eth_ixgbe_dev_init(__attribute__((unused)) struct 
> > eth_driver *eth_drv,
> >  */
> > if (rte_eal_process_type() != RTE_PROC_PRIMARY){
> > struct igb_tx_queue *txq;
> > -   /* TX queue function in primary, set by last queue initialized 
> > */
> > -   txq = eth_dev->data->tx_queues[eth_dev->data->nb_tx_queues-1];
> > -   set_tx_function(eth_dev, txq);
> > +   /* TX queue function in primary, set by last queue initialized
> > +* Tx queue may not initialized by primary process
> > +* */
> > +   if (eth_dev->data->tx_queues) {
> > +   txq = 
> > eth_dev->data->tx_queues[eth_dev->data->nb_tx_queues-1];
> > +   set_tx_function(eth_dev, txq);
> > +   } else {
> > +   /* Shall we exit this process if we get here? */
> 
> I'm just not sure if it is better to terminated when Tx queues are NULL
> in secondary process.
> 
> Thanks
> Michael

No, don't terminate. Printing a message is enough.


> > +   PMD_INIT_LOG(INFO, "Last tx queue initialized fail in "
> > +"secondary process, please verify if tx "
> > +"queues were initialized in primary "
> > +"process!\n");
> > +   }

Maybe shorten message to: "No TX queues configured yet. Using default TX 
function."

> >  
> > if (eth_dev->data->scattered_rx)
> > eth_dev->rx_pkt_burst = ixgbe_recv_scattered_pkts;
> 
> 

[dpdk-dev] DPDK RSS support for ixgbevf PMD

[Vlad Zolotarov]

On 12/18/14 03:32, Ouyang, Changchun wrote:
> Hi
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Wednesday, December 17, 2014 4:47 PM
>> To: Ouyang, Changchun; Thomas Monjalon
>> Cc: dev at dpdk.org; Avi Kivity; Gleb Natapov
>> Subject: Re: [dpdk-dev] DPDK RSS support for ixgbevf PMD
>>
>>
>> On 12/17/14 03:03, Ouyang, Changchun wrote:
>>> Hi ,
>>>
 -Original Message-
 From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
 Sent: Tuesday, December 16, 2014 11:36 PM
 To: Thomas Monjalon
 Cc: dev at dpdk.org; Avi Kivity; Gleb Natapov
 Subject: Re: [dpdk-dev] DPDK RSS support for ixgbevf PMD


 On 12/15/14 22:33, Thomas Monjalon wrote:
> 2014-12-15 21:11, Vladislav Zolotarov:
>> Hi,
>> I'm running an ixgbevf PMD on an AWS guests with extended
>> networking (SR-IOV functions of 82599 Intel's NIC) and noticed that
>> even in the current git tree there is no support for a multi-queue in 
>> this
>> PMD:
>> reta size returned by rte_eth_dev_info_get() call is 0, while
>> max_rx_queues and max_tx_queues are both 4.
>>
>> Linux ixgbevf-2.15.3 driver on the other hand successfully
>> initializes 2 RSS queues: for some reason it always limits the
>> number of
 RSS queues by 2.
>> ixgbevf_main.c: line 2539
>> u16 rss = min_t(u16, num_online_cpus(), 2);
>>
>> The above is strange since if MRQE is set to 1010b there are 4 RSS
>> queues available which seems to be the case in my AWS Guest.
>>
>> However, let's get back to DPDK. As I've mentioned above the SR-IOV
>> function i have is RSS capable (to be 100% sure I've verified both
>> queues are receiving packets in a multi-socket TCP test). And it's
>> a shame I can't utilize it with a DPDK.
> Yes, it is not yet supported.
> But a patch was recently sent:
>   http://dpdk.org/ml/archives/dev/2014-December/010028.html
 Applying this patchset seems to break the NIC fast path functionality
 of a AWS Guest NIC.
 I'm still debugging it - will update u as soon as I have more specific 
 info.
>> Hi, thanks for tips but I have a question below.
>>
>>> Pls make sure enabling and using 4 queues on guest
>> Why should I enable all 4? Won't any number below or equal 4 work if (!)
>> 4 queues are available?
>> Note that there is a 82599 mode when only 2 RSS queues are available per
>> VF: MRQE=1011b.
>>
> Yes you are right, it could be 2 queues, the actual queue number per VF 
> depends on the number of VF:
> VF number from 1~32: 4 queues per VF;
> VF number from 33~64:   2 queues per VF;
> The queue number is determined by the vf number at the pf init stage,
> If pf setup 4 queues for each vf and distribute packets to 4 queues, but vf 
> only poll 1 or 2 queue,
> Then packets in other queues will be lost.
> You can try to poll 4 queues firstly to debug your issue.

Sure. When I hardcoded the queues number to 4 all works like a charm. 
The problem is that we can't leave it this way. I've posted some 
comments to your patches (0 and 5). Since I've joined the list after the 
patches have been sent I had to paste the patches bodies into my email 
and they will most like not appear in the thread of the original series. 
I hope this won't be a big problem... ;)

vlad

> Thanks
> Changchun
>

[dpdk-dev] [PATCH] ixgbe: fix segmentation fault when start secondary process

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michael Qiu
> Sent: Thursday, December 18, 2014 10:17 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] ixgbe: fix segmentation fault when start
> secondary process
> 
> EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
> EAL:   PCI memory mapped at 0x7f18c2a0
> EAL:   PCI memory mapped at 0x7f18c2a8
> Segmentation fault (core dumped)
> 
> This is introduced by commit: 46bc9d75
>   ixgbe: fix multi-process support
> When start primary process with command line:
> ./app/test/test -n 1 -c  -m 64
> then start the second one:
> ./app/test/test -n 1 --proc-type=secondary --file-prefix=rte
> This segment-fault will occur.
> 
> Root cause is test app on primary process only starts device, but
> the queue need initialized by manually command line.
> So the tx queue is still NULL when secondary process startup.
> 
> Reported-by: Yong Liu 
> Signed-off-by: Michael Qiu 

Acked-by: Pablo de Lara 

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Neil Horman]

On Wed, Dec 17, 2014 at 11:20:26PM +0100, Thomas Monjalon wrote:
> Hi Neil,
> 
> 2014-12-17 12:03, Neil Horman:
> > Back in:
> > 
> > commit aaa662e75c23c61a1d79bd4d1f9f35b4967c39db
> > Author: Alan Carew 
> > Date:   Fri Dec 5 15:19:07 2014 +0100
> > 
> > cmdline: fix overflow on bsd
> > 
> > The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  
> > This
> > patch makes the needed correction to avoid a build break
> > 
> > Signed-off-by: Neil Horman 
> > CC: Thomas Monjalon 
> 
> What is the meaning of CC here?
> 
CC is a tag that git send-email understands.  As it implies it cc's the post to
the indicated email, and records that fact in the body of the commit.

> > --- a/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> > +++ b/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> > @@ -586,8 +586,9 @@ rte_eth_xenvirt_parse_args(struct xenvirt_dict *dict,
> > if (!strncmp(pair[0], RTE_ETH_XENVIRT_MAC_PARAM,
> > sizeof(RTE_ETH_XENVIRT_MAC_PARAM))) {
> > if (cmdline_parse_etheraddr(NULL,
> > -   pair[1],
> > -   &dict->addr) < 0) {
> > +   pair[1],
> > +   &dict->addr,
> > +   sizeof(struct ether_addr)) 
> > < 0) {
> 
> Why not sizeof(dict->addr)?
> 
Because addr is a struct ether_addr, and I always get confused when doing sizeof
on pointer variables, so I find it more clear to specify the type exactly.  I'm
not bound to it though so if you like I can change it, though given its release
day, I figure you want to fix this build break asap.
Neil

> -- 
> Thomas
> 

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Neil Horman]

On Thu, Dec 18, 2014 at 03:40:54AM +, Cao, Waterman wrote:
> Hi Neil,
> 
>   Can you let me know what configuration you used for XEN Domain U?
>   Do you able to run some test cases on XEN Domain U?
>   So far, we met some issues on xenvirt (Domain U). 
> 
>   Thanks
> 
> Waterman 
> 
No configuration, I simply turned on the option in the build to ensure another
patch set of mine didn't break anything.
Neil

[dpdk-dev] [PATCH v2] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Neil Horman]

Back in:

commit aaa662e75c23c61a1d79bd4d1f9f35b4967c39db
Author: Alan Carew 
Date:   Fri Dec 5 15:19:07 2014 +0100

cmdline: fix overflow on bsd

The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  This
patch makes the needed correction to avoid a build break

Signed-off-by: Neil Horman 
CC: Thomas Monjalon 
CC: Olivier Matz 

---
Change notes

v2: Changed sizeof(struct ether_addr) to sizeof(dict->addr)
---
 lib/librte_pmd_xenvirt/rte_eth_xenvirt.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c 
b/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
index 6555ec5..04e30c9 100644
--- a/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
+++ b/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
@@ -586,8 +586,9 @@ rte_eth_xenvirt_parse_args(struct xenvirt_dict *dict,
if (!strncmp(pair[0], RTE_ETH_XENVIRT_MAC_PARAM,
sizeof(RTE_ETH_XENVIRT_MAC_PARAM))) {
if (cmdline_parse_etheraddr(NULL,
-   pair[1],
-   &dict->addr) < 0) {
+   pair[1],
+   &dict->addr,
+   sizeof(dict->addr)) < 0) {
RTE_LOG(ERR, PMD,
"Invalid %s device ether address\n",
name);
-- 
1.9.3

[dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore

[Walukiewicz, Miroslaw]

I have another question regarding your patch.

 Could we extend values returned by rte_lcore_id() to set them per thread 
(really the DPDK lcore is a pthread but started on specific core) instead of 
creating linear thread id. 

The patch would be much simpler and will work same way. The only change would 
be extending rte_lcore_id when rte_pthread_create() is called. 

The value __lcore_id has really an attribute __thread that means it is valid 
not only per CPU core but also per thread.

The mempools, timers, statistics would work without any modifications in that 
environment.

 I do not see any reason why old legacy DPDK applications would not work in 
that model. 

Mirek

> -Original Message-
> From: Liang, Cunming
> Sent: Monday, December 15, 2014 12:53 PM
> To: Walukiewicz, Miroslaw; dev at dpdk.org
> Subject: RE: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
> 
> Hi Mirek,
> 
> That sounds great.
> Looking forward to it.
> 
> -Cunming
> 
> > -Original Message-
> > From: Walukiewicz, Miroslaw
> > Sent: Monday, December 15, 2014 7:11 PM
> > To: Liang, Cunming; dev at dpdk.org
> > Subject: RE: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
> >
> > Hi Cunming,
> >
> > The timers could be used by any application/library started as a standard
> > pthread.
> > Each pthread needs to have assigned some identifier same way as you are
> doing
> > it for mempools (the rte_linear_thread_id and rte_lcore_id are good
> examples)
> >
> > I made series of patches extending the rte timers API to use with such kind
> of
> > identifier keeping existing API working also.
> >
> > I will send it soon.
> >
> > Mirek
> >
> >
> > > -Original Message-
> > > From: Liang, Cunming
> > > Sent: Friday, December 12, 2014 6:45 AM
> > > To: Walukiewicz, Miroslaw; dev at dpdk.org
> > > Subject: RE: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
> > >
> > > Thanks Mirek. That's a good point which wasn't mentioned in cover
> letter.
> > > For 'rte_timer', I only expect it be used within the 'legacy per-lcore'
> pthread.
> > > I'm appreciate if you can give me some cases which can't use it to fit.
> > > In case have to use 'rte_timer' in multi-pthread, there are some
> > > prerequisites and limitations.
> > > 1. Make sure thread local variable 'lcore_id' is set correctly (e.g. do
> pthread
> > > init by rte_pthread_prepare)
> > > 2. As 'rte_timer' is not preemptable, when using
> rte_timer_manager/reset in
> > > multi-pthread, make sure they're not on the same core.
> > >
> > > -Cunming
> > >
> > > > -Original Message-
> > > > From: Walukiewicz, Miroslaw
> > > > Sent: Thursday, December 11, 2014 5:57 PM
> > > > To: Liang, Cunming; dev at dpdk.org
> > > > Subject: RE: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per
> lcore
> > > >
> > > > Thank you Cunming for explanation.
> > > >
> > > > What about DPDK timers? They also depend on rte_lcore_id() to avoid
> > > spinlocks.
> > > >
> > > > Mirek
> > > >
> > > > > -Original Message-
> > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cunming
> Liang
> > > > > Sent: Thursday, December 11, 2014 3:05 AM
> > > > > To: dev at dpdk.org
> > > > > Subject: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
> > > > >
> > > > >
> > > > > Scope & Usage Scenario
> > > > > 
> > > > >
> > > > > DPDK usually pin pthread per core to avoid task switch overhead. It
> gains
> > > > > performance a lot, but it's not efficient in all cases. In some 
> > > > > cases, it
> may
> > > > > too expensive to use the whole core for a lightweight workload. It's a
> > > > > reasonable demand to have multiple threads per core and each
> threads
> > > > > share CPU
> > > > > in an assigned weight.
> > > > >
> > > > > In fact, nothing avoid user to create normal pthread and using cgroup
> to
> > > > > control the CPU share. One of the purpose for the patchset is to clean
> the
> > > > > gaps of using more DPDK libraries in the normal pthread. In addition, 
> > > > > it
> > > > > demonstrates performance gain by proactive 'yield' when doing idle
> loop
> > > > > in packet IO. It also provides several 'rte_pthread_*' APIs to easy 
> > > > > life.
> > > > >
> > > > >
> > > > > Changes to DPDK libraries
> > > > > ==
> > > > >
> > > > > Some of DPDK libraries must run in DPDK environment.
> > > > >
> > > > > # rte_mempool
> > > > >
> > > > > In rte_mempool doc, it mentions a thread not created by EAL must
> not
> > > use
> > > > > mempools. The root cause is it uses a per-lcore cache inside
> mempool.
> > > > > And 'rte_lcore_id()' will not return a correct value.
> > > > >
> > > > > The patchset changes this a little. The index of mempool cache won't
> be a
> > > > > lcore_id. Instead of it, using a linear number generated by the
> allocator.
> > > > > For those legacy EAL per-lcore thread, it apply for an unique linear 
> > > > > id
> > > > > during creation. For those normal p

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Thomas Monjalon]

2014-12-18 06:25, Neil Horman:
> On Wed, Dec 17, 2014 at 11:20:26PM +0100, Thomas Monjalon wrote:
> > 2014-12-17 12:03, Neil Horman:
> > > Signed-off-by: Neil Horman 
> > > CC: Thomas Monjalon 
> > 
> > What is the meaning of CC here?
> > 
> CC is a tag that git send-email understands.  As it implies it cc's the post 
> to
> the indicated email, and records that fact in the body of the commit.

OK but why CC me when sending this patch?

-- 
Thomas

[dpdk-dev] [PATCH 0/6] Enable VF RSS for Niantic

[Vlad Zolotarov]

On 12/18/14 12:11, Vlad Zolotarov wrote:
> From: Changchun Ouyang 
>
> This patch enables VF RSS for Niantic, which allow each VF having at most 4 
> queues.
> The actual queue number per VF depends on the number of VF:
> VF number from 1~32: 4 queues per VF;
> VF number from 33~max vf num: 2 queues per VF;
>
> On host, to enable VF RSS functionality, mq mode should be set as 
> ETH_MQ_RX_VMDQ_RSS
> or ETH_MQ_RX_RSS mode, and SRIOV mode should be activated.
> It also needs config VF RSS information like hash function, RSS key, RSS key 
> length.

This patch series is missing a few things:

 1. Taking into the consideration the number of Rx queues requested by a
user in the rte_eth_dev_configure().
 2. dev->dev_ops->reta_query used by a rte_eth_dev_rss_reta_query() is
still not initialized for a VF. Thus there is no way to query the
RSS table contents.
 3. rte_eth_dev_info_get() returns reta_size == 0 when called for a VF
function.

thanks,
vlad
>
> Changchun Ouyang (6):
>ixgbe: Code cleanup
>ixgbe: Negotiate VF API version
>ixgbe: Get VF queue number
>ether: Check VMDq RSS mode
>ixgbe: Config VF RSS
>testpmd: Set Rx VMDq RSS mode
>
>   app/test-pmd/testpmd.c  |  9 
>   lib/librte_ether/rte_ethdev.c   | 21 ++--
>   lib/librte_pmd_ixgbe/ixgbe_ethdev.h |  1 +
>   lib/librte_pmd_ixgbe/ixgbe_pf.c | 75 -
>   lib/librte_pmd_ixgbe/ixgbe_rxtx.c   | 95 
> +++--
>   5 files changed, 171 insertions(+), 30 deletions(-)
>
> --

[dpdk-dev] rte_mempool_create fails with ENOMEM

[Newman Poborsky]

Hi,

could someone please provide any explanation why sometimes mempool creation
fails with ENOMEM?

I run my test app several times without any problems and then I start
getting ENOMEM error when creating mempool that are used for packets. I try
to delete everything from /mnt/huge, I increase the number of huge pages,
remount /mnt/huge but nothing helps.

There is more than enough memory on server. I tried to debug
rte_mempool_create() call and it seems that after server is restarted free
mem segments are bigger than 2MB, but after running test app for several
times, it seems that all free mem segments have a size of 2MB, and since I
am requesting 8MB for my packet mempool, this fails.  I'm not really sure
that this conclusion is correct.

Does anybody have any idea what to check and how running my test app
several times affects hugepages?

For me, this doesn't make any since because after test app exits, resources
should be freed, right?

This has been driving me crazy for days now. I tried reading a bit more
theory about hugepages, but didn't find out anything that could help me.
Maybe it's something else and completely trivial, but I can't figure it
out, so any help is appreciated.

Thank you!

BR,
Newman P.

[dpdk-dev] [PATCH v2] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Qiu, Michael]

Hi Neil,

I think if you could add the commit author in the cc list will be better.

Because this could let him know about his code's issue and he is the
always the best person to review the patch.

Thanks,
Michael

On 2014/12/18 19:32, Neil Horman wrote:
> Back in:
>
> commit aaa662e75c23c61a1d79bd4d1f9f35b4967c39db
> Author: Alan Carew 
> Date:   Fri Dec 5 15:19:07 2014 +0100
>
> cmdline: fix overflow on bsd
>
> The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  This
> patch makes the needed correction to avoid a build break
>
> Signed-off-by: Neil Horman 
> CC: Thomas Monjalon 
> CC: Olivier Matz 
>
> ---
> Change notes
>
> v2: Changed sizeof(struct ether_addr) to sizeof(dict->addr)
> ---
>  lib/librte_pmd_xenvirt/rte_eth_xenvirt.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c 
> b/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> index 6555ec5..04e30c9 100644
> --- a/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> +++ b/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> @@ -586,8 +586,9 @@ rte_eth_xenvirt_parse_args(struct xenvirt_dict *dict,
>   if (!strncmp(pair[0], RTE_ETH_XENVIRT_MAC_PARAM,
>   sizeof(RTE_ETH_XENVIRT_MAC_PARAM))) {
>   if (cmdline_parse_etheraddr(NULL,
> - pair[1],
> - &dict->addr) < 0) {
> + pair[1],
> + &dict->addr,
> + sizeof(dict->addr)) < 0) {
>   RTE_LOG(ERR, PMD,
>   "Invalid %s device ether address\n",
>   name);

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Qiu, Michael]

On 2014/12/18 19:26, Neil Horman wrote:
> On Wed, Dec 17, 2014 at 11:20:26PM +0100, Thomas Monjalon wrote:
>> Hi Neil,
>>
>> 2014-12-17 12:03, Neil Horman:
>>> Back in:
>>>
>>> commit aaa662e75c23c61a1d79bd4d1f9f35b4967c39db
>>> Author: Alan Carew 
>>> Date:   Fri Dec 5 15:19:07 2014 +0100
>>>
>>> cmdline: fix overflow on bsd
>>>
>>> The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  
>>> This
>>> patch makes the needed correction to avoid a build break
>>>
>>> Signed-off-by: Neil Horman 
>>> CC: Thomas Monjalon 
>> What is the meaning of CC here?
>>
> CC is a tag that git send-email understands.  As it implies it cc's the post 
> to
> the indicated email, and records that fact in the body of the commit.

But if you use --cc in git send-email will be a good choice. CC list is
useless for patch it self, but here it will exist in commit log(although
this style can also be seen in linux kernel)

Thanks,
Michael
>>> --- a/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
>>> +++ b/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
>>> @@ -586,8 +586,9 @@ rte_eth_xenvirt_parse_args(struct xenvirt_dict *dict,
>>> if (!strncmp(pair[0], RTE_ETH_XENVIRT_MAC_PARAM,
>>> sizeof(RTE_ETH_XENVIRT_MAC_PARAM))) {
>>> if (cmdline_parse_etheraddr(NULL,
>>> -   pair[1],
>>> -   &dict->addr) < 0) {
>>> +   pair[1],
>>> +   &dict->addr,
>>> +   sizeof(struct ether_addr)) 
>>> < 0) {
>> Why not sizeof(dict->addr)?
>>
> Because addr is a struct ether_addr, and I always get confused when doing 
> sizeof
> on pointer variables, so I find it more clear to specify the type exactly.  
> I'm
> not bound to it though so if you like I can change it, though given its 
> release
> day, I figure you want to fix this build break asap.
> Neil
>
>> -- 
>> Thomas
>>

[dpdk-dev] [PATCH] af_packet: fix memory allocation check

[Daniel Mrzyglod]

In rte_eth_af_packet.c we are we are missing NULL pointer
checks after calls to alocate memory for queues. Add checking NULL
pointer and error handling.

Signed-off-by: Daniel Mrzyglod 
---
 lib/librte_pmd_af_packet/rte_eth_af_packet.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/librte_pmd_af_packet/rte_eth_af_packet.c 
b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
index ad7242c..236749b 100644
--- a/lib/librte_pmd_af_packet/rte_eth_af_packet.c
+++ b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
@@ -603,6 +603,8 @@ rte_pmd_init_internals(const char *name,
rdsize = req->tp_frame_nr * sizeof(*(rx_queue->rd));

rx_queue->rd = rte_zmalloc_socket(name, rdsize, 0, numa_node);
+   if (rx_queue->rd == NULL)
+   goto error;
for (i = 0; i < req->tp_frame_nr; ++i) {
rx_queue->rd[i].iov_base = rx_queue->map + (i * 
framesize);
rx_queue->rd[i].iov_len = req->tp_frame_size;
@@ -615,6 +617,8 @@ rte_pmd_init_internals(const char *name,
tx_queue->map = rx_queue->map + req->tp_block_size * 
req->tp_block_nr;

tx_queue->rd = rte_zmalloc_socket(name, rdsize, 0, numa_node);
+   if (tx_queue->rd == NULL)
+   goto error;
for (i = 0; i < req->tp_frame_nr; ++i) {
tx_queue->rd[i].iov_base = tx_queue->map + (i * 
framesize);
tx_queue->rd[i].iov_len = req->tp_frame_size;
-- 
2.1.0

[dpdk-dev] [PATCH] test: fix missing NULL pointer checks

[Daniel Mrzyglod]

In test_sched, we are missing NULL pointer checks after calls to create the 
mempool and to allocate an mbuf. Add in these checks using VERIFY macros.

Signed-off-by: Daniel Mrzyglod 
---
 app/test/test_sched.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/app/test/test_sched.c b/app/test/test_sched.c
index c957d80..9b6e037 100644
--- a/app/test/test_sched.c
+++ b/app/test/test_sched.c
@@ -166,6 +166,7 @@ test_sched(void)
int err;

mp = create_mempool();
+   VERIFY(mp != NULL,"Error create mempool\n");

port_param.socket = 0;
port_param.rate = (uint64_t) 1 * 1000 * 1000 / 8;
@@ -184,6 +185,7 @@ test_sched(void)

for (i = 0; i < 10; i++) {
in_mbufs[i] = rte_pktmbuf_alloc(mp);
+   VERIFY(in_mbufs[i] != NULL, "Bad packet allocation");
prepare_pkt(in_mbufs[i]);
}

-- 
2.1.0

[dpdk-dev] [PATCH] af_packet: fix memory allocation check

[Daniel Mrzyglod]

In rte_eth_af_packet.c we are we are missing NULL pointer
checks after calls to alocate memory for queues. Add checking NULL
pointer and error handling.

Signed-off-by: Daniel Mrzyglod 
---
 lib/librte_pmd_af_packet/rte_eth_af_packet.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/librte_pmd_af_packet/rte_eth_af_packet.c 
b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
index ad7242c..236749b 100644
--- a/lib/librte_pmd_af_packet/rte_eth_af_packet.c
+++ b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
@@ -603,6 +603,8 @@ rte_pmd_init_internals(const char *name,
rdsize = req->tp_frame_nr * sizeof(*(rx_queue->rd));

rx_queue->rd = rte_zmalloc_socket(name, rdsize, 0, numa_node);
+   if (rx_queue->rd == NULL)
+   goto error;
for (i = 0; i < req->tp_frame_nr; ++i) {
rx_queue->rd[i].iov_base = rx_queue->map + (i * 
framesize);
rx_queue->rd[i].iov_len = req->tp_frame_size;
@@ -615,6 +617,8 @@ rte_pmd_init_internals(const char *name,
tx_queue->map = rx_queue->map + req->tp_block_size * 
req->tp_block_nr;

tx_queue->rd = rte_zmalloc_socket(name, rdsize, 0, numa_node);
+   if (tx_queue->rd == NULL)
+   goto error;
for (i = 0; i < req->tp_frame_nr; ++i) {
tx_queue->rd[i].iov_base = tx_queue->map + (i * 
framesize);
tx_queue->rd[i].iov_len = req->tp_frame_size;
-- 
2.1.0

[dpdk-dev] rte_mempool_create fails with ENOMEM

[Alex Markuze]

I've Also seen a similar issue when trying to run a dpdk app which
allocates huge pools(~0.5GB) after a memory heavy operation on the machine.

I've come to the same conclusion as you did, that internal fragmentation is
causing pool creation failures.
It seems that the rte_mempool_xmem_create/rte_memzone_reserve_aligned are
attempting to create physicaly contiguous pools. Which may offer a slight
performance gain(?) but may cause unpredictable allocation issues which is
a big risk for DC deployments where hundreds or even thousands of machines
may be deployed with a dpdk app and fail inexplicably.

I didn't really get the chance to digg into the memory managment internals
of DPDK, so feel free to correct me where I'm off.

Thanks.

On Thu, Dec 18, 2014 at 3:25 PM, Newman Poborsky 
wrote:
>
> Hi,
>
> could someone please provide any explanation why sometimes mempool creation
> fails with ENOMEM?
>
> I run my test app several times without any problems and then I start
> getting ENOMEM error when creating mempool that are used for packets. I try
> to delete everything from /mnt/huge, I increase the number of huge pages,
> remount /mnt/huge but nothing helps.
>
> There is more than enough memory on server. I tried to debug
> rte_mempool_create() call and it seems that after server is restarted free
> mem segments are bigger than 2MB, but after running test app for several
> times, it seems that all free mem segments have a size of 2MB, and since I
> am requesting 8MB for my packet mempool, this fails.  I'm not really sure
> that this conclusion is correct.
>
> Does anybody have any idea what to check and how running my test app
> several times affects hugepages?
>
> For me, this doesn't make any since because after test app exits, resources
> should be freed, right?
>
> This has been driving me crazy for days now. I tried reading a bit more
> theory about hugepages, but didn't find out anything that could help me.
> Maybe it's something else and completely trivial, but I can't figure it
> out, so any help is appreciated.
>
> Thank you!
>
> BR,
> Newman P.
>

[dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore

[Bruce Richardson]

On Thu, Dec 18, 2014 at 12:20:07PM +, Walukiewicz, Miroslaw wrote:
> I have another question regarding your patch.
> 
>  Could we extend values returned by rte_lcore_id() to set them per thread 
> (really the DPDK lcore is a pthread but started on specific core) instead of 
> creating linear thread id. 
> 
> The patch would be much simpler and will work same way. The only change would 
> be extending rte_lcore_id when rte_pthread_create() is called. 
> 
> The value __lcore_id has really an attribute __thread that means it is valid 
> not only per CPU core but also per thread.
> 
> The mempools, timers, statistics would work without any modifications in that 
> environment.
> 
>  I do not see any reason why old legacy DPDK applications would not work in 
> that model. 
> 
> Mirek

Definite +1 here. 

/Bruce

> 
> > -Original Message-
> > From: Liang, Cunming
> > Sent: Monday, December 15, 2014 12:53 PM
> > To: Walukiewicz, Miroslaw; dev at dpdk.org
> > Subject: RE: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
> > 
> > Hi Mirek,
> > 
> > That sounds great.
> > Looking forward to it.
> > 
> > -Cunming
> > 
> > > -Original Message-
> > > From: Walukiewicz, Miroslaw
> > > Sent: Monday, December 15, 2014 7:11 PM
> > > To: Liang, Cunming; dev at dpdk.org
> > > Subject: RE: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
> > >
> > > Hi Cunming,
> > >
> > > The timers could be used by any application/library started as a standard
> > > pthread.
> > > Each pthread needs to have assigned some identifier same way as you are
> > doing
> > > it for mempools (the rte_linear_thread_id and rte_lcore_id are good
> > examples)
> > >
> > > I made series of patches extending the rte timers API to use with such 
> > > kind
> > of
> > > identifier keeping existing API working also.
> > >
> > > I will send it soon.
> > >
> > > Mirek
> > >
> > >
> > > > -Original Message-
> > > > From: Liang, Cunming
> > > > Sent: Friday, December 12, 2014 6:45 AM
> > > > To: Walukiewicz, Miroslaw; dev at dpdk.org
> > > > Subject: RE: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
> > > >
> > > > Thanks Mirek. That's a good point which wasn't mentioned in cover
> > letter.
> > > > For 'rte_timer', I only expect it be used within the 'legacy per-lcore'
> > pthread.
> > > > I'm appreciate if you can give me some cases which can't use it to fit.
> > > > In case have to use 'rte_timer' in multi-pthread, there are some
> > > > prerequisites and limitations.
> > > > 1. Make sure thread local variable 'lcore_id' is set correctly (e.g. do
> > pthread
> > > > init by rte_pthread_prepare)
> > > > 2. As 'rte_timer' is not preemptable, when using
> > rte_timer_manager/reset in
> > > > multi-pthread, make sure they're not on the same core.
> > > >
> > > > -Cunming
> > > >
> > > > > -Original Message-
> > > > > From: Walukiewicz, Miroslaw
> > > > > Sent: Thursday, December 11, 2014 5:57 PM
> > > > > To: Liang, Cunming; dev at dpdk.org
> > > > > Subject: RE: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per
> > lcore
> > > > >
> > > > > Thank you Cunming for explanation.
> > > > >
> > > > > What about DPDK timers? They also depend on rte_lcore_id() to avoid
> > > > spinlocks.
> > > > >
> > > > > Mirek
> > > > >
> > > > > > -Original Message-
> > > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cunming
> > Liang
> > > > > > Sent: Thursday, December 11, 2014 3:05 AM
> > > > > > To: dev at dpdk.org
> > > > > > Subject: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore
> > > > > >
> > > > > >
> > > > > > Scope & Usage Scenario
> > > > > > 
> > > > > >
> > > > > > DPDK usually pin pthread per core to avoid task switch overhead. It
> > gains
> > > > > > performance a lot, but it's not efficient in all cases. In some 
> > > > > > cases, it
> > may
> > > > > > too expensive to use the whole core for a lightweight workload. 
> > > > > > It's a
> > > > > > reasonable demand to have multiple threads per core and each
> > threads
> > > > > > share CPU
> > > > > > in an assigned weight.
> > > > > >
> > > > > > In fact, nothing avoid user to create normal pthread and using 
> > > > > > cgroup
> > to
> > > > > > control the CPU share. One of the purpose for the patchset is to 
> > > > > > clean
> > the
> > > > > > gaps of using more DPDK libraries in the normal pthread. In 
> > > > > > addition, it
> > > > > > demonstrates performance gain by proactive 'yield' when doing idle
> > loop
> > > > > > in packet IO. It also provides several 'rte_pthread_*' APIs to easy 
> > > > > > life.
> > > > > >
> > > > > >
> > > > > > Changes to DPDK libraries
> > > > > > ==
> > > > > >
> > > > > > Some of DPDK libraries must run in DPDK environment.
> > > > > >
> > > > > > # rte_mempool
> > > > > >
> > > > > > In rte_mempool doc, it mentions a thread not created by EAL must
> > not
> > > > use
> > > > > > mempools. The root cause is it uses

[dpdk-dev] [PATCH 0/2] doc: update to release notes

[Siobhan Butler]

Update to release notes to add VXLAN features.
Added 1.8 to 'updating apps' section of release notes. 

Siobhan Butler (2):
  doc: add vxlan support to release notes
  doc: updating from 1.7 to 1.8 release note

 doc/guides/rel_notes/new_features.rst   |  2 ++
 doc/guides/rel_notes/supported_features.rst |  5 +
 doc/guides/rel_notes/updating_apps.rst  | 29 +++--
 3 files changed, 30 insertions(+), 6 deletions(-)

-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH 1/2] doc: add vxlan support to release notes

[Siobhan Butler]

Added to New and Supported features for VXLAN feature.

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/new_features.rst   | 2 ++
 doc/guides/rel_notes/supported_features.rst | 5 +
 2 files changed, 7 insertions(+)

diff --git a/doc/guides/rel_notes/new_features.rst 
b/doc/guides/rel_notes/new_features.rst
index 568d0c9..9c6ba51 100644
--- a/doc/guides/rel_notes/new_features.rst
+++ b/doc/guides/rel_notes/new_features.rst
@@ -49,4 +49,6 @@ New Features

 *   Support NIC filters in addition to flow director for Intel? 1GbE and 10GbE 
Controllers

+*   Support for VXLAN packet on Intel(R) 40GbE Controllers
+
 For further features supported in this release, see Chapter 3 Supported 
Features.
diff --git a/doc/guides/rel_notes/supported_features.rst 
b/doc/guides/rel_notes/supported_features.rst
index c51eb26..510d489 100644
--- a/doc/guides/rel_notes/supported_features.rst
+++ b/doc/guides/rel_notes/supported_features.rst
@@ -360,3 +360,8 @@ Supported Features
 *   Exact match flow classification in the L3 Forwarding sample application

 *   Support in LPM for IPv6 addresses
+
+* Tunneling packet support:
+
+*   Provide the APIs for VXLAN destination UDP port and VXLAN packet 
filter configuration
+and support VXLAN TX checksum offload on Intel(R) 40GbE Controllers.
-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct

[ciara.lof...@intel.com]

From: Ciara Loftus 

This patch fixes the issue whereby when using userspace vhost ports
in the context of vSwitching, the name provided to the hypervisor/QEMU
of the vhost tap device needs to be exposed in the library, in order
for the vSwitch to be able to direct packets to the correct device.
This patch introduces an 'ifname' member to the virtio-net structure
which is populated with the tap device name when QEMU is brought up
with a vhost device.

Signed-off-by: Ciara Loftus 
Signed-off-by: Anthony Fee 
Acked-by: Huawei Xie 
---
 lib/librte_vhost/rte_virtio_net.h |1 +
 lib/librte_vhost/virtio-net.c |   41 -
 2 files changed, 41 insertions(+), 1 deletions(-)

diff --git a/lib/librte_vhost/rte_virtio_net.h 
b/lib/librte_vhost/rte_virtio_net.h
index 00b1328..aebb4b5 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -96,6 +96,7 @@ struct virtio_net {
uint64_tfeatures;   /**< Negotiated feature set. */
uint64_tdevice_fh;  /**< device identifier. */
uint32_tflags;  /**< Device flags. Only used to 
check if device is running on data core. */
+   charifname[32]; /** Name of the tap device **/
void*priv;  /**< private context */
 } __rte_cache_aligned;

diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index 852b6d1..7f90ecf 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -43,6 +43,10 @@
 #include 
 #include 

+#include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -1000,6 +1004,39 @@ set_vring_kick(struct vhost_device_ctx ctx, struct 
vhost_vring_file *file)
 }

 /*
+ * Function to get the tap device name from the provided file descriptor and
+ * save it in the device structure.
+ */
+static int
+get_ifname(struct virtio_net *dev, int tap_fd, int pid)
+{
+   struct eventfd_copy fd_tap;
+   struct ifreq ifr;
+   uint32_t size;
+
+   fd_tap.source_fd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
+   fd_tap.target_fd = tap_fd;
+   fd_tap.target_pid = pid;
+
+   if (eventfd_copy(dev, &fd_tap))
+   return -1;
+
+   ioctl(fd_tap.source_fd, TUNGETIFF, &ifr);
+
+   if (close(fd_tap.source_fd) < 0)
+   RTE_LOG(ERR, VHOST_CONFIG,
+   "(%"PRIu64") fd close failed\n",
+   dev->device_fh);
+
+   size = strnlen(ifr.ifr_name, sizeof(ifr.ifr_name)) > 
sizeof(dev->ifname)?
+   sizeof(dev->ifname): strnlen(ifr.ifr_name, 
sizeof(ifr.ifr_name));
+
+   strncpy(dev->ifname, ifr.ifr_name, size);
+
+   return 0;
+}
+
+/*
  * Called from CUSE IOCTL: VHOST_NET_SET_BACKEND
  * To complete device initialisation when the virtio driver is loaded,
  * we are provided with a valid fd for a tap device (not used by us).
@@ -1026,8 +1063,10 @@ set_backend(struct vhost_device_ctx ctx, struct 
vhost_vring_file *file)
 */
if (!(dev->flags & VIRTIO_DEV_RUNNING)) {
if (((int)dev->virtqueue[VIRTIO_TXQ]->backend != 
VIRTIO_DEV_STOPPED) &&
-   ((int)dev->virtqueue[VIRTIO_RXQ]->backend != 
VIRTIO_DEV_STOPPED))
+   ((int)dev->virtqueue[VIRTIO_RXQ]->backend != 
VIRTIO_DEV_STOPPED)) {
+   get_ifname(dev, file->fd, ctx.pid);
return notify_ops->new_device(dev);
+   }
/* Otherwise we remove it. */
} else
if (file->fd == VIRTIO_DEV_STOPPED)
-- 
1.7.4.1

[dpdk-dev] [PATCH 10/17] librte_acl: add AVX2 as new rte_acl_classify() method

[Ananyev, Konstantin]

> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Wednesday, December 17, 2014 8:28 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 10/17] librte_acl: add AVX2 as new 
> rte_acl_classify() method
> 
> On Wed, Dec 17, 2014 at 07:22:06PM +, Ananyev, Konstantin wrote:
> > > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > > Sent: Wednesday, December 17, 2014 3:33 PM
> > > To: Ananyev, Konstantin
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 10/17] librte_acl: add AVX2 as new 
> > > rte_acl_classify() method
> > >
> > > On Tue, Dec 16, 2014 at 04:16:48PM +, Ananyev, Konstantin wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > > > > Sent: Monday, December 15, 2014 8:21 PM
> > > > > To: Ananyev, Konstantin
> > > > > Cc: dev at dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 10/17] librte_acl: add AVX2 as new 
> > > > > rte_acl_classify() method
> > > > >
> > > > > On Mon, Dec 15, 2014 at 04:33:47PM +, Ananyev, Konstantin wrote:
> > > > > > Hi Neil,
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > > > > > > Sent: Monday, December 15, 2014 4:00 PM
> > > > > > > To: Ananyev, Konstantin
> > > > > > > Cc: dev at dpdk.org
> > > > > > > Subject: Re: [dpdk-dev] [PATCH 10/17] librte_acl: add AVX2 as new 
> > > > > > > rte_acl_classify() method
> > > > > > >
> > > > > > > On Sun, Dec 14, 2014 at 06:10:52PM +, Konstantin Ananyev 
> > > > > > > wrote:
> > > > > > > > Introduce new classify() method that uses AVX2 instructions.
> > > > > > > > From my measurements:
> > > > > > > > On HSW boards when processing >= 16 packets per call,
> > > > > > > > AVX2 method outperforms it's SSE counterpart by 10-25%,
> > > > > > > > (depending on the ruleset).
> > > > > > > > At runtime, this method is selected as default one on HW that 
> > > > > > > > supports AVX2.
> > > > > > > >
> > > > > > > > Signed-off-by: Konstantin Ananyev  > > > > > > > intel.com>
> > > > > > > > ---
> > > > > > > >  lib/librte_acl/Makefile   |   9 +
> > > > > > > >  lib/librte_acl/acl.h  |   4 +
> > > > > > > >  lib/librte_acl/acl_run.h  |   2 +-
> > > > > > > >  lib/librte_acl/acl_run_avx2.c |  58 +
> > > > > > > >  lib/librte_acl/acl_run_avx2.h | 305 
> > > > > > > >  lib/librte_acl/acl_run_sse.c  | 537 
> > > > > > > > +-
> > > > > > > >  lib/librte_acl/acl_run_sse.h  | 533 
> > > > > > > > +
> > > > > > > >  lib/librte_acl/rte_acl.c  |   5 +-
> > > > > > > >  lib/librte_acl/rte_acl.h  |   2 +
> > > > > > > >  9 files changed, 917 insertions(+), 538 deletions(-)
> > > > > > > >  create mode 100644 lib/librte_acl/acl_run_avx2.c
> > > > > > > >  create mode 100644 lib/librte_acl/acl_run_avx2.h
> > > > > > > >  create mode 100644 lib/librte_acl/acl_run_sse.h
> > > > > > > >
> > > > > > > > diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
> > > > > > > > index 65e566d..223ec31 100644
> > > > > > > > --- a/lib/librte_acl/Makefile
> > > > > > > > +++ b/lib/librte_acl/Makefile
> > > > > > > > @@ -45,8 +45,17 @@ SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_bld.c
> > > > > > > >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_gen.c
> > > > > > > >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_scalar.c
> > > > > > > >  SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_sse.c
> > > > > > > > +SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_avx2.c
> > > > > > > >
> > > > > > > >  CFLAGS_acl_run_sse.o += -msse4.1
> > > > > > > > +ifeq ($(CC), icc)
> > > > > > > > +CFLAGS_acl_run_avx2.o += -march=core-avx2
> > > > > > > > +else ifneq ($(shell \
> > > > > > > > +test $(GCC_MAJOR_VERSION) -le 4 -a $(GCC_MINOR_VERSION) -le 6 
> > > > > > > > && echo 1), 1)
> > > > > > > > +CFLAGS_acl_run_avx2.o += -mavx2
> > > > > > > > +else
> > > > > > > > +CFLAGS_acl_run_avx2.o += -msse4.1
> > > > > > > > +endif
> > > > > > > >
> > > > > > > This seems broken.  You've unilaterally included acl_run_avx2.c 
> > > > > > > in the build
> > > > > > > list above, but only enable -mavx2 if the compiler is at least 
> > > > > > > gcc 4.6.
> > > > > >
> > > > > > Actually 4.7 (before that version, as I know,  gcc doesn't support 
> > > > > > avx2)
> > > > > >
> > > > > > >  Unless
> > > > > > > you want to make gcc 4.6 a requirement for building,
> > > > > >
> > > > > > I believe DPDK is required to be buildable by gcc 4.6
> > > > > > As I remember, we have to support it all way down to gcc 4.3.
> > > > > >
> > > > > > > you need to also exclude
> > > > > > > the file above from the build list.
> > > > > >
> > > > > > That means that for  gcc 4.6 and below rte_acl_classify_avx2() 
> > > > > > would not be defined.
> > > > > > And then at runtime, I have to check for that somehow and 
> > > > > > (re)populate classify_fns[].

[dpdk-dev] [PATCH] doc:add udp info to prog_guide for vxlan

[Siobhan Butler]

Added to configuration instructions for UDP packet tunneling.

Signed-off-by: Siobhan Butler 
---
 doc/guides/prog_guide/poll_mode_drv.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/prog_guide/poll_mode_drv.rst 
b/doc/guides/prog_guide/poll_mode_drv.rst
index 2567876..2e7b430 100644
--- a/doc/guides/prog_guide/poll_mode_drv.rst
+++ b/doc/guides/prog_guide/poll_mode_drv.rst
@@ -199,6 +199,7 @@ Other features such as the L3/L4 5-Tuple packet filtering 
feature of a port can
 Ethernet* flow control (pause frame) can be configured on the individual port.
 Refer to the testpmd source code for details.
 Also, L4 (UDP/TCP/ SCTP) checksum offload by the NIC can be enabled for an 
individual packet as long as the packet mbuf is set up correctly.
+In terms of UDP tunneling packet, the PKT_TX_UDP_TUNNEL_PKT flag must be set 
to enable tunneling packet TX checksum offload for both outer layer and inner 
layer.
 Refer to the testpmd source code (specifically the csumonly.c file) for 
details.

 That being said, the support of some offload features implies the addition of 
dedicated status bit(s) and value field(s) into the rte_mbuf
-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH 2/2] doc: updating from 1.7 to 1.8 release note

[Siobhan Butler]

Added instructions for updating from DPDK 1.7.0 to 1.8.0

Signed-off-by: Siobhan Butler 

Signed-off-by: Bruce Richardson 
---
 doc/guides/rel_notes/updating_apps.rst | 29 +++--
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/doc/guides/rel_notes/updating_apps.rst 
b/doc/guides/rel_notes/updating_apps.rst
index ba8012d..60d5d60 100644
--- a/doc/guides/rel_notes/updating_apps.rst
+++ b/doc/guides/rel_notes/updating_apps.rst
@@ -2,17 +2,34 @@ Updating Applications from Previous Versions
 

 Although backward compatibility is being maintained across Intel?? DPDK 
releases, code written for previous versions of the Intel?? DPDK
-may require some code updates to benefit from performance and user experience 
enhancements provided in later Intel?? DPDK releases.
+may require some code updates to benefit from performance and user experience 
enhancements provided in later DPDK releases.
+
+Intel?? DPDK 1.7 to DPDK 1.8
+
+
+Note that in DPDK 1.8, the structure of the rte_mbuf has changed considerably 
from all previous versions.
+It is recommended that users familiarize themselves with the new structure 
defined in the file rte_mbuf.h in the release package.
+The follow are some common changes that need to be made to code using mbufs, 
following an update to DPDK 1.8:
+*   Any references to fields in the pkt or ctrl sub-structures 
of the mbuf, need to be replaced with references to the field
+directly from the rte_mbuf, i.e. buf->pkt.data_len should be replace by 
buf->data_len.
+
+*   Any direct references to the data field of the mbuf (original 
buf->pkt.data) should now be replace by the macro rte_pktmbuf_mtod
+to get a computed data address inside the mbuf buffer area.
+
+*   Any references to the in_port mbuf field should be replace by 
references to the port field.
+
+NOTE: The above list is not exhaustive, but only includes the most commonly 
required changes to code using mbufs.
+

 Intel?? DPDK 1.6 to Intel?? DPDK 1.7
---
+

 Note the following difference between 1.6 and 1.7:

 *   The "default" target has been renamed to "native"

 Intel?? DPDK 1.5 to Intel?? DPDK 1.6
---
+

 Note the following difference between 1.5 and 1.6:

@@ -21,7 +38,7 @@ Note the following difference between 1.5 and 1.6:
 Intel?? DPDK release and documented in the *Intel?? DPDK Getting Started 
Guide*.

 Intel?? DPDK 1.4 to Intel?? DPDK 1.5
---
+

 Note the following difference between 1.4 and 1.5:

@@ -29,7 +46,7 @@ Note the following difference between 1.4 and 1.5:
 that is, DPDK-1.5.2/ rather than just DPDK/ .

 Intel?? DPDK 1.3 to Intel?? DPDK 1.4.x
-
+--

 Note the following difference between releases 1.3 and 1.4.x:

@@ -50,7 +67,7 @@ Note the following difference between releases 1.3 and 1.4.x:
 For more details on this and how to re-enable the HPET if it is needed, 
please consult the *Intel?? DPDK Getting Started Guide*.

 Intel?? DPDK 1.2 to Intel?? DPDK 1.3
---
+

 Note the following difference between releases 1.2 and 1.3:

-- 
1.9.4.msysgit.2

[dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore

[Olivier MATZ]

Hi,

On 12/18/2014 03:32 PM, Bruce Richardson wrote:
> On Thu, Dec 18, 2014 at 12:20:07PM +, Walukiewicz, Miroslaw wrote:
>> I have another question regarding your patch.
>>
>>  Could we extend values returned by rte_lcore_id() to set them per thread 
>> (really the DPDK lcore is a pthread but started on specific core) instead of 
>> creating linear thread id. 
>>
>> The patch would be much simpler and will work same way. The only change 
>> would be extending rte_lcore_id when rte_pthread_create() is called. 
>>
>> The value __lcore_id has really an attribute __thread that means it is valid 
>> not only per CPU core but also per thread.
>>
>> The mempools, timers, statistics would work without any modifications in 
>> that environment.
>>
>>  I do not see any reason why old legacy DPDK applications would not work in 
>> that model. 
>>
>> Mirek
> 
> Definite +1 here. 

One remark though: it looks that the rte_rings (and therefore the
rte_mempools) are designed with the assumption that the execution
units are alone on their cores.

As explained in [1], there is a risk that a pthread is interrupted
by the kernel at a bad moment. Therefore another thread can be
blocked, spinning on a variable to change its value.

The same could also occurs with spinlocks which are not designed
to wakeup another pthread when the lock is held (like pthread_locks).

And finally, having several pthreads per core implies that the
application should be designed with large queues: if a pthread is
not scheduled during 10ms, it represents 100K packets at 10M PPS.

I don't say it's impossible to do it, but I think it's not so
simple :)

Regards,
Olivier

[1] http://dpdk.org/ml/archives/dev/2013-November/000714.html

[dpdk-dev] [PATCH v4 3/8] doc: added to known issue 6.10 and removed fixed issue 6.29 from rel_notes

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, December 17, 2014 4:58 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4 3/8] doc: added to known issue 6.10 and removed 
> fixed issue 6.29
> from rel_notes
> 
> From: Siobhan Butler 
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v4 1/8] doc: moved 1.7 new features to supported features for 1.8 in Rel_Notes

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, December 17, 2014 4:48 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4 1/8] doc: moved 1.7 new features to supported 
> features for 1.8 in
> Rel_Notes
> 
> From: Siobhan Butler 
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v4 5/8] doc: remove appendix a from release notes

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, December 17, 2014 4:48 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4 5/8] doc: remove appendix a from release notes
> 
> From: Siobhan Butler 
> 
> Removing Appendix A from Release Notes as Intel Licensing information is no 
> longer relevant in this
> document.
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v2 1/2] doc: remove intel dpdk in sample app ug

[Siobhan Butler]

Removed redundant references to Intel(R) DPDK in Sample App UG.

Signed-off-by: Siobhan Butler 
---
 doc/guides/sample_app_ug/cmd_line.rst  | 10 ++--
 doc/guides/sample_app_ug/exception_path.rst|  8 ++--
 doc/guides/sample_app_ug/hello_world.rst   |  8 ++--
 doc/guides/sample_app_ug/intel_quickassist.rst | 18 +++
 .../sample_app_ug/internet_proto_ip_pipeline.rst   |  4 +-
 doc/guides/sample_app_ug/intro.rst | 12 ++---
 doc/guides/sample_app_ug/ip_frag.rst   |  6 +--
 doc/guides/sample_app_ug/ip_reassembly.rst |  6 +--
 doc/guides/sample_app_ug/ipv4_multicast.rst|  6 +--
 doc/guides/sample_app_ug/kernel_nic_interface.rst  | 34 ++---
 .../sample_app_ug/l2_forward_real_virtual.rst  | 12 ++---
 doc/guides/sample_app_ug/l3_forward.rst|  8 ++--
 .../sample_app_ug/l3_forward_access_ctrl.rst   |  6 +--
 doc/guides/sample_app_ug/l3_forward_power_man.rst  | 16 +++
 doc/guides/sample_app_ug/l3_forward_virtual.rst|  8 ++--
 doc/guides/sample_app_ug/link_status_intr.rst  | 10 ++--
 doc/guides/sample_app_ug/load_balancer.rst | 12 ++---
 doc/guides/sample_app_ug/multi_process.rst | 34 ++---
 doc/guides/sample_app_ug/netmap_compatibility.rst  | 30 ++--
 doc/guides/sample_app_ug/qos_metering.rst  |  4 +-
 doc/guides/sample_app_ug/qos_scheduler.rst |  6 +--
 doc/guides/sample_app_ug/quota_watermark.rst   | 12 ++---
 doc/guides/sample_app_ug/test_pipeline.rst | 10 ++--
 doc/guides/sample_app_ug/timer.rst |  6 +--
 doc/guides/sample_app_ug/vhost.rst | 56 +++---
 doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst   | 10 ++--
 26 files changed, 176 insertions(+), 176 deletions(-)

diff --git a/doc/guides/sample_app_ug/cmd_line.rst 
b/doc/guides/sample_app_ug/cmd_line.rst
index 0a0ea41..6a72959 100644
--- a/doc/guides/sample_app_ug/cmd_line.rst
+++ b/doc/guides/sample_app_ug/cmd_line.rst
@@ -32,15 +32,15 @@ Command Line Sample Application
 ===

 This chapter describes the Command Line sample application that
-is part of the Intel? Data Plane Development Kit (Intel? DPDK).
+is part of the Data Plane Development Kit (DPDK).

 Overview
 

 The Command Line sample application is a simple application that
-demonstrates the use of the command line interface in the Intel? DPDK.
+demonstrates the use of the command line interface in the DPDK.
 This application is a readline-like interface that can be used
-to debug an Intel? DPDK application, in a Linux* application environment.
+to debug a DPDK application, in a Linux* application environment.

 .. note::

@@ -81,7 +81,7 @@ Compiling the Application

 export RTE_TARGET=x86_64-native-linuxapp-gcc

-Refer to the *Intel? DPDK Getting Started Guide* for possible RTE_TARGET 
values.
+Refer to the *DPDK Getting Started Guide* for possible RTE_TARGET values.

 #.  Build the application:

@@ -98,7 +98,7 @@ To run the application in linuxapp environment, issue the 
following command:

 $ ./build/cmdline -c f -n 4

-Refer to the *Intel? DPDK Getting Started Guide* for general information on 
running applications
+Refer to the *DPDK Getting Started Guide* for general information on running 
applications
 and the Environment Abstraction Layer (EAL) options.

 Explanation
diff --git a/doc/guides/sample_app_ug/exception_path.rst 
b/doc/guides/sample_app_ug/exception_path.rst
index e440268..0b71f9e 100644
--- a/doc/guides/sample_app_ug/exception_path.rst
+++ b/doc/guides/sample_app_ug/exception_path.rst
@@ -31,10 +31,10 @@
 Exception Path Sample Application
 =

-The Exception Path sample application is a simple example that demonstrates 
the use of the Intel? DPDK
+The Exception Path sample application is a simple example that demonstrates 
the use of the DPDK
 to set up an exception path for packets to go through the Linux* kernel.
 This is done by using virtual TAP network interfaces.
-These can be read from and written to by the Intel? DPDK application and
+These can be read from and written to by the DPDK application and
 appear to the kernel as a standard network interface.

 Overview
@@ -74,7 +74,7 @@ Compiling the Application
 export RTE_TARGET=x86_64-native-linuxapp-gcc

 This application is intended as a linuxapp only.
-See the *Intel? DPDK Getting Started Guide* for possible RTE_TARGET values.
+See the *DPDK Getting Started Guide* for possible RTE_TARGET values.

 #.  Build the application:

@@ -99,7 +99,7 @@ where:

 *   -o OUT_CORES: A hex bitmask of cores which write to NIC

-Refer to the *Intel? DPDK Getting Started Guide* for general information on 
running applications
+Refer to the *DPDK Getting Started Guide* for general information on running 
applications
 and the Environment Abstraction Layer (EAL) options.

 The number of bits set in each bitmask must be the same

[dpdk-dev] [PATCH v4 2/8] doc: added new features to release notes

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, December 17, 2014 4:48 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4 2/8] doc: added new features to release notes
> 
> From: Siobhan Butler 
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v4 7/8] doc: updated resolved issues with old known issues

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, December 17, 2014 4:48 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4 7/8] doc: updated resolved issues with old 
> known issues
> 
> From: Siobhan Butler 
> 
> Removed resolved issues from known issues section.
> Added new resolved issues to resolved issues section.
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v4 4/8] doc: moved known issue 6.29 to resolved issues in rel notes

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, December 17, 2014 4:48 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4 4/8] doc: moved known issue 6.29 to resolved 
> issues in rel notes
> 
> From: Siobhan Butler 
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v4 8/8] doc: updating the list of sample apps in rel notes

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, December 17, 2014 4:48 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4 8/8] doc: updating the list of sample apps in 
> rel notes
> 
> From: Siobhan Butler 
> 
> Added new and existing names of sample apps to list of sample apps in release 
> notes.
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v4 6/8] doc: removed reference to Intel DPDK in Rel Notes

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara
> Sent: Wednesday, December 17, 2014 4:48 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4 6/8] doc: removed reference to Intel DPDK in 
> Rel Notes
> 
> From: Siobhan Butler 
> 
> Removed multiple references to Intel(R) DPDK where no longer
> relevant.
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v2 0/2] doc: remove intel references from sample app ug

[Siobhan Butler]

Removed Intel(R) DPDK references from sample app guide.
Removed Intel legal blurb from sample app guide.

Siobhan Butler (2):
  doc: remove intel dpdk in sample app ug
  doc: remove intel legal blurb from sample app ug

 doc/guides/sample_app_ug/cmd_line.rst  | 10 ++--
 doc/guides/sample_app_ug/exception_path.rst|  8 ++--
 doc/guides/sample_app_ug/hello_world.rst   |  8 ++--
 doc/guides/sample_app_ug/index.rst | 35 --
 doc/guides/sample_app_ug/intel_quickassist.rst | 18 +++
 .../sample_app_ug/internet_proto_ip_pipeline.rst   |  4 +-
 doc/guides/sample_app_ug/intro.rst | 12 ++---
 doc/guides/sample_app_ug/ip_frag.rst   |  6 +--
 doc/guides/sample_app_ug/ip_reassembly.rst |  6 +--
 doc/guides/sample_app_ug/ipv4_multicast.rst|  6 +--
 doc/guides/sample_app_ug/kernel_nic_interface.rst  | 34 ++---
 .../sample_app_ug/l2_forward_real_virtual.rst  | 12 ++---
 doc/guides/sample_app_ug/l3_forward.rst|  8 ++--
 .../sample_app_ug/l3_forward_access_ctrl.rst   |  6 +--
 doc/guides/sample_app_ug/l3_forward_power_man.rst  | 16 +++
 doc/guides/sample_app_ug/l3_forward_virtual.rst|  8 ++--
 doc/guides/sample_app_ug/link_status_intr.rst  | 10 ++--
 doc/guides/sample_app_ug/load_balancer.rst | 12 ++---
 doc/guides/sample_app_ug/multi_process.rst | 34 ++---
 doc/guides/sample_app_ug/netmap_compatibility.rst  | 30 ++--
 doc/guides/sample_app_ug/qos_metering.rst  |  4 +-
 doc/guides/sample_app_ug/qos_scheduler.rst |  6 +--
 doc/guides/sample_app_ug/quota_watermark.rst   | 12 ++---
 doc/guides/sample_app_ug/test_pipeline.rst | 10 ++--
 doc/guides/sample_app_ug/timer.rst |  6 +--
 doc/guides/sample_app_ug/vhost.rst | 56 +++---
 doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst   | 10 ++--
 27 files changed, 176 insertions(+), 211 deletions(-)

-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct

[Thomas Monjalon]

2014-12-18 14:55, ciara.loftus at intel.com:
> This patch fixes the issue whereby when using userspace vhost ports
> in the context of vSwitching, the name provided to the hypervisor/QEMU
> of the vhost tap device needs to be exposed in the library, in order
> for the vSwitch to be able to direct packets to the correct device.

Do you mean that vhost was not working at all?
Please precise the context and how it is critical.
More informations are needed to understand wether it should be merged in
release 1.8.0 or not.

> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -96,6 +96,7 @@ struct virtio_net {
>   uint64_tfeatures;   /**< Negotiated feature set. */
>   uint64_tdevice_fh;  /**< device identifier. */
>   uint32_tflags;  /**< Device flags. Only used to 
> check if device is running on data core. */
> + charifname[32]; /** Name of the tap device **/

Wrong comment style.

-- 
Thomas

[dpdk-dev] [PATCH v2 1/2] doc: add vxlan support to release notes

[Pablo de Lara]

From: Siobhan Butler 

Added to New and Supported features for VXLAN feature.

Signed-off-by: Siobhan Butler 
---
 doc/guides/rel_notes/new_features.rst   | 2 ++
 doc/guides/rel_notes/supported_features.rst | 5 +
 2 files changed, 7 insertions(+)

diff --git a/doc/guides/rel_notes/new_features.rst 
b/doc/guides/rel_notes/new_features.rst
index 00895ce..2c37af7 100644
--- a/doc/guides/rel_notes/new_features.rst
+++ b/doc/guides/rel_notes/new_features.rst
@@ -54,6 +54,8 @@ New Features

 *   Support configuring hash functions

+*   Support for VXLAN packet on Intel(R) 40GbE Controllers
+
 *   Packet Distributor Sample Application

 For further features supported in this release, see Chapter 3 Supported 
Features.
diff --git a/doc/guides/rel_notes/supported_features.rst 
b/doc/guides/rel_notes/supported_features.rst
index 37e5416..e683ead 100644
--- a/doc/guides/rel_notes/supported_features.rst
+++ b/doc/guides/rel_notes/supported_features.rst
@@ -382,3 +382,8 @@ Supported Features
 *   Exact match flow classification in the L3 Forwarding sample application

 *   Support in LPM for IPv6 addresses
+
+* Tunneling packet support:
+
+*   Provide the APIs for VXLAN destination UDP port and VXLAN packet 
filter configuration
+and support VXLAN TX checksum offload on Intel(R) 40GbE Controllers.
-- 
2.1.0

[dpdk-dev] librte_distributor.so: cannot open shared object file

[sothy shan]

Hi!

I am in fedora 21. I build sucesfully. I set the LD_LIBRARY_PATH.
When I run the testpmd file, I am getting above error. Thank for your help.

[cubiq at localhost dpdk-1.7.1]$ echo $LD_LIBRARY_PATH
/home/cubiq/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib
[cubiq at localhost dpdk-1.7.1]$ sudo ./x86_64-ivshmem-linuxapp-gcc/app/testpmd
[sudo] password for cubiq:
./x86_64-ivshmem-linuxapp-gcc/app/testpmd: error while loading shared
libraries: librte_distributor.so: cannot open shared object file: No such
file or directory
[cubiq at localhost dpdk-1.7.1]$


Best regards
Sothy

[dpdk-dev] [PATCH] doc:add udp info to prog_guide for vxlan

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler
> Sent: Thursday, December 18, 2014 3:02 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc:add udp info to prog_guide for vxlan
> 
> Added to configuration instructions for UDP packet tunneling.
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v2 0/2] doc: update to release notes

[Pablo de Lara]

Update to release notes to add VXLAN features.
Added 1.8 to 'updating apps' section of release notes. 

Changes to v2:
Rebase to latest document

Siobhan Butler (2):
  doc: add vxlan support to release notes
  doc: updating from 1.7 to 1.8 release note

 doc/guides/rel_notes/new_features.rst   |  2 ++
 doc/guides/rel_notes/supported_features.rst |  5 +
 doc/guides/rel_notes/updating_apps.rst  | 13 +
 3 files changed, 20 insertions(+)

-- 
2.1.0

[dpdk-dev] [PATCH v2 2/2] doc: updating from 1.7 to 1.8 release note

[Pablo de Lara]

From: Siobhan Butler 

Added instructions for updating from DPDK 1.7.0 to 1.8.0

Signed-off-by: Siobhan Butler 

Signed-off-by: Bruce Richardson 
---
 doc/guides/rel_notes/updating_apps.rst | 13 +
 1 file changed, 13 insertions(+)

diff --git a/doc/guides/rel_notes/updating_apps.rst 
b/doc/guides/rel_notes/updating_apps.rst
index 034554d..4dbf268 100644
--- a/doc/guides/rel_notes/updating_apps.rst
+++ b/doc/guides/rel_notes/updating_apps.rst
@@ -7,6 +7,19 @@ may require some code updates to benefit from performance and 
user experience en
 DPDK 1.7 to DPDK 1.8
 

+Note that in DPDK 1.8, the structure of the rte_mbuf has changed considerably 
from all previous versions.
+It is recommended that users familiarize themselves with the new structure 
defined in the file rte_mbuf.h in the release package.
+The follow are some common changes that need to be made to code using mbufs, 
following an update to DPDK 1.8:
+
+*   Any references to fields in the pkt or ctrl sub-structures of the mbuf, 
need to be replaced with references to the field
+directly from the rte_mbuf, i.e. buf->pkt.data_len should be replace by 
buf->data_len.
+
+*   Any direct references to the data field of the mbuf (original 
buf->pkt.data) should now be replace by the macro rte_pktmbuf_mtod
+to get a computed data address inside the mbuf buffer area.
+
+*   Any references to the in_port mbuf field should be replace by references 
to the port field.
+
+NOTE: The above list is not exhaustive, but only includes the most commonly 
required changes to code using mbufs.

 Intel? DPDK 1.6 to DPDK 1.7
 ---
-- 
2.1.0

[dpdk-dev] [PATCH v2 2/2] doc: remove intel legal blurb from sample app ug

[Siobhan Butler]

Removed Legal blurb from sample applications guide.

Signed-off-by: Siobhan Butler 
---
 doc/guides/sample_app_ug/index.rst | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/doc/guides/sample_app_ug/index.rst 
b/doc/guides/sample_app_ug/index.rst
index c3b50e2..d07dec3 100644
--- a/doc/guides/sample_app_ug/index.rst
+++ b/doc/guides/sample_app_ug/index.rst
@@ -33,41 +33,6 @@ Sample Applications User Guide

 |today|

-INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS.
-NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL 
PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT.
-EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS,
-INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR 
IMPLIED WARRANTY,
-RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR 
WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE,
-MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER 
INTELLECTUAL PROPERTY RIGHT.
-
-A "Mission Critical Application" is any application in which failure of the 
Intel Product could result, directly or indirectly, in personal injury or death.
-SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL 
APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES,
-SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF 
EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES,
-AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR 
INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY,
-OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION,
-WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN,
-MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS.
-
-Intel may make changes to specifications and product descriptions at any time, 
without notice.
-Designers must not rely on the absence or characteristics of any features or 
instructions marked "reserved" or "undefined".
-Intel reserves these for future definition and shall have no responsibility 
whatsoever for conflicts or incompatibilities arising from future changes to 
them.
-The information here is subject to change without notice.
-Do not finalize a design with this information.
-
-The products described in this document may contain design defects or errors 
known as errata which may cause the product to deviate from published 
specifications.
-Current characterized errata are available on request.
-
-Contact your local Intel sales office or your distributor to obtain the latest 
specifications and before placing your product order.
-
-Copies of documents which have an order number and are referenced in this 
document, or other Intel literature, may be obtained by calling 1-800-548-4725, 
or go to:
-`http://www.intel.com/design/literature.htm 
`_.
-
-Intel and the Intel logo are trademarks or registered trademarks of Intel 
Corporation or its subsidiaries in the United States and other countries.
-
-\*Other names and brands may be claimed as the property of others.
-
-Copyright ? 2012 - 2014, Intel Corporation. All rights reserved.
-
 **Contents**

 .. toctree::
-- 
1.9.4.msysgit.2

[dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore

[Bruce Richardson]

On Thu, Dec 18, 2014 at 04:11:12PM +0100, Olivier MATZ wrote:
> Hi,
> 
> On 12/18/2014 03:32 PM, Bruce Richardson wrote:
> > On Thu, Dec 18, 2014 at 12:20:07PM +, Walukiewicz, Miroslaw wrote:
> >> I have another question regarding your patch.
> >>
> >>  Could we extend values returned by rte_lcore_id() to set them per thread 
> >> (really the DPDK lcore is a pthread but started on specific core) instead 
> >> of creating linear thread id. 
> >>
> >> The patch would be much simpler and will work same way. The only change 
> >> would be extending rte_lcore_id when rte_pthread_create() is called. 
> >>
> >> The value __lcore_id has really an attribute __thread that means it is 
> >> valid not only per CPU core but also per thread.
> >>
> >> The mempools, timers, statistics would work without any modifications in 
> >> that environment.
> >>
> >>  I do not see any reason why old legacy DPDK applications would not work 
> >> in that model. 
> >>
> >> Mirek
> > 
> > Definite +1 here. 
> 
> One remark though: it looks that the rte_rings (and therefore the
> rte_mempools) are designed with the assumption that the execution
> units are alone on their cores.
> 
> As explained in [1], there is a risk that a pthread is interrupted
> by the kernel at a bad moment. Therefore another thread can be
> blocked, spinning on a variable to change its value.
> 
> The same could also occurs with spinlocks which are not designed
> to wakeup another pthread when the lock is held (like pthread_locks).
> 
> And finally, having several pthreads per core implies that the
> application should be designed with large queues: if a pthread is
> not scheduled during 10ms, it represents 100K packets at 10M PPS.
> 
> I don't say it's impossible to do it, but I think it's not so
> simple :)
> 
> Regards,
> Olivier
> 
> [1] http://dpdk.org/ml/archives/dev/2013-November/000714.html

Yes, completely agree, but because there are so many potential pitfalls, I
think we should take small steps without making major changes. Hence my 
agreement
with Mirek's suggestion as the simplest way forward that gives us good 
possibilities
and flexibility without major work.

BTW: For the multi-thread per core case, I think we'll need to look at threads
making extensive use of yields to help force the context switches at proper 
times.

/Bruce

[dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore

[Stephen Hemminger]

On Thu, 18 Dec 2014 12:20:07 +
"Walukiewicz, Miroslaw"  wrote:

>  Could we extend values returned by rte_lcore_id() to set them per thread 
> (really the DPDK lcore is a pthread but started on specific core) instead of 
> creating linear thread id.

The linear thread id is very useful for having per-core statistics tables.
This is done in lots of places to avoid cache thrashing.

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Stephen Hemminger]

On Wed, 17 Dec 2014 12:03:28 -0500
Neil Horman  wrote:

> Back in:
> 
> commit aaa662e75c23c61a1d79bd4d1f9f35b4967c39db
> Author: Alan Carew 
> Date:   Fri Dec 5 15:19:07 2014 +0100
> 
> cmdline: fix overflow on bsd
> 
> The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  This
> patch makes the needed correction to avoid a build break
> 
> Signed-off-by: Neil Horman 
> CC: Thomas Monjalon 

If we could fix the header incompatiablities then the driver could use
a standard library like ether_aton() instead of dragging in the unnecessary
cmdline library.

[dpdk-dev] [PATCH v2 2/2] doc: remove intel legal blurb from sample app ug

[Siobhan Butler]

Removed Legal blurb from sample applications guide.

Signed-off-by: Siobhan Butler 
---
 doc/guides/sample_app_ug/index.rst | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/doc/guides/sample_app_ug/index.rst 
b/doc/guides/sample_app_ug/index.rst
index c3b50e2..d07dec3 100644
--- a/doc/guides/sample_app_ug/index.rst
+++ b/doc/guides/sample_app_ug/index.rst
@@ -33,41 +33,6 @@ Sample Applications User Guide

 |today|

-INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS.
-NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL 
PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT.
-EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS,
-INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR 
IMPLIED WARRANTY,
-RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR 
WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE,
-MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER 
INTELLECTUAL PROPERTY RIGHT.
-
-A "Mission Critical Application" is any application in which failure of the 
Intel Product could result, directly or indirectly, in personal injury or death.
-SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL 
APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES,
-SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF 
EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES,
-AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR 
INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY,
-OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION,
-WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN,
-MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS.
-
-Intel may make changes to specifications and product descriptions at any time, 
without notice.
-Designers must not rely on the absence or characteristics of any features or 
instructions marked "reserved" or "undefined".
-Intel reserves these for future definition and shall have no responsibility 
whatsoever for conflicts or incompatibilities arising from future changes to 
them.
-The information here is subject to change without notice.
-Do not finalize a design with this information.
-
-The products described in this document may contain design defects or errors 
known as errata which may cause the product to deviate from published 
specifications.
-Current characterized errata are available on request.
-
-Contact your local Intel sales office or your distributor to obtain the latest 
specifications and before placing your product order.
-
-Copies of documents which have an order number and are referenced in this 
document, or other Intel literature, may be obtained by calling 1-800-548-4725, 
or go to:
-`http://www.intel.com/design/literature.htm 
`_.
-
-Intel and the Intel logo are trademarks or registered trademarks of Intel 
Corporation or its subsidiaries in the United States and other countries.
-
-\*Other names and brands may be claimed as the property of others.
-
-Copyright ? 2012 - 2014, Intel Corporation. All rights reserved.
-
 **Contents**

 .. toctree::
-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct

[Stephen Hemminger]

On Thu, 18 Dec 2014 14:55:23 +
ciara.loftus at intel.com wrote:

> diff --git a/lib/librte_vhost/rte_virtio_net.h 
> b/lib/librte_vhost/rte_virtio_net.h
> index 00b1328..aebb4b5 100644
> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -96,6 +96,7 @@ struct virtio_net {
>   uint64_tfeatures;   /**< Negotiated feature set. */
>   uint64_tdevice_fh;  /**< device identifier. */
>   uint32_tflags;  /**< Device flags. Only used to 
> check if device is running on data core. */
> + charifname[32]; /** Name of the tap device **/

Linux and BSD the maximum network device name size is 16

[dpdk-dev] Error while installing OVS with DPDK

[Shankari Vaidyalingam]

Hi,

I'm trying to install OVS with DPDK

Followed the steps given in INSTALL.DPDK.md file given in the OVS page.

I have downloaded latest tar ball of both OVS and DPDK.

DPDK version - 1.7.1

OVS version - 2.3.1

Operating system - Ubuntu 12.04 LTS (64 bit)

When I tried running make I got the below errors in dpdk library files.

Would like to know whether I'm missing something while installation.

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I ./include -I ./lib -I ./lib
-I/home/controller/PoC/software/Pktgen-DPDK/dpdk/x86_64-native-linuxapp-gcc//include
-Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-arith
-Wdeclaration-after-statement -Wformat-security -Wno-format-zero-length
-Wswitch-enum -Wunused-parameter -Wstrict-aliasing -Wbad-function-cast
-Wcast-align -Wmissing-prototypes -Wmissing-field-initializers -g -O2 -MT
lib/netdev-dpdk.lo -MD -MP -MF lib/.deps/netdev-dpdk.Tpo -c
lib/netdev-dpdk.c -o lib/netdev-dpdk.o
In file included from
/home/controller/PoC/software/Pktgen-DPDK/dpdk/x86_64-native-linuxapp-gcc//include/rte_ring.h:98:0,
 from
/home/controller/PoC/software/Pktgen-DPDK/dpdk/x86_64-native-linuxapp-gcc//include/rte_mempool.h:74,
 from
/home/controller/PoC/software/Pktgen-DPDK/dpdk/x86_64-native-linuxapp-gcc//include/rte_mbuf.h:61,
 from
/home/controller/PoC/software/Pktgen-DPDK/dpdk/x86_64-native-linuxapp-gcc//include/rte_ethdev.h:178,
 from lib/netdev-dpdk.h:12,
 from lib/ofpbuf.h:25,
 from lib/dpif-netdev.h:24,
 from lib/netdev-dpdk.c:31:
/home/controller/PoC/software/Pktgen-DPDK/dpdk/x86_64-native-linuxapp-gcc//include/rte_common.h:
In function 'rte_is_aligned':
/home/controller/PoC/software/Pktgen-DPDK/dpdk/x86_64-native-linuxapp-gcc//include/rte_common.h:176:9:
warning: cast from function call of type 'uintptr_t' to non-matching type
'void *' [-Wbad-function-cast]
lib/netdev-dpdk.c: In function 'dpdk_class_init':
lib/netdev-dpdk.c:1081:5: warning: implicit declaration of function
'rte_pmd_init_all' [-Wimplicit-function-declaration]
lib/netdev-dpdk.c: In function 'dpdk_init':
lib/netdev-dpdk.c:1189:5: error: too few arguments to function
'rte_memzone_dump'
/home/controller/PoC/software/Pktgen-DPDK/dpdk/x86_64-native-linuxapp-gcc//include/rte_memzone.h:253:6:
note: declared here
make[2]: *** [lib/netdev-dpdk.lo] Error 1
make[2]: Leaving directory `/home/controller/PoC/LLDP/openvswitch-2.3.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/controller/PoC/LLDP/openvswitch-2.3.1'
make: *** [all] Error 2

Regards,

Shankari.V

[dpdk-dev] [PATCH v2 1/2] doc: remove intel dpdk in sample app ug

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler
> Sent: Thursday, December 18, 2014 10:51 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 1/2] doc: remove intel dpdk in sample app ug
> 
> Removed redundant references to Intel(R) DPDK in Sample App UG.
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct

[Vincent JARDIN]

>> +charifname[32]; /** Name of the tap device **/
>
> Linux and BSD the maximum network device name size is 16
>
In any case, please, use IF_NAMESIZE or IFNAMSIZ

see:
http://fxr.watson.org/fxr/ident?v=FREEBSD51;im=bigexcerpts;i=IF_NAMESIZE

[dpdk-dev] [PATCH v2 2/2] doc: remove intel legal blurb from sample app ug

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler
> Sent: Thursday, December 18, 2014 4:04 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 2/2] doc: remove intel legal blurb from sample 
> app ug
> 
> Removed Legal blurb from sample applications guide.
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Thomas Monjalon]

2014-12-18 08:17, Stephen Hemminger:
> On Wed, 17 Dec 2014 12:03:28 -0500
> Neil Horman  wrote:
[...]
> > The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  
> > This
> > patch makes the needed correction to avoid a build break
[...]
> 
> If we could fix the header incompatiablities then the driver could use
> a standard library like ether_aton() instead of dragging in the unnecessary
> cmdline library.

Right.
A first fix was done to remove conflict with netinet/in.h:
http://dpdk.org/browse/dpdk/commit/?id=d07180f211
But there still are conflicts with netinet/ether.h and maybe more.
I suggest to fix it in the release 2.0.

-- 
Thomas

[dpdk-dev] [PATCH] doc: added copyright to dist sample app images

[Siobhan Butler]

Added copyright to distributor sample app images.

Signed-off-by: Siobhan Butler 
---
 doc/guides/sample_app_ug/img/dist_app.svg  | 36 -
 doc/guides/sample_app_ug/img/dist_perf.svg | 37 +-
 2 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/doc/guides/sample_app_ug/img/dist_app.svg 
b/doc/guides/sample_app_ug/img/dist_app.svg
index 3bb912b..4714c7d 100644
--- a/doc/guides/sample_app_ug/img/dist_app.svg
+++ b/doc/guides/sample_app_ug/img/dist_app.svg
@@ -1,5 +1,39 @@
 
-
+
+

 http://purl.org/dc/elements/1.1/";
diff --git a/doc/guides/sample_app_ug/img/dist_perf.svg 
b/doc/guides/sample_app_ug/img/dist_perf.svg
index 5a2720b..7338dca 100644
--- a/doc/guides/sample_app_ug/img/dist_perf.svg
+++ b/doc/guides/sample_app_ug/img/dist_perf.svg
@@ -1,5 +1,40 @@
 
-
+
+
+

 http://purl.org/dc/elements/1.1/";
-- 
1.9.4.msysgit.2

[dpdk-dev] [PATCH 2/2] doc: updating from 1.7 to 1.8 release note

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler
> Sent: Thursday, December 18, 2014 2:52 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 2/2] doc: updating from 1.7 to 1.8 release note
> 
> Added instructions for updating from DPDK 1.7.0 to 1.8.0
> 
> Signed-off-by: Siobhan Butler 
> 
> Signed-off-by: Bruce Richardson 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct

[Loftus, Ciara]

Hi Thomas,

A basic vHost use case will work, for example a single Virtual Machine with a 
vHost port. However normal vSwitching use cases will require the use of 
multiple vHost ports and multiple VMs. With that in mind, it is essential that 
the vSwitch has some way of knowing which vHost port it is sending to and 
receiving packets from. This patch resolves this issue by exposing the tap 
device name of the vHost device. Without that information we cannot determine 
the particular vHost port to send/receive from, which in the context of 
switching, is a critical problem.

Thanks,
Ciara

-Original Message-
From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] 
Sent: Thursday, December 18, 2014 3:33 PM
To: Loftus, Ciara
Cc: dev at dpdk.org; Anthony Fee
Subject: Re: [dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct

2014-12-18 14:55, ciara.loftus at intel.com:
> This patch fixes the issue whereby when using userspace vhost ports in 
> the context of vSwitching, the name provided to the hypervisor/QEMU of 
> the vhost tap device needs to be exposed in the library, in order for 
> the vSwitch to be able to direct packets to the correct device.

Do you mean that vhost was not working at all?
Please precise the context and how it is critical.
More informations are needed to understand wether it should be merged in 
release 1.8.0 or not.

> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -96,6 +96,7 @@ struct virtio_net {
>   uint64_tfeatures;   /**< Negotiated feature set. */
>   uint64_tdevice_fh;  /**< device identifier. */
>   uint32_tflags;  /**< Device flags. Only used to 
> check if device is running on data core. */
> + charifname[32]; /** Name of the tap device **/

Wrong comment style.

--
Thomas
--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

[dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of ciara.loftus at 
> intel.com
> Sent: Thursday, December 18, 2014 2:55 PM
> To: dev at dpdk.org
> Cc: Anthony Fee
> Subject: [dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct
> 
> From: Ciara Loftus 
> 
> This patch fixes the issue whereby when using userspace vhost ports
> in the context of vSwitching, the name provided to the hypervisor/QEMU
> of the vhost tap device needs to be exposed in the library, in order
> for the vSwitch to be able to direct packets to the correct device.
> This patch introduces an 'ifname' member to the virtio-net structure
> which is populated with the tap device name when QEMU is brought up
> with a vhost device.
> 
> Signed-off-by: Ciara Loftus 
> Signed-off-by: Anthony Fee 
> Acked-by: Huawei Xie 
> ---
>  lib/librte_vhost/rte_virtio_net.h |1 +
>  lib/librte_vhost/virtio-net.c |   41 
> -
>  2 files changed, 41 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/librte_vhost/rte_virtio_net.h 
> b/lib/librte_vhost/rte_virtio_net.h
> index 00b1328..aebb4b5 100644
> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -96,6 +96,7 @@ struct virtio_net {
>   uint64_tfeatures;   /**< Negotiated feature set. */
>   uint64_tdevice_fh;  /**< device identifier. */
>   uint32_tflags;  /**< Device flags. Only used to 
> check if device is running on data core. */
> + charifname[32]; /** Name of the tap device **/
>   void*priv;  /**< private context */
>  } __rte_cache_aligned;
> 
> diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
> index 852b6d1..7f90ecf 100644
> --- a/lib/librte_vhost/virtio-net.c
> +++ b/lib/librte_vhost/virtio-net.c
> @@ -43,6 +43,10 @@
>  #include 
>  #include 
> 
> +#include 
> +#include 
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -1000,6 +1004,39 @@ set_vring_kick(struct vhost_device_ctx ctx, struct 
> vhost_vring_file *file)
>  }
> 
>  /*
> + * Function to get the tap device name from the provided file descriptor and
> + * save it in the device structure.
> + */
> +static int
> +get_ifname(struct virtio_net *dev, int tap_fd, int pid)
> +{
> + struct eventfd_copy fd_tap;
> + struct ifreq ifr;
> + uint32_t size;
> +
> + fd_tap.source_fd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
> + fd_tap.target_fd = tap_fd;
> + fd_tap.target_pid = pid;
> +
> + if (eventfd_copy(dev, &fd_tap))
> + return -1;
> +
> + ioctl(fd_tap.source_fd, TUNGETIFF, &ifr);

Shouldn't we check that ioctl() returns with success here,
and if it fails, don't copy stuff over?

> +
> + if (close(fd_tap.source_fd) < 0)
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "(%"PRIu64") fd close failed\n",
> + dev->device_fh);
> +
> + size = strnlen(ifr.ifr_name, sizeof(ifr.ifr_name)) > 
> sizeof(dev->ifname)?
> + sizeof(dev->ifname): strnlen(ifr.ifr_name, 
> sizeof(ifr.ifr_name));
> +

So if sizeof(ifr.ifr_name) > sizeof(dev->ifname) then we can endup with 
dev->ifname not being null-termianted?
Another nit: there is no need to call strnlen() twice.

Konstantin

> + strncpy(dev->ifname, ifr.ifr_name, size);
> +
> + return 0;
> +}
> +
> +/*
>   * Called from CUSE IOCTL: VHOST_NET_SET_BACKEND
>   * To complete device initialisation when the virtio driver is loaded,
>   * we are provided with a valid fd for a tap device (not used by us).
> @@ -1026,8 +1063,10 @@ set_backend(struct vhost_device_ctx ctx, struct 
> vhost_vring_file *file)
>*/
>   if (!(dev->flags & VIRTIO_DEV_RUNNING)) {
>   if (((int)dev->virtqueue[VIRTIO_TXQ]->backend != 
> VIRTIO_DEV_STOPPED) &&
> - ((int)dev->virtqueue[VIRTIO_RXQ]->backend != 
> VIRTIO_DEV_STOPPED))
> + ((int)dev->virtqueue[VIRTIO_RXQ]->backend != 
> VIRTIO_DEV_STOPPED)) {
> + get_ifname(dev, file->fd, ctx.pid);
>   return notify_ops->new_device(dev);
> + }
>   /* Otherwise we remove it. */
>   } else
>   if (file->fd == VIRTIO_DEV_STOPPED)
> --
> 1.7.4.1

[dpdk-dev] [PATCH 1/2] doc: add vxlan support to release notes

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler
> Sent: Thursday, December 18, 2014 2:52 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/2] doc: add vxlan support to release notes
> 
> Added to New and Supported features for VXLAN feature.
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH] doc: added copyright to dist sample app images

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Siobhan Butler
> Sent: Thursday, December 18, 2014 4:35 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: added copyright to dist sample app images
> 
> Added copyright to distributor sample app images.
> 
> Signed-off-by: Siobhan Butler 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct

[Xie, Huawei]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Loftus, Ciara
> Sent: Thursday, December 18, 2014 10:02 AM
> To: Thomas Monjalon
> Cc: dev at dpdk.org; Anthony Fee
> Subject: Re: [dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct
> 
> Hi Thomas,
> 
> A basic vHost use case will work, for example a single Virtual Machine with a
> vHost port. However normal vSwitching use cases will require the use of 
> multiple
> vHost ports and multiple VMs. With that in mind, it is essential that the 
> vSwitch
> has some way of knowing which vHost port it is sending to and receiving 
> packets
> from. This patch resolves this issue by exposing the tap device name of the
> vHost device. Without that information we cannot determine the particular
> vHost port to send/receive from, which in the context of switching, is a 
> critical
> problem.


For example, in qemu command line, we specify tap device "tap1" for virtio 
device in "VM1", and "tap2" for virtio device in "VM2".
vSwitch wants to expose the tap device name in the virtio_net device structure 
otherwise it doesn't know the virtio_device it gets
is for which VM.
The mac address isn't enough for vSwitch.
The problem is for vhost-user, we have no such kind of identity, unless we 
create socket for each virtio device, and use the socket
path string.

> 
> Thanks,
> Ciara
> 
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, December 18, 2014 3:33 PM
> To: Loftus, Ciara
> Cc: dev at dpdk.org; Anthony Fee
> Subject: Re: [dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct
> 
> 2014-12-18 14:55, ciara.loftus at intel.com:
> > This patch fixes the issue whereby when using userspace vhost ports in
> > the context of vSwitching, the name provided to the hypervisor/QEMU of
> > the vhost tap device needs to be exposed in the library, in order for
> > the vSwitch to be able to direct packets to the correct device.
> 
> Do you mean that vhost was not working at all?
> Please precise the context and how it is critical.
> More informations are needed to understand wether it should be merged in
> release 1.8.0 or not.
> 
> > --- a/lib/librte_vhost/rte_virtio_net.h
> > +++ b/lib/librte_vhost/rte_virtio_net.h
> > @@ -96,6 +96,7 @@ struct virtio_net {
> > uint64_tfeatures;   /**< Negotiated feature set.
> */
> > uint64_tdevice_fh;  /**< device identifier. */
> > uint32_tflags;  /**< Device flags. Only used to
> check if device is running on data core. */
> > +   charifname[32]; /** Name of the tap device
> **/
> 
> Wrong comment style.
> 
> --
> Thomas 

[dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct

[Czesnowicz, Przemyslaw]

> Hi Thomas,
> 
> A basic vHost use case will work, for example a single Virtual Machine with a
> vHost port. However normal vSwitching use cases will require the use of 
> multiple
> vHost ports and multiple VMs. With that in mind, it is essential that the 
> vSwitch
> has some way of knowing which vHost port it is sending to and receiving 
> packets
> from. This patch resolves this issue by exposing the tap device name of the
> vHost device. Without that information we cannot determine the particular
> vHost port to send/receive from, which in the context of switching, is a 
> critical
> problem.


Exactly.
The vSwitch uses tap name to associate the virtio device with ovs port.
Without this change the vhost library cannot be used in vSwitch.

Regards
Przemek

> 
> Thanks,
> Ciara
> 

[dpdk-dev] rte_mempool_create fails with ENOMEM

[Ananyev, Konstantin]

Hi 

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Newman Poborsky
> Sent: Thursday, December 18, 2014 1:26 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] rte_mempool_create fails with ENOMEM
> 
> Hi,
> 
> could someone please provide any explanation why sometimes mempool creation
> fails with ENOMEM?
> 
> I run my test app several times without any problems and then I start
> getting ENOMEM error when creating mempool that are used for packets. I try
> to delete everything from /mnt/huge, I increase the number of huge pages,
> remount /mnt/huge but nothing helps.
> 
> There is more than enough memory on server. I tried to debug
> rte_mempool_create() call and it seems that after server is restarted free
> mem segments are bigger than 2MB, but after running test app for several
> times, it seems that all free mem segments have a size of 2MB, and since I
> am requesting 8MB for my packet mempool, this fails.  I'm not really sure
> that this conclusion is correct.

Yes,rte_mempool_create uses  rte_memzone_reserve() to allocate
single physically continuous chunk of memory.
If no such chunk exist, then it would fail.
Why physically continuous?
Main reason - to make things easier for us, as in that case we don't have to 
worry
about situation when mbuf crosses page boundary. 
So you can overcome that problem like that:
Allocate max amount of memory you would need to hold all mbufs in worst case 
(all pages physically disjoint)
using rte_malloc().
Figure out it's physical mappings.
Call  rte_mempool_xmem_create().
You can look at: app/test-pmd/mempool_anon.c as a reference.
It uses same approach to create mempool over 4K pages.

We probably add similar function into mempool API (create_scatter_mempool or 
something)
or just add a new flag (USE_SCATTER_MEM) into rte_mempool_create().
Though right now it is not there.

Another quick alternative - use 1G pages.

Konstantin

> 
> Does anybody have any idea what to check and how running my test app
> several times affects hugepages?
> 
> For me, this doesn't make any since because after test app exits, resources
> should be freed, right?
> 
> This has been driving me crazy for days now. I tried reading a bit more
> theory about hugepages, but didn't find out anything that could help me.
> Maybe it's something else and completely trivial, but I can't figure it
> out, so any help is appreciated.
> 
> Thank you!
> 
> BR,
> Newman P.

[dpdk-dev] [PATCH v2] ixgbe_vf: Fix getting link state

[Balazs Nemeth]

This patch fixes checking the link state of a virtual function. If the
state has already been checked, it does not need to be checked
again. Previously, get_link_status in the ixgbe_hw struct was used to
track if the information had already been retrieved, but this field
was always set to false (signifying that the information was
up-to-date). The problem was introduced by commit 8ef32003 which was
part of a patch set to update the ixgbe portion of the PMD. This patch
does not break consistency with the ixgbevf driver. Instead, it fixes
the problem at the level of DPDK.

Applications that rely on the reported link speed could fail without
this patch. The qos_sched example application provided with DPDK did
not run when virtual functions were used. The output for this example
application is shown below:

EAL: Error - exiting with code: 1
  Cause: Unable to config sched subport 0, err=-2

The problem and the effect of the patch can been seen by running the
l2fwd example application using the following command:

sudo ./build/l2fwd -c 0x3 -n 4 -- -p 0x3 -T 0

Before the patch has been applied (with both links up):
...
Checking link statusdone
Port 0 Link Up - speed 100 Mbps - half-duplex

Port 1 Link Up - speed 100 Mbps - half-duplex

L2FWD: entering main loop on lcore 1
...

After the patch has been applied (with both links up):
...
Checking link statusdone
Port 0 Link Up - speed 1 Mbps - full-duplex
Port 1 Link Up - speed 1 Mbps - full-duplex
L2FWD: entering main loop on lcore 1
...

Before the patch has been applied (with link 0 down, link 1 up):
...
Checking link statusdone
Port 0 Link Up - speed 100 Mbps - half-duplex

Port 1 Link Up - speed 100 Mbps - half-duplex

L2FWD: entering main loop on lcore 1
...

After the patch has been applied (with link 0 down, link 1 up):
...
Checking link status
..done
Port 0 Link Down
Port 1 Link Up - speed 1 Mbps - full-duplex
...

Signed-off-by: Balazs Nemeth 
---

changes v2:
* Include more elaborate explanation of the problem in the commit message
* Fix the issue at the level of DPDK not touching ixgbe driver code

 lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c 
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
index 9401916..7e6 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
@@ -1469,6 +1469,7 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
if (status != 0)
return -1;
hw->mac.ops.start_hw(hw);
+   hw->mac.get_link_status = true;

/* configure PF module if SRIOV enabled */
ixgbe_pf_host_configure(dev);
@@ -2064,7 +2065,7 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev, int 
wait_to_complete)
 {
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_eth_link link, old;
-   ixgbe_link_speed link_speed;
+   ixgbe_link_speed link_speed = IXGBE_LINK_SPEED_UNKNOWN;
int link_up;
int diag;

@@ -2088,6 +2089,12 @@ 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)
@@ -2926,6 +2933,7 @@ ixgbevf_dev_start(struct rte_eth_dev *dev)
PMD_INIT_FUNC_TRACE();

hw->mac.ops.reset_hw(hw);
+   hw->mac.get_link_status = true;

/* negotiate mailbox API version to use with the PF. */
ixgbevf_negotiate_api(hw);
--
2.1.3

[dpdk-dev] [PATCH v2] vhost: add interface name to virtio-net struct

[ciara.lof...@intel.com]

From: Ciara Loftus 

This patch fixes the issue whereby when using userspace vhost ports
in the context of vSwitching, the name provided to the hypervisor/QEMU
of the vhost tap device needs to be exposed in the library, in order
for the vSwitch to be able to direct packets to the correct device.
This patch introduces an 'ifname' member to the virtio-net structure
which is populated with the tap device name when QEMU is brought up
with a vhost device.

Signed-off-by: Ciara Loftus 
Signed-off-by: Anthony Fee 
Acked-by: Huawei Xie 
---
 lib/librte_vhost/rte_virtio_net.h |3 ++
 lib/librte_vhost/virtio-net.c |   48 -
 2 files changed, 50 insertions(+), 1 deletions(-)

diff --git a/lib/librte_vhost/rte_virtio_net.h 
b/lib/librte_vhost/rte_virtio_net.h
index 00b1328..0bf07c7 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -43,6 +43,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 
 #include 
@@ -96,6 +98,7 @@ struct virtio_net {
uint64_tfeatures;   /**< Negotiated feature set. */
uint64_tdevice_fh;  /**< device identifier. */
uint32_tflags;  /**< Device flags. Only used to 
check if device is running on data core. */
+   charifname[IFNAMSIZ];   /**< Name of the tap 
device. */
void*priv;  /**< private context */
 } __rte_cache_aligned;

diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index 852b6d1..7eae5ee 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -43,6 +43,10 @@
 #include 
 #include 

+#include 
+#include 
+#include 
+
 #include 
 #include 
 #include 
@@ -1000,6 +1004,46 @@ set_vring_kick(struct vhost_device_ctx ctx, struct 
vhost_vring_file *file)
 }

 /*
+ * Function to get the tap device name from the provided file descriptor and
+ * save it in the device structure.
+ */
+static int
+get_ifname(struct virtio_net *dev, int tap_fd, int pid)
+{
+   struct eventfd_copy fd_tap;
+   struct ifreq ifr;
+   uint32_t size, ifr_size;
+   int ret;
+
+   fd_tap.source_fd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
+   fd_tap.target_fd = tap_fd;
+   fd_tap.target_pid = pid;
+
+   if (eventfd_copy(dev, &fd_tap))
+   return -1;
+
+   ret = ioctl(fd_tap.source_fd, TUNGETIFF, &ifr);
+
+   if (close(fd_tap.source_fd) < 0)
+   RTE_LOG(ERR, VHOST_CONFIG,
+   "(%"PRIu64") fd close failed\n",
+   dev->device_fh);
+
+   if (ret >= 0) {
+   ifr_size = strnlen(ifr.ifr_name, sizeof(ifr.ifr_name));
+   size = ifr_size > sizeof(dev->ifname)?
+   sizeof(dev->ifname): ifr_size;
+
+   strncpy(dev->ifname, ifr.ifr_name, size);
+   } else
+   RTE_LOG(ERR, VHOST_CONFIG,
+   "(%"PRIu64") TUNGETIFF ioctl failed\n",
+   dev->device_fh);
+
+   return 0;
+}
+
+/*
  * Called from CUSE IOCTL: VHOST_NET_SET_BACKEND
  * To complete device initialisation when the virtio driver is loaded,
  * we are provided with a valid fd for a tap device (not used by us).
@@ -1026,8 +1070,10 @@ set_backend(struct vhost_device_ctx ctx, struct 
vhost_vring_file *file)
 */
if (!(dev->flags & VIRTIO_DEV_RUNNING)) {
if (((int)dev->virtqueue[VIRTIO_TXQ]->backend != 
VIRTIO_DEV_STOPPED) &&
-   ((int)dev->virtqueue[VIRTIO_RXQ]->backend != 
VIRTIO_DEV_STOPPED))
+   ((int)dev->virtqueue[VIRTIO_RXQ]->backend != 
VIRTIO_DEV_STOPPED)) {
+   get_ifname(dev, file->fd, ctx.pid);
return notify_ops->new_device(dev);
+   }
/* Otherwise we remove it. */
} else
if (file->fd == VIRTIO_DEV_STOPPED)
-- 
1.7.4.1

[dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct

[Loftus, Ciara]

Hi Konstantin,

Thank you for the feedback. 

As regards the following:
"So if sizeof(ifr.ifr_name) > sizeof(dev->ifname) then we can endup with 
dev->ifname not being null-termianted?"
This should never be the case as now both dev->ifname and ifr.ifr_name are of 
size IFNAMSIZ in v2 of the patch.

Thanks,
Ciara

-Original Message-
From: Ananyev, Konstantin 
Sent: Thursday, December 18, 2014 5:03 PM
To: Loftus, Ciara; dev at dpdk.org
Cc: Anthony Fee
Subject: RE: [dpdk-dev] [PATCH] vhost: add interface name to virtio-net struct



> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of 
> ciara.loftus at intel.com
> Sent: Thursday, December 18, 2014 2:55 PM
> To: dev at dpdk.org
> Cc: Anthony Fee
> Subject: [dpdk-dev] [PATCH] vhost: add interface name to virtio-net 
> struct
> 
> From: Ciara Loftus 
> 
> This patch fixes the issue whereby when using userspace vhost ports in 
> the context of vSwitching, the name provided to the hypervisor/QEMU of 
> the vhost tap device needs to be exposed in the library, in order for 
> the vSwitch to be able to direct packets to the correct device.
> This patch introduces an 'ifname' member to the virtio-net structure 
> which is populated with the tap device name when QEMU is brought up 
> with a vhost device.
> 
> Signed-off-by: Ciara Loftus 
> Signed-off-by: Anthony Fee 
> Acked-by: Huawei Xie 
> ---
>  lib/librte_vhost/rte_virtio_net.h |1 +
>  lib/librte_vhost/virtio-net.c |   41 
> -
>  2 files changed, 41 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/librte_vhost/rte_virtio_net.h 
> b/lib/librte_vhost/rte_virtio_net.h
> index 00b1328..aebb4b5 100644
> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -96,6 +96,7 @@ struct virtio_net {
>   uint64_tfeatures;   /**< Negotiated feature set. */
>   uint64_tdevice_fh;  /**< device identifier. */
>   uint32_tflags;  /**< Device flags. Only used to 
> check if device is running on data core. */
> + charifname[32]; /** Name of the tap device **/
>   void*priv;  /**< private context */
>  } __rte_cache_aligned;
> 
> diff --git a/lib/librte_vhost/virtio-net.c 
> b/lib/librte_vhost/virtio-net.c index 852b6d1..7f90ecf 100644
> --- a/lib/librte_vhost/virtio-net.c
> +++ b/lib/librte_vhost/virtio-net.c
> @@ -43,6 +43,10 @@
>  #include 
>  #include 
> 
> +#include 
> +#include 
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -1000,6 +1004,39 @@ set_vring_kick(struct vhost_device_ctx ctx, 
> struct vhost_vring_file *file)  }
> 
>  /*
> + * Function to get the tap device name from the provided file 
> +descriptor and
> + * save it in the device structure.
> + */
> +static int
> +get_ifname(struct virtio_net *dev, int tap_fd, int pid) {
> + struct eventfd_copy fd_tap;
> + struct ifreq ifr;
> + uint32_t size;
> +
> + fd_tap.source_fd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
> + fd_tap.target_fd = tap_fd;
> + fd_tap.target_pid = pid;
> +
> + if (eventfd_copy(dev, &fd_tap))
> + return -1;
> +
> + ioctl(fd_tap.source_fd, TUNGETIFF, &ifr);

Shouldn't we check that ioctl() returns with success here, and if it fails, 
don't copy stuff over?

> +
> + if (close(fd_tap.source_fd) < 0)
> + RTE_LOG(ERR, VHOST_CONFIG,
> + "(%"PRIu64") fd close failed\n",
> + dev->device_fh);
> +
> + size = strnlen(ifr.ifr_name, sizeof(ifr.ifr_name)) > 
> sizeof(dev->ifname)?
> + sizeof(dev->ifname): strnlen(ifr.ifr_name, 
> sizeof(ifr.ifr_name));
> +

So if sizeof(ifr.ifr_name) > sizeof(dev->ifname) then we can endup with 
dev->ifname not being null-termianted?
Another nit: there is no need to call strnlen() twice.

Konstantin

> + strncpy(dev->ifname, ifr.ifr_name, size);
> +
> + return 0;
> +}
> +
> +/*
>   * Called from CUSE IOCTL: VHOST_NET_SET_BACKEND
>   * To complete device initialisation when the virtio driver is loaded,
>   * we are provided with a valid fd for a tap device (not used by us).
> @@ -1026,8 +1063,10 @@ set_backend(struct vhost_device_ctx ctx, struct 
> vhost_vring_file *file)
>*/
>   if (!(dev->flags & VIRTIO_DEV_RUNNING)) {
>   if (((int)dev->virtqueue[VIRTIO_TXQ]->backend != 
> VIRTIO_DEV_STOPPED) &&
> - ((int)dev->virtqueue[VIRTIO_RXQ]->backend != 
> VIRTIO_DEV_STOPPED))
> + ((int)dev->virtqueue[VIRTIO_RXQ]->backend != 
> VIRTIO_DEV_STOPPED)) {
> + get_ifname(dev, file->fd, ctx.pid);
>   return notify_ops->new_device(dev);
> + }
>   /* Otherwise we remove it. */
>   } else
>   if (file->fd == VIRTIO_DEV_STOPPED)
> --
> 1.7.4.1

--
Intel Shannon Li

[dpdk-dev] [PATCH] Minor fixes in rte_common.h file.

[Neil Horman]

On Wed, Dec 17, 2014 at 08:40:17AM -0800, Ravi Kerur wrote:
> On Tue, Dec 16, 2014 at 1:40 PM, Neil Horman  wrote:
> >
> > On Tue, Dec 16, 2014 at 08:46:51AM -0800, Ravi Kerur wrote:
> > > On Sat, Dec 13, 2014 at 2:39 AM, Neil Horman 
> > wrote:
> > > >
> > > > On Fri, Dec 12, 2014 at 03:04:34PM -0800, r k wrote:
> > > > > Subject: [PATCH] Minor fixes in rte_common.h file.
> > > > >
> > > > > Fix rte_is_power_of_2 since 0 is not.
> > > > > Avoid branching instructions in RTE_MAX and RTE_MIN.
> > > > >
> > > > > Signed-off-by: Ravi Kerur 
> > > > > ---
> > > > >  lib/librte_eal/common/include/rte_common.h | 6 +++---
> > > > >  lib/librte_pmd_e1000/igb_pf.c  | 4 ++--
> > > > >  lib/librte_pmd_ixgbe/ixgbe_pf.c| 4 ++--
> > > > >  3 files changed, 7 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/lib/librte_eal/common/include/rte_common.h
> > > > > b/lib/librte_eal/common/include/rte_common.h
> > > > > index 921b91f..e163f35 100644
> > > > > --- a/lib/librte_eal/common/include/rte_common.h
> > > > > +++ b/lib/librte_eal/common/include/rte_common.h
> > > > > @@ -203,7 +203,7 @@ extern int RTE_BUILD_BUG_ON_detected_error;
> > static
> > > > > inline int  rte_is_power_of_2(uint32_t n)  {
> > > > > -   return ((n-1) & n) == 0;
> > > > > +   return n && !(n & (n - 1));
> > > > >  }
> > > > >
> > > > >  /**
> > > > > @@ -259,7 +259,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MIN(a,
> > b)
> > > > ({ \
> > > > > typeof (a) _a = (a); \
> > > > > typeof (b) _b = (b); \
> > > > > -   _a < _b ? _a : _b; \
> > > > > +_b ^ ((_a ^ _b) & -(_a < _b)); \
> > > > Are you sure this is actually faster than the branch version?  What
> > about
> > > > using
> > > > a cmov instead?
> > > >
> > > >
> > >  i am pretty sure modified code is faster than branching. I remember
> > > cmov had performance issues esp. on Pentuim-4 not sure how new intel
> > cpu's
> > > perform.
> > >
> > Pretty sure isn't sure.  Theres no point in code churn if theres no obvious
> > advantage.  Some perf tests to deomonstrate the advantage here would be
> > great.
> >
> 
>  I have used this before with the intent to avoid branching and it was
> part of other changes I did for performance improvement in our code.
> 

Then it should be pretty easy to provide the perf data demonstrating the
advantage in this code.

> >
> > > > })
> > > > >
> > > > >  /**
> > > > > @@ -268,7 +268,7 @@ rte_align64pow2(uint64_t v)  #define RTE_MAX(a,
> > b)
> > > > ({ \
> > > > > typeof (a) _a = (a); \
> > > > > typeof (b) _b = (b); \
> > > > > -   _a > _b ? _a : _b; \
> > > > > +   _a ^ ((_a ^ _b) & -(_a < _b)); \
> > > > Same as above
> > > >
> > > >  Same as above.
> > >
> > > > > })
> > > > >
> > > > >  /*** Other general functions / macros / diff --git
> > > > > a/lib/librte_pmd_e1000/igb_pf.c b/lib/librte_pmd_e1000/igb_pf.c index
> > > > > bc3816a..546499c 100644
> > > > > --- a/lib/librte_pmd_e1000/igb_pf.c
> > > > > +++ b/lib/librte_pmd_e1000/igb_pf.c
> > > > > @@ -321,11 +321,11 @@ igb_vf_set_mac_addr(struct rte_eth_dev *dev,
> > > > uint32_t
> > > > > vf, uint32_t *msgbuf)  static int  igb_vf_set_multicast(struct
> > > > rte_eth_dev
> > > > > *dev, __rte_unused uint32_t vf, uint32_t *msgbuf)  {
> > > > > -   int i;
> > > > > +   int16_t i;
> > > > > uint32_t vector_bit;
> > > > > uint32_t vector_reg;
> > > > > uint32_t mta_reg;
> > > > > -   int entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
> > > > > +   int32_t entries = (msgbuf[0] & E1000_VT_MSGINFO_MASK) >>
> > > > > E1000_VT_MSGINFO_SHIFT;
> > > > NAK, this has nothing to do with the included changelog
> > > >
> > >
> > >  It does, it causes compilation errors such as
> > >
> > > /root/dpdk-new/dpdk/lib/librte_pmd_e1000/igb_pf.c: In function
> > > \u2018igb_pf_mbx_process\u2019:
> > > /root/dpdk-new/dpdk/lib/librte_pmd_e1000/igb_pf.c:350:23: error: array
> > > subscript is above array bounds [-Werror=array-bounds]
> > >vfinfo->vf_mc_hashes[i] = hash_list[i];
> > >^
> > > cc1: all warnings being treated as errors
> > >
> > > Also it is always better to use explicit int definitions esp. for 64bit
> > > systems.
> > >
> >
> > This is your changelog:
> > =
> > Subject: [PATCH] Minor fixes in rte_common.h file.
> >
> > Fix rte_is_power_of_2 since 0 is not.
> > Avoid branching instructions in RTE_MAX and RTE_MIN
> > =
> >
> > Nowhere does your changelog indicate that you are fixing compliation
> > errors.
> > That would in and of itself be far more serious that making micro
> > optimizations.
> > If you want to fix build breaks, great, please do, but send a patch that
> > clearly
> > indicates what the break is and how your fix

[dpdk-dev] ixgbe: fix link speed detection of ixgbevf

[Nemeth, Balazs]

This patch is actually a workaround to the problem. By setting
get_link_status just before calling ixgbe_check_link defeats the whole
purpose of the variable and results in _always_ getting the link
status. I think that this patch should be superseded by the following
patch:

http://dpdk.org/dev/patchwork/patch/2104/

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Neil Horman]

On Thu, Dec 18, 2014 at 01:21:31PM +0100, Thomas Monjalon wrote:
> 2014-12-18 06:25, Neil Horman:
> > On Wed, Dec 17, 2014 at 11:20:26PM +0100, Thomas Monjalon wrote:
> > > 2014-12-17 12:03, Neil Horman:
> > > > Signed-off-by: Neil Horman 
> > > > CC: Thomas Monjalon 
> > > 
> > > What is the meaning of CC here?
> > > 
> > CC is a tag that git send-email understands.  As it implies it cc's the 
> > post to
> > the indicated email, and records that fact in the body of the commit.
> 
> OK but why CC me when sending this patch?
Typically a tree maintainer is CC'ed when submitting a patch to a list. I've
done it on most, if not all of my previous patches (and where I didn't, I should
have).  Especially given that we're this late in the release cycle, I want to be
sure you're attention is called to a build break

Neil

> 
> -- 
> Thomas
> 

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Neil Horman]

On Thu, Dec 18, 2014 at 01:51:13PM +, Qiu, Michael wrote:
> On 2014/12/18 19:26, Neil Horman wrote:
> > On Wed, Dec 17, 2014 at 11:20:26PM +0100, Thomas Monjalon wrote:
> >> Hi Neil,
> >>
> >> 2014-12-17 12:03, Neil Horman:
> >>> Back in:
> >>>
> >>> commit aaa662e75c23c61a1d79bd4d1f9f35b4967c39db
> >>> Author: Alan Carew 
> >>> Date:   Fri Dec 5 15:19:07 2014 +0100
> >>>
> >>> cmdline: fix overflow on bsd
> >>>
> >>> The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  
> >>> This
> >>> patch makes the needed correction to avoid a build break
> >>>
> >>> Signed-off-by: Neil Horman 
> >>> CC: Thomas Monjalon 
> >> What is the meaning of CC here?
> >>
> > CC is a tag that git send-email understands.  As it implies it cc's the 
> > post to
> > the indicated email, and records that fact in the body of the commit.
> 
> But if you use --cc in git send-email will be a good choice. CC list is
> useless for patch it self, but here it will exist in commit log(although
> this style can also be seen in linux kernel)
Yes, its good to have a record of who was CCed on a patch for archival purposes,
so you can get an idea of who participated (or was expected to participate in a
review)

Neil

> 
> Thanks,
> Michael
> >>> --- a/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> >>> +++ b/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> >>> @@ -586,8 +586,9 @@ rte_eth_xenvirt_parse_args(struct xenvirt_dict *dict,
> >>>   if (!strncmp(pair[0], RTE_ETH_XENVIRT_MAC_PARAM,
> >>>   sizeof(RTE_ETH_XENVIRT_MAC_PARAM))) {
> >>>   if (cmdline_parse_etheraddr(NULL,
> >>> - pair[1],
> >>> - &dict->addr) < 0) {
> >>> + pair[1],
> >>> + &dict->addr,
> >>> + sizeof(struct ether_addr)) 
> >>> < 0) {
> >> Why not sizeof(dict->addr)?
> >>
> > Because addr is a struct ether_addr, and I always get confused when doing 
> > sizeof
> > on pointer variables, so I find it more clear to specify the type exactly.  
> > I'm
> > not bound to it though so if you like I can change it, though given its 
> > release
> > day, I figure you want to fix this build break asap.
> > Neil
> >
> >> -- 
> >> Thomas
> >>
> 
> 

[dpdk-dev] rte_mempool_create fails with ENOMEM

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Thursday, December 18, 2014 5:43 PM
> To: Newman Poborsky; dev at dpdk.org
> Subject: Re: [dpdk-dev] rte_mempool_create fails with ENOMEM
> 
> Hi
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Newman Poborsky
> > Sent: Thursday, December 18, 2014 1:26 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] rte_mempool_create fails with ENOMEM
> >
> > Hi,
> >
> > could someone please provide any explanation why sometimes mempool creation
> > fails with ENOMEM?
> >
> > I run my test app several times without any problems and then I start
> > getting ENOMEM error when creating mempool that are used for packets. I try
> > to delete everything from /mnt/huge, I increase the number of huge pages,
> > remount /mnt/huge but nothing helps.
> >
> > There is more than enough memory on server. I tried to debug
> > rte_mempool_create() call and it seems that after server is restarted free
> > mem segments are bigger than 2MB, but after running test app for several
> > times, it seems that all free mem segments have a size of 2MB, and since I
> > am requesting 8MB for my packet mempool, this fails.  I'm not really sure
> > that this conclusion is correct.
> 
> Yes,rte_mempool_create uses  rte_memzone_reserve() to allocate
> single physically continuous chunk of memory.
> If no such chunk exist, then it would fail.
> Why physically continuous?
> Main reason - to make things easier for us, as in that case we don't have to 
> worry
> about situation when mbuf crosses page boundary.
> So you can overcome that problem like that:
> Allocate max amount of memory you would need to hold all mbufs in worst case 
> (all pages physically disjoint)
> using rte_malloc().

Actually my wrong: rte_malloc()s wouldn't help you here.
You probably need to allocate some external (not managed by EAL) memory in that 
case,
may be mmap() with MAP_HUGETLB, or something similar.

> Figure out it's physical mappings.
> Call  rte_mempool_xmem_create().
> You can look at: app/test-pmd/mempool_anon.c as a reference.
> It uses same approach to create mempool over 4K pages.
> 
> We probably add similar function into mempool API (create_scatter_mempool or 
> something)
> or just add a new flag (USE_SCATTER_MEM) into rte_mempool_create().
> Though right now it is not there.
> 
> Another quick alternative - use 1G pages.
> 
> Konstantin
> 
> >
> > Does anybody have any idea what to check and how running my test app
> > several times affects hugepages?
> >
> > For me, this doesn't make any since because after test app exits, resources
> > should be freed, right?
> >
> > This has been driving me crazy for days now. I tried reading a bit more
> > theory about hugepages, but didn't find out anything that could help me.
> > Maybe it's something else and completely trivial, but I can't figure it
> > out, so any help is appreciated.
> >
> > Thank you!
> >
> > BR,
> > Newman P.

[dpdk-dev] [PATCH 1/2] doc: update mbuf section of programmer's guide for 1.8

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Tuesday, December 2, 2014 4:18 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/2] doc: update mbuf section of programmer's 
> guide for 1.8
> 
> In Release 1.8, the mbuf structure was significantly reworked to add extra 
> information, leading to the
> structure being split across two cache lines, and the data pointer being 
> replaced by an offset. The
> description of the library in the programmer's guide document needs to be 
> updated to take account of
> these changes.
> 
> Signed-off-by: Bruce Richardson 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH v2] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Neil Horman]

On Thu, Dec 18, 2014 at 01:45:54PM +, Qiu, Michael wrote:
> Hi Neil,
> 
> I think if you could add the commit author in the cc list will be better.
> 
The commit author is me, and its recorded by the Signed-off line, as well as the
Authorship tag in git.  Not really sure what you're driving at here.

> Because this could let him know about his code's issue and he is the
> always the best person to review the patch.
> 
Yes, Git already does that, as noted above.

Neil


> Thanks,
> Michael
> 
> On 2014/12/18 19:32, Neil Horman wrote:
> > Back in:
> >
> > commit aaa662e75c23c61a1d79bd4d1f9f35b4967c39db
> > Author: Alan Carew 
> > Date:   Fri Dec 5 15:19:07 2014 +0100
> >
> > cmdline: fix overflow on bsd
> >
> > The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  
> > This
> > patch makes the needed correction to avoid a build break
> >
> > Signed-off-by: Neil Horman 
> > CC: Thomas Monjalon 
> > CC: Olivier Matz 
> >
> > ---
> > Change notes
> >
> > v2: Changed sizeof(struct ether_addr) to sizeof(dict->addr)
> > ---
> >  lib/librte_pmd_xenvirt/rte_eth_xenvirt.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c 
> > b/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> > index 6555ec5..04e30c9 100644
> > --- a/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> > +++ b/lib/librte_pmd_xenvirt/rte_eth_xenvirt.c
> > @@ -586,8 +586,9 @@ rte_eth_xenvirt_parse_args(struct xenvirt_dict *dict,
> > if (!strncmp(pair[0], RTE_ETH_XENVIRT_MAC_PARAM,
> > sizeof(RTE_ETH_XENVIRT_MAC_PARAM))) {
> > if (cmdline_parse_etheraddr(NULL,
> > -   pair[1],
> > -   &dict->addr) < 0) {
> > +   pair[1],
> > +   &dict->addr,
> > +   sizeof(dict->addr)) < 0) {
> > RTE_LOG(ERR, PMD,
> > "Invalid %s device ether address\n",
> > name);
> 
> 

[dpdk-dev] [PATCH] xenvirt: Fix build break on cmdline_parse_etheraddr call

[Neil Horman]

On Thu, Dec 18, 2014 at 08:17:12AM -0800, Stephen Hemminger wrote:
> On Wed, 17 Dec 2014 12:03:28 -0500
> Neil Horman  wrote:
> 
> > Back in:
> > 
> > commit aaa662e75c23c61a1d79bd4d1f9f35b4967c39db
> > Author: Alan Carew 
> > Date:   Fri Dec 5 15:19:07 2014 +0100
> > 
> > cmdline: fix overflow on bsd
> > 
> > The author failed to fixup a call to cmdline_parse_etheraddr in xenvirt.  
> > This
> > patch makes the needed correction to avoid a build break
> > 
> > Signed-off-by: Neil Horman 
> > CC: Thomas Monjalon 
> 
> If we could fix the header incompatiablities then the driver could use
> a standard library like ether_aton() instead of dragging in the unnecessary
> cmdline library.
> 
I agree, that would be great, but I think that would be better done after the
release, since this is in compliance with how the rest of the DPDK handles this
situation currently.  Using ether_aton is definately a superior solution
however.

Neil

[dpdk-dev] [PATCH] af_packet: fix memory allocation check

[Thomas Monjalon]

2014-12-18 10:51, Daniel Mrzyglod:
> In rte_eth_af_packet.c we are we are missing NULL pointer
> checks after calls to alocate memory for queues. Add checking NULL
> pointer and error handling.
> 
> Signed-off-by: Daniel Mrzyglod 

You sent this patch twice:
http://dpdk.org/ml/archives/dev/2014-December/010331.html
http://dpdk.org/ml/archives/dev/2014-December/010333.html

And you didn't send any patch for the part "Not munmaped queue area"
of your original patch:
http://dpdk.org/ml/archives/dev/2014-December/010229.html

-- 
Thomas

[dpdk-dev] [PATCH v2 2/2] doc: Updated image files for rte_mbuf changes in 1.8

[Iremonger, Bernard]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Friday, December 12, 2014 11:22 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 2/2] doc: Updated image files for rte_mbuf 
> changes in 1.8
> 
> The two image files showing the structure of the rte_mbuf data structure 
> required some minor
> updates to take account of the changes introduced to the structure in the 1.8 
> release
> 
> Signed-off-by: Bruce Richardson 

Acked-by: Bernard Iremonger 

 I have applied the patch to my tree next/dpdk-doc.

[dpdk-dev] [PATCH] test: fix missing NULL pointer checks

[Thomas Monjalon]

2014-12-18 09:41, Daniel Mrzyglod:
> In test_sched, we are missing NULL pointer checks after calls to create the 
> mempool and to allocate an mbuf. Add in these checks using VERIFY macros.
> 
> Signed-off-by: Daniel Mrzyglod 
> ---
>  app/test/test_sched.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/app/test/test_sched.c b/app/test/test_sched.c
> index c957d80..9b6e037 100644
> --- a/app/test/test_sched.c
> +++ b/app/test/test_sched.c
> @@ -166,6 +166,7 @@ test_sched(void)
>   int err;
>  
>   mp = create_mempool();
> + VERIFY(mp != NULL,"Error create mempool\n");

A space is missing after the comma.
Is "Error creating mempool" more correct?

>   port_param.socket = 0;
>   port_param.rate = (uint64_t) 1 * 1000 * 1000 / 8;
> @@ -184,6 +185,7 @@ test_sched(void)
>  
>   for (i = 0; i < 10; i++) {
>   in_mbufs[i] = rte_pktmbuf_alloc(mp);
> + VERIFY(in_mbufs[i] != NULL, "Bad packet allocation");

An \n is missing.
"Packet allocation failed" seems more appropriate.

-- 
Thomas

[dpdk-dev] [PATCH] test: fix missing NULL pointer checks

[Neil Horman]

On Thu, Dec 18, 2014 at 09:41:47AM +, Daniel Mrzyglod wrote:
> In test_sched, we are missing NULL pointer checks after calls to create the 
> mempool and to allocate an mbuf. Add in these checks using VERIFY macros.
> 
> Signed-off-by: Daniel Mrzyglod 
> ---
>  app/test/test_sched.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/app/test/test_sched.c b/app/test/test_sched.c
> index c957d80..9b6e037 100644
> --- a/app/test/test_sched.c
> +++ b/app/test/test_sched.c
> @@ -166,6 +166,7 @@ test_sched(void)
>   int err;
>  
>   mp = create_mempool();
> + VERIFY(mp != NULL,"Error create mempool\n");
>  
>   port_param.socket = 0;
>   port_param.rate = (uint64_t) 1 * 1000 * 1000 / 8;
> @@ -184,6 +185,7 @@ test_sched(void)
>  
>   for (i = 0; i < 10; i++) {
>   in_mbufs[i] = rte_pktmbuf_alloc(mp);
> + VERIFY(in_mbufs[i] != NULL, "Bad packet allocation");
>   prepare_pkt(in_mbufs[i]);
>   }
>  
> -- 
> 2.1.0
> 
> 

Looking at the VERIFY macro, its defined as:
#define VERIFY(exp,fmt,args...) \
if (!(exp)) {   \
printf(fmt, ##args);
return -1;  \
}

Thats really bad practice, as it embodies a return into the VERIFY macro,
creating hidden function exit points that the programmer can't clean up within.
Every use of the VERIFY macro in test_sched causes the program to return without
freeing any of the memory allocated in the function (not that the function is
any good at cleaning up after itself anyway), but I would recommend that you
modify the macro as such:

#define VERIFY(exp, fmt, args...) \
if (!(exp)) { \
printf(fmt, ##args); \
0;\
} else \
1;\

}


That way you can use the macro like this:

if (VERIFY(in_mbufs[i] != NULL, "Bad packet allocation") {
//Insert cleanup code here
}

Neil

[dpdk-dev] [PATCH] af_packet: fix memory allocation check

[Neil Horman]

On Thu, Dec 18, 2014 at 09:45:05AM +, Daniel Mrzyglod wrote:
> In rte_eth_af_packet.c we are we are missing NULL pointer
> checks after calls to alocate memory for queues. Add checking NULL
> pointer and error handling.
> 
> Signed-off-by: Daniel Mrzyglod 
> ---
>  lib/librte_pmd_af_packet/rte_eth_af_packet.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/librte_pmd_af_packet/rte_eth_af_packet.c 
> b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
> index ad7242c..236749b 100644
> --- a/lib/librte_pmd_af_packet/rte_eth_af_packet.c
> +++ b/lib/librte_pmd_af_packet/rte_eth_af_packet.c
> @@ -603,6 +603,8 @@ rte_pmd_init_internals(const char *name,
>   rdsize = req->tp_frame_nr * sizeof(*(rx_queue->rd));
>  
>   rx_queue->rd = rte_zmalloc_socket(name, rdsize, 0, numa_node);
> + if (rx_queue->rd == NULL)
> + goto error;
>   for (i = 0; i < req->tp_frame_nr; ++i) {
>   rx_queue->rd[i].iov_base = rx_queue->map + (i * 
> framesize);
>   rx_queue->rd[i].iov_len = req->tp_frame_size;
> @@ -615,6 +617,8 @@ rte_pmd_init_internals(const char *name,
>   tx_queue->map = rx_queue->map + req->tp_block_size * 
> req->tp_block_nr;
>  
>   tx_queue->rd = rte_zmalloc_socket(name, rdsize, 0, numa_node);
> + if (tx_queue->rd == NULL)
> + goto error;
>   for (i = 0; i < req->tp_frame_nr; ++i) {
>   tx_queue->rd[i].iov_base = tx_queue->map + (i * 
> framesize);
>   tx_queue->rd[i].iov_len = req->tp_frame_size;
> -- 
> 2.1.0
> 
> 
Acked-by: Neil Horman 

[dpdk-dev] [PULL REQUEST] doc: modifications to user guides

[Bernard Iremonger]

These changes are DPDK 1.8 modifications and some corrections to the
Linux Getting Started Guide, FreeBSD Getting Started Guide,
Programmers Guide, the Sample Application User Guide, the Release Notes
the TestPMD Guide.

The following changes since commit 7d6378efb46820b2dcf6d1547ba19b67e9021098:

  version: 1.8.0-rc6 (2014-12-18 00:33:19 +0100)

are available in the git repository at:
  git://dpdk.org/next/dpdk-doc  master

Bernard Iremonger (1):
  doc: fix typos in prog_guide

Chao Zhu (1):
  doc: add IBM Power description to linux guides

Reshma Pattan (1):
  doc: fix setup menu options in linux gsg

Richardson, Bruce (2):
  doc: update mbuf section of prog_guide
  doc: updated svg files for rte_mbuf changes

Sergio Gonzalez Monroy (1):
  doc: add known issue for iommu and igb_uio

Siobhan Butler (18):
  doc: remove intel references from freebsd gsg
  doc: remove intel legal info from freebsd gsg
  doc: removed intel references from testpmd_ug
  doc: removed intel legal info from testpmd_ug
  doc: moved 1.7 new features to supported features for 1.8 in rel_notes
  doc: added new features to rel_notes
  doc: added to known issue 6.10 and removed fixed issue 6.29 from rel_notes
  doc: moved known issue 6.29 to resolved issues in rel_notes
  doc: remove appendix A from rel_notes
  doc: removed reference to Intel DPDK in rel_notes
  doc: updated resolved issues with old known issues
  doc: updating the list of sample apps in rel_notes
  doc:add udp info to prog_guide for vxlan
  doc: remove intel dpdk in sample app ug
  doc: remove intel legal info from sample app ug
  doc: add vxlan support to rel_notes
  doc: updating from 1.7 to 1.8 release note
  doc: add BSD License to dist sample app svg files

 doc/guides/freebsd_gsg/build_dpdk.rst  |   78 +++---
 doc/guides/freebsd_gsg/build_sample_apps.rst   |   40 ++--
 doc/guides/freebsd_gsg/index.rst   |   38 ---
 doc/guides/freebsd_gsg/install_from_ports.rst  |   28 +-
 doc/guides/freebsd_gsg/intro.rst   |   22 +-
 doc/guides/linux_gsg/build_dpdk.rst|4 +-
 doc/guides/linux_gsg/quick_start.rst   |   66 +++--
 doc/guides/linux_gsg/sys_reqs.rst  |   29 ++-
 .../prog_guide/i40e_ixgbe_igb_virt_func_drv.rst|   16 +-
 doc/guides/prog_guide/img/mbuf1.svg|   48 ++--
 doc/guides/prog_guide/img/mbuf2.svg|   65 ++--
 doc/guides/prog_guide/mbuf_lib.rst |   22 +-
 doc/guides/prog_guide/poll_mode_drv.rst|3 +-
 doc/guides/rel_notes/appendices.rst|  324 
 doc/guides/rel_notes/faq.rst   |   14 +-
 doc/guides/rel_notes/index.rst |   46 +---
 doc/guides/rel_notes/known_issues.rst  |  313 +++
 doc/guides/rel_notes/new_features.rst  |   27 ++-
 doc/guides/rel_notes/rel_description.rst   |   42 ++--
 doc/guides/rel_notes/resolved_issues.rst   |  271 ++---
 doc/guides/rel_notes/supported_features.rst|   37 ++-
 doc/guides/rel_notes/supported_os.rst  |2 +-
 doc/guides/rel_notes/updating_apps.rst |   25 ++-
 doc/guides/sample_app_ug/cmd_line.rst  |   10 +-
 doc/guides/sample_app_ug/exception_path.rst|8 +-
 doc/guides/sample_app_ug/hello_world.rst   |8 +-
 doc/guides/sample_app_ug/img/dist_app.svg  |   36 +++-
 doc/guides/sample_app_ug/img/dist_perf.svg |   37 +++-
 doc/guides/sample_app_ug/index.rst |   35 ---
 doc/guides/sample_app_ug/intel_quickassist.rst |   18 +-
 .../sample_app_ug/internet_proto_ip_pipeline.rst   |4 +-
 doc/guides/sample_app_ug/intro.rst |   12 +-
 doc/guides/sample_app_ug/ip_frag.rst   |6 +-
 doc/guides/sample_app_ug/ip_reassembly.rst |6 +-
 doc/guides/sample_app_ug/ipv4_multicast.rst|6 +-
 doc/guides/sample_app_ug/kernel_nic_interface.rst  |   34 +-
 .../sample_app_ug/l2_forward_real_virtual.rst  |   12 +-
 doc/guides/sample_app_ug/l3_forward.rst|8 +-
 .../sample_app_ug/l3_forward_access_ctrl.rst   |6 +-
 doc/guides/sample_app_ug/l3_forward_power_man.rst  |   16 +-
 doc/guides/sample_app_ug/l3_forward_virtual.rst|8 +-
 doc/guides/sample_app_ug/link_status_intr.rst  |   10 +-
 doc/guides/sample_app_ug/load_balancer.rst |   12 +-
 doc/guides/sample_app_ug/multi_process.rst |   34 +-
 doc/guides/sample_app_ug/netmap_compatibility.rst  |   30 +-
 doc/guides/sample_app_ug/qos_metering.rst  |4 +-
 doc/guides/sample_app_ug/qos_scheduler.rst |6 +-
 doc/guides/sample_app_ug/quota_watermark.rst   |   12 +-
 doc/guides/sample_app_ug/test_pipeline.rst |   10 +-
 doc/guides/sample_app_ug/timer.rst |6