[dpdk-dev] [PATCH 18/22] virtio: Fix descriptor index issue

[Ouyang, Changchun]

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Friday, January 16, 2015 12:54 AM
> To: Ouyang, Changchun
> Cc: dev at dpdk.org; Doherty, Declan; Cao, Waterman
> Subject: Re: [PATCH 18/22] virtio: Fix descriptor index issue
> 
> On Thu, 15 Jan 2015 13:15:26 +0800
> Ouyang Changchun  wrote:
> 
> > It should use vring descriptor index instead of used_ring index to index
> vq_descx.
> >
> > Signed-off-by: Changchun Ouyang 
> > ---
> >  lib/librte_pmd_virtio/virtio_rxtx.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c
> > b/lib/librte_pmd_virtio/virtio_rxtx.c
> > index 12c2310..2529dc4 100644
> > --- a/lib/librte_pmd_virtio/virtio_rxtx.c
> > +++ b/lib/librte_pmd_virtio/virtio_rxtx.c
> > @@ -144,9 +144,9 @@ virtio_xmit_cleanup(struct virtqueue *vq, uint16_t
> > num)
> >
> > used_idx = (uint16_t)(vq->vq_used_cons_idx & (vq-
> >vq_nentries - 1));
> > uep = &vq->vq_ring.used->ring[used_idx];
> > -   dxp = &vq->vq_descx[used_idx];
> >
> > desc_idx = (uint16_t) uep->id;
> > +   dxp = &vq->vq_descx[desc_idx];
> > vq->vq_used_cons_idx++;
> > vq_ring_free_chain(vq, desc_idx);
> >
> 
> Rather than patching a code added by earlier patch in series, why not just
> fix/merge the two patches?

I think it could be more clear what's the original patch looks like and what I 
need to fix.
And I also resolve the patch author issue, which I am not care for, but someone 
may care for. :-) 
Thanks
Changchun

[dpdk-dev] [PATCH 22/22] virtio: Use soft vlan strip in mergeable Rx path

[Ouyang, Changchun]

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Friday, January 16, 2015 12:56 AM
> To: Ouyang, Changchun
> Cc: dev at dpdk.org; Doherty, Declan; Cao, Waterman
> Subject: Re: [PATCH 22/22] virtio: Use soft vlan strip in mergeable Rx path
> 
> On Thu, 15 Jan 2015 13:15:30 +0800
> Ouyang Changchun  wrote:
> 
> > To keep the consistent logic with normal Rx path, the mergeable Rx
> > path also needs software vlan strip/decap if it is enabled.
> >
> > Signed-off-by: Changchun Ouyang 
> > ---
> >  lib/librte_pmd_virtio/virtio_rxtx.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/lib/librte_pmd_virtio/virtio_rxtx.c
> > b/lib/librte_pmd_virtio/virtio_rxtx.c
> > index 2529dc4..9090613 100644
> > --- a/lib/librte_pmd_virtio/virtio_rxtx.c
> > +++ b/lib/librte_pmd_virtio/virtio_rxtx.c
> > @@ -568,6 +568,7 @@ virtio_recv_mergeable_pkts(void *rx_queue,
> > uint16_t nb_pkts)
> >  {
> > struct virtqueue *rxvq = rx_queue;
> > +   struct virtio_hw *hw = rxvq->hw;
> > struct rte_mbuf *rxm, *new_mbuf;
> > uint16_t nb_used, num, nb_rx = 0;
> > uint32_t len[VIRTIO_MBUF_BURST_SZ];
> > @@ -674,6 +675,9 @@ virtio_recv_mergeable_pkts(void *rx_queue,
> > seg_res -= rcv_cnt;
> > }
> >
> > +   if (hw->vlan_strip)
> > +   rte_vlan_strip(rx_pkts[nb_rx]);
> > +
> > VIRTIO_DUMP_PACKET(rx_pkts[nb_rx],
> > rx_pkts[nb_rx]->data_len);
> >
> 
> If you resubmit, just combine this with earlier patch that does vlan strip

I think just keeping it as a separate a patch may be a good way.
Thanks
Changchun

[dpdk-dev] Q on Support for I217 and I218 Intel chipsets.

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ravi Kerur
> Sent: Monday, January 5, 2015 7:28 AM
> To: dev at dpdk.org; Neil Horman; Thomas Monjalon
> Subject: [dpdk-dev] Q on Support for I217 and I218 Intel chipsets.
> 
> Hi,
> 
> We have a Gigabyte H97N motherboard which has I217 Intel chipset which
> uses e100e drivers. I looked into lib/librte_pmd_e1000 directory and I do see
> that e1000e code is integrated but missing some support for read/write from
> flash_address and other minor things. I have made changes shown below and
> have done some testing with testpmd utility and now have following questions
> 
> 1. What amount of testing is required to qualify patch as successfully tested 
> on
> new chipsets
> 
> 2. FreeBSD testing, currently we have Ubuntu 14.04 installed on existing H97N
> motherboard and testing is done solely on Linux. We plan to get another
> motherboard which will have I218 chipset and still deciding whether to go with
> FreeBSD or Ubuntu. So the question I have is what amount of testing should be
> done on FreeBSD? I don't think setup.sh/dpdk_nic_bind.py works on FreeBSD
> yet hence the question on testing.
> 
> Thanks,
> Ravi
> 
> 
> 
> On Sun, Jan 4, 2015 at 3:15 PM, Ravi Kerur  wrote:
> 
> > This patch adds support for I217 and I218 Intel chipsets.
> > Gigabyte H97N motherboard has I217 Intel chipsets and changes include
> >
> > 1. Add relevant device-ids via RTE_PCI_DEV_ID_DECL_EM 2. Add support
> > for memory mapped flash address read/write
> >
> > Basic testing on Ubuntu with testpmd utility.
> >
> > Signed-off-by: Ravi Kerur 
> > ---
> >  lib/librte_eal/common/include/rte_pci_dev_ids.h |  4 
> >  lib/librte_pmd_e1000/e1000/e1000_api.c  | 21
> +
> >  lib/librte_pmd_e1000/e1000/e1000_api.h  |  1 +
> >  lib/librte_pmd_e1000/e1000/e1000_osdep.h| 24
> > +++-
> >  lib/librte_pmd_e1000/em_ethdev.c|  7 +++
> >  5 files changed, 52 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > index c922de9..712793a 100644
> > --- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > +++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
> > @@ -274,6 +274,10 @@
> RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > E1000_DEV_ID_82572EI)
> >  RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> E1000_DEV_ID_82573L)
> > RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> E1000_DEV_ID_82574L)
> > RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> E1000_DEV_ID_82574LA)
> > +RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > +E1000_DEV_ID_PCH_LPT_I217_LM)
> > +RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > +E1000_DEV_ID_PCH_LPT_I217_V)
> > +RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > E1000_DEV_ID_PCH_LPTLP_I218_LM)
> > +RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
> > +E1000_DEV_ID_PCH_LPTLP_I218_V)
So, you are enabling new Intel(r) NICs. That's great, and thanks!

> >
> >  / Physical IGB devices from e1000_hw.h
> > /
> >
> > diff --git a/lib/librte_pmd_e1000/e1000/e1000_api.c
> > b/lib/librte_pmd_e1000/e1000/e1000_api.c
> > index a064565..30ed1f3 100644
> > --- a/lib/librte_pmd_e1000/e1000/e1000_api.c
> > +++ b/lib/librte_pmd_e1000/e1000/e1000_api.c
> > @@ -1355,3 +1355,24 @@ void e1000_shutdown_fiber_serdes_link(struct
> > e1000_hw *hw)
> > hw->mac.ops.shutdown_serdes(hw);  }
> >
> > +/**
> > + *  e1000_device_is_ich8 - Check for ICH8 device
> > + *  @hw: pointer to the HW structure
> > + *
> > + *  return TRUE for ICH8, otherwise FALSE  **/ bool
> > +e1000_device_is_ich8(struct e1000_hw *hw) {
> > +   DEBUGFUNC("e1000_device_is_ich8");
> > +
> > +   switch (hw->device_id) {
> > +   case E1000_DEV_ID_PCH_LPT_I217_LM:
> > +   case E1000_DEV_ID_PCH_LPT_I217_V:
> > +   case E1000_DEV_ID_PCH_LPTLP_I218_LM:
> > +   case E1000_DEV_ID_PCH_LPTLP_I218_V:
> > +   return 1;
> > +
> > +   default:
> > +   return 0;
> > +   }
> > +}
As Konstantin indicated, please do not try to modify any code in any source 
files in e1000
sub-folder, except e1000_osdep.c and e1000_osdep.h. If this piece of code is 
needed, please
try to move it to em_ethdev.c or e1000_osdep.c files!

> > diff --git a/lib/librte_pmd_e1000/e1000/e1000_api.h
> > b/lib/librte_pmd_e1000/e1000/e1000_api.h
> > index 02b16da..f96a674 100644
> > --- a/lib/librte_pmd_e1000/e1000/e1000_api.h
> > +++ b/lib/librte_pmd_e1000/e1000/e1000_api.h
> > @@ -49,6 +49,7 @@ extern void e1000_init_function_pointers_vf(struct
> > e1000_hw *hw);
> >  extern void e1000_power_up_fiber_serdes_link(struct e1000_hw *hw);
> > extern void e1000_shutdown_fiber_serdes_link(struct e1000_hw *hw);
> > extern void e1000_init_function_pointers_i210(struct e1000_hw *hw);
> > +extern bool e1000_device_is_ich8(struct e1000_hw *hw);
> >
> >  s32 e1000_set_obff_timer

[dpdk-dev] [PATCH 0/2] support TSO on i40e

[Jijiang Liu]

This patch set enables i40e TSO feature for both non-tunneling packet and UDP 
tunneling packet.

Jijiang Liu (2):
  support i40e TSO
  csum fwd engine testpmd change

 app/test-pmd/csumonly.c   |7 +-
 lib/librte_pmd_i40e/i40e_ethdev.c |3 +-
 lib/librte_pmd_i40e/i40e_rxtx.c   |  111 +++-
 lib/librte_pmd_i40e/i40e_rxtx.h   |   13 
 4 files changed, 102 insertions(+), 32 deletions(-)

-- 
1.7.7.6

[dpdk-dev] [PATCH 1/2] i40e:support i40e TSO

[Jijiang Liu]

This patch enables i40e TSO feature for both non-tunneling packet and UDP 
tunneling packet.

Signed-off-by: Jijiang Liu 
Signed-off-by: Miroslaw Walukiewicz 
---
 lib/librte_pmd_i40e/i40e_ethdev.c |3 +-
 lib/librte_pmd_i40e/i40e_rxtx.c   |  111 +++-
 lib/librte_pmd_i40e/i40e_rxtx.h   |   13 
 3 files changed, 98 insertions(+), 29 deletions(-)

diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c 
b/lib/librte_pmd_i40e/i40e_ethdev.c
index b47a3d2..af95296 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -1516,7 +1516,8 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct 
rte_eth_dev_info *dev_info)
DEV_TX_OFFLOAD_IPV4_CKSUM |
DEV_TX_OFFLOAD_UDP_CKSUM |
DEV_TX_OFFLOAD_TCP_CKSUM |
-   DEV_TX_OFFLOAD_SCTP_CKSUM;
+   DEV_TX_OFFLOAD_SCTP_CKSUM |
+   DEV_TX_OFFLOAD_TCP_TSO;
dev_info->reta_size = pf->hash_lut_size;

dev_info->default_rxconf = (struct rte_eth_rxconf) {
diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c b/lib/librte_pmd_i40e/i40e_rxtx.c
index 2beae3c..529ffb2 100644
--- a/lib/librte_pmd_i40e/i40e_rxtx.c
+++ b/lib/librte_pmd_i40e/i40e_rxtx.c
@@ -460,18 +460,15 @@ static inline void
 i40e_txd_enable_checksum(uint64_t ol_flags,
uint32_t *td_cmd,
uint32_t *td_offset,
-   uint8_t l2_len,
-   uint16_t l3_len,
-   uint8_t outer_l2_len,
-   uint16_t outer_l3_len,
+   union i40e_tx_offload tx_offload,
uint32_t *cd_tunneling)
 {
-   if (!l2_len) {
+   if (!tx_offload.l2_len) {
PMD_DRV_LOG(DEBUG, "L2 length set to 0");
return;
}

-   if (!l3_len) {
+   if (!tx_offload.l3_len) {
PMD_DRV_LOG(DEBUG, "L3 length set to 0");
return;
}
@@ -479,7 +476,7 @@ i40e_txd_enable_checksum(uint64_t ol_flags,
/* UDP tunneling packet TX checksum offload */
if (unlikely(ol_flags & PKT_TX_UDP_TUNNEL_PKT)) {

-   *td_offset |= (outer_l2_len >> 1)
+   *td_offset |= (tx_offload.outer_l2_len >> 1)
<< I40E_TX_DESC_LENGTH_MACLEN_SHIFT;

if (ol_flags & PKT_TX_OUTER_IP_CKSUM)
@@ -490,26 +487,36 @@ i40e_txd_enable_checksum(uint64_t ol_flags,
*cd_tunneling |= I40E_TX_CTX_EXT_IP_IPV6;

/* Now set the ctx descriptor fields */
-   *cd_tunneling |= (outer_l3_len >> 2) <<
+   *cd_tunneling |= (tx_offload.outer_l3_len >> 2) <<
I40E_TXD_CTX_QW0_EXT_IPLEN_SHIFT |
I40E_TXD_CTX_UDP_TUNNELING |
-   (l2_len >> 1) <<
+   (tx_offload.l2_len >> 1) <<
I40E_TXD_CTX_QW0_NATLEN_SHIFT;

} else
-   *td_offset |= (l2_len >> 1)
+   *td_offset |= (tx_offload.l2_len >> 1)
<< I40E_TX_DESC_LENGTH_MACLEN_SHIFT;

/* Enable L3 checksum offloads */
if (ol_flags & PKT_TX_IPV4_CSUM) {
*td_cmd |= I40E_TX_DESC_CMD_IIPT_IPV4_CSUM;
-   *td_offset |= (l3_len >> 2) << I40E_TX_DESC_LENGTH_IPLEN_SHIFT;
+   *td_offset |= (tx_offload.l3_len >> 2)
+   << I40E_TX_DESC_LENGTH_IPLEN_SHIFT;
} else if (ol_flags & PKT_TX_IPV4) {
*td_cmd |= I40E_TX_DESC_CMD_IIPT_IPV4;
-   *td_offset |= (l3_len >> 2) << I40E_TX_DESC_LENGTH_IPLEN_SHIFT;
+   *td_offset |= (tx_offload.l3_len >> 2)
+   << I40E_TX_DESC_LENGTH_IPLEN_SHIFT;
} else if (ol_flags & PKT_TX_IPV6) {
*td_cmd |= I40E_TX_DESC_CMD_IIPT_IPV6;
-   *td_offset |= (l3_len >> 2) << I40E_TX_DESC_LENGTH_IPLEN_SHIFT;
+   *td_offset |= (tx_offload.l3_len >> 2)
+   << I40E_TX_DESC_LENGTH_IPLEN_SHIFT;
+   }
+
+   if (ol_flags & PKT_TX_TCP_SEG) {
+   *td_cmd |= I40E_TX_DESC_CMD_L4T_EOFT_TCP;
+   *td_offset |= (tx_offload.l4_len >> 2)
+   << I40E_TX_DESC_LENGTH_L4_FC_LEN_SHIFT;
+   return;
}

/* Enable L4 checksum offloads */
@@ -1160,8 +1167,11 @@ i40e_calc_context_desc(uint64_t flags)
 {
uint64_t mask = 0ULL;

-   if (flags | PKT_TX_UDP_TUNNEL_PKT)
+   if (flags & PKT_TX_UDP_TUNNEL_PKT)
mask |= PKT_TX_UDP_TUNNEL_PKT;
+   if (flags & PKT_TX_TCP_SEG)
+   /* need for context descriptor when TSO enabled */
+   mask |= PKT_TX_TCP_SEG;

 #ifdef RTE_LIBRTE_IEEE1588
mask |= PKT_TX_IEEE1588_TMST;
@@ -1172,6 +1182,47 @@ i40e_calc_context_desc(uint64_t flags)
return 0;
 }

+/* set i40e TS

[dpdk-dev] [PATCH 2/2] app/testpmd:csum fwd engine change

[Jijiang Liu]

change the palce of setting UDP tunneling packet offload flag.

Signed-off-by: Jijiang Liu 
---
 app/test-pmd/csumonly.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 41711fd..57afdfc 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -256,9 +256,6 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t 
outer_ethertype,
struct udp_hdr *udp_hdr;
uint64_t ol_flags = 0;

-   if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
-   ol_flags |= PKT_TX_UDP_TUNNEL_PKT;
-
if (outer_ethertype == _htons(ETHER_TYPE_IPv4)) {
ipv4_hdr->hdr_checksum = 0;

@@ -392,6 +389,10 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
tunnel = 1;

if (tunnel == 1) {
+   if (testpmd_ol_flags &
+   TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
+   ol_flags |= PKT_TX_UDP_TUNNEL_PKT;
+
outer_ethertype = ethertype;
outer_l2_len = l2_len;
outer_l3_len = l3_len;
-- 
1.7.7.6

[dpdk-dev] how does it count the number of contiguous physical pages in map_all_hugepages

[Jack,Xie Jie]

Hi,

I am learning DPDK recently, when I check l2fwd example, I am a little 
confused, please someone give me a clue.

In function map_all_hugepages called in rte_eal_hugepage_init,
There are lines of source code like below to count the number of contiguous 
physical pages,
But I check the source code, I just cannot find where is hugepg_tbl[j].physaddr 
be set before,
how can here check the value of hugepg_tbl[j].physaddr.

/* reserve a virtual area for next contiguous
* physical block: count the number of
* contiguous physical pages. */
for (j = i+1; j < hpi->num_pages[0] ; j++) {
 if (hugepg_tbl[j].physaddr !=
 hugepg_tbl[j-1].physaddr + hugepage_sz)
   break;
}


Thanks !
Jack

[dpdk-dev] [PATCH v2] i40e: workaround for XL710 performance

[Zhang, Helin]

> Subject: [PATCH v2] i40e: workaround for XL710 performance
> 
> On XL710, performance number is far from the expectation on recent firmware
> versions, if promiscuous mode is disabled, or promiscuous mode is enabled and
> port MAC address is equal to the packet destination MAC address. The fix for
> this issue may not be integrated in the following firmware version. So the
> workaround in software driver is needed. For XL710, it needs to modify the
> initial values of 3 internal only registers, which are the same as X710.
> Note that the values for X710 and XL710 registers could be different, and the
> workaround can be removed when it is fixed in firmware in the future.
> 
> Signed-off-by: Helin Zhang 
Acked-by: Jingjing Wu 

> ---
>  lib/librte_pmd_i40e/i40e_ethdev.c | 44
> ++-
>  1 file changed, 30 insertions(+), 14 deletions(-)
> 
> v2 changes:
> * Supported modifying the address of 0x269FBC of XL710 during
>   initialization, to fix the minor performance gap to expectation.
>   That means XL710 can meet the performance expectation with this
>   workaround.

Applied. Thanks to Neil's for his reviewing efforts on v1 version!

Thanks,
Helin

[dpdk-dev] Why nothing since 1.8.0?

[Thomas Monjalon]

2015-01-15 17:46, Matthew Hall:
> On Thu, Jan 15, 2015 at 09:55:00PM +, O'driscoll, Tim wrote:
> > As you said, there's a balance to be struck, and too many subtrees may 
> > become unmanageable. With respect to your concern about developers having 
> > to 
> > potentially develop patches against multiple subtrees, this has never been 
> > raised as a concern by any of our development team. Is there any historical 
> > data on the number of changes that would fall into this category so we can 
> > see if it's a real problem or not?
> 
> Hi Tim,
> 
> What happens when a core API like rte_mbuf gets some changes, and you have to 
> update the PMD's to fit?
> 
> Do I have to make 10-20 odd random patches to separate PMD maintainers 
> instead 
> of one set of patches to the PMD subtree?

Then the patchset is core-wide and must be managed in the main tree.

> To me it doesn't sound very nice for the guys maintaining the core. Given 
> most 
> of the changes seem to be mbuf or eal this seems like a scaling issue to me.

In previous release, there were a lot of changes related to i40e.
And we expect to have the same level of activity for fm10k.

> But maybe I misunderstood the process.

No problem, we are starting experiencing this model and will write some
guidelines.

-- 
Thomas

[dpdk-dev] Callbacks after buffer (mbuf) sent out

[Vithal S Mohare]

To elaborate more...
Assuming an example of vmxnet3 driver, at present, when rte_eth_tx_burst() is 
called to send mbufs, vmxnet3 driver calls vmxnet3_tq_tx_complete() to free up  
completed buffers.  Instead, wondering, if vmxnet3 (or corresponding driver) 
can trigger application callback for the buffer (mbuf) which gets transmitted 
out of n/w interface.  Application callback can decide now decide whether to 
reuse the mbuf and continue multicasting on other tunnels.  

Thanks,
-Vithal

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Vithal S Mohare
Sent: Tuesday, January 13, 2015 9:21 AM
To: dev at dpdk.org
Subject: [dpdk-dev] Callbacks after buffer (mbuf) sent out

Hi,

I am looking for application callbacks after mbufs are sent (tx) out 
successfully.   One of the use cases is for async multicast (over different gre 
tunnels etc).   Using direct/indirect buffers along with ref-count itself is 
not enough, as actual 'pkt-data' itself changes while flooding on list of 
tunnels.

Thanks,
-Vithal

[dpdk-dev] [PATCH] ethdev: fix missing parenthesis

[Wodkowski, PawelX]

> Good catch!
> Was introduced in commit 4bdefaade6d1 (VMDQ enhancements).
> Note that quite often, when a patch contains too much things,
> we miss this kind of bugs. That's a reason to well split patches.
> 

What is most surprising I did not spotted this, neither  the compiler
what I think it should. It was my IDE which pointed possible bug.

Are we using '-Wparentheses' switch? If not, we should consider
to use this switch?

Pawel

[dpdk-dev] Q on Support for I217 and I218 Intel chipsets.

[Bruce Richardson]

On Thu, Jan 15, 2015 at 11:54:52PM +, Ananyev, Konstantin wrote:
> Hi,
> 
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ravi Kerur
> > Sent: Thursday, January 15, 2015 8:34 PM
> > To: Thomas Monjalon
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] Q on Support for I217 and I218 Intel chipsets.
> > 
> > On Wed, Jan 14, 2015 at 8:27 AM, Thomas Monjalon  > 6wind.com>
> > wrote:
> > 
> > > 2015-01-09 04:41, Ravi Kerur:
> > > > Thomas,
> > > >
> > > > Please let me know how I can move forward on this. If i confine changes
> > > in
> > > > e1000/ directory to e1000_osdep.h file only and the rest in PMD will 
> > > > that
> > > > work? The reason I ask is because of following comment  in README file.
> > > >
> > > > ...
> > > > Few changes to the original FreeBSD sources were made to:
> > > > - Adopt it for PMD usage mode:
> > > > e1000_osdep.c
> > > > e1000_osdep.h
> > > > ...
> 
> Yes, if needed you can modify these files.
> In fact, these files are the only 2 that are allowed to be modified inside 
> e1000 sub-directory.
> As I understand you plan to implement E1000_READ_FLASH_REG  and 
> E1000_WRITE_FLASH_REG
> macros properly, correct?
> Konstantin
> 

As a cleanup we should really look to move these two files out of the e1000
subdirectory (and similarly for the ixgbe versions etc.), so as to give a 
cleaner
and more manageable separation between what can be edited or not.

/Bruce

[dpdk-dev] Does I210 NIC support Flow director filters?

[Bruce Richardson]

On Thu, Jan 15, 2015 at 08:06:52PM -0500, Kamraan Nasim wrote:
> >>> update the RSS RETA table so that traffic doesn't get sent
> >> to that queue via RSS. Is that what you are asking?
> 
> Thanks Bruce, that's exactly it.  Basically each filter will forward
> traffic to a unique RSS queue which can allow me to calculate filter match
> statistics for that queue(or filter). At that point I would like to drop
> the filtered packet. Is there any way to drop the filtered packet in the
> RSS queue without doing a rte_eth_rx_burst() and dropping it then?
> 
> --Kam
>
I don't believe there is any other way to drop them from the queue other than
RX and drop. It's not the most efficient way to do so (since you have to 
allocate,
fill and free an mbuf), but it's the only way that an app can do so without
adding new functions to the driver(s).

/Bruce

[dpdk-dev] how does it count the number of contiguous physical pages in map_all_hugepages

[Bruce Richardson]

On Fri, Jan 16, 2015 at 05:32:08AM +, Jack,Xie Jie wrote:
> Hi,
> 
> I am learning DPDK recently, when I check l2fwd example, I am a little 
> confused, please someone give me a clue.
> 
> In function map_all_hugepages called in rte_eal_hugepage_init,
> There are lines of source code like below to count the number of contiguous 
> physical pages,
> But I check the source code, I just cannot find where is 
> hugepg_tbl[j].physaddr be set before,
> how can here check the value of hugepg_tbl[j].physaddr.
> 
> /* reserve a virtual area for next contiguous
> * physical block: count the number of
> * contiguous physical pages. */
> for (j = i+1; j < hpi->num_pages[0] ; j++) {
>  if (hugepg_tbl[j].physaddr !=
>  hugepg_tbl[j-1].physaddr + 
> hugepage_sz)
>break;
> }
> 
> 
> Thanks !
> Jack

See function "find_physaddrs" in "eal_memory.c".

Regards,
/Bruce

[dpdk-dev] Q on Support for I217 and I218 Intel chipsets.

[Ananyev, Konstantin]

> -Original Message-
> From: Richardson, Bruce
> Sent: Friday, January 16, 2015 10:53 AM
> To: Ananyev, Konstantin
> Cc: Ravi Kerur; Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] Q on Support for I217 and I218 Intel chipsets.
> 
> On Thu, Jan 15, 2015 at 11:54:52PM +, Ananyev, Konstantin wrote:
> > Hi,
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ravi Kerur
> > > Sent: Thursday, January 15, 2015 8:34 PM
> > > To: Thomas Monjalon
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] Q on Support for I217 and I218 Intel chipsets.
> > >
> > > On Wed, Jan 14, 2015 at 8:27 AM, Thomas Monjalon  > > 6wind.com>
> > > wrote:
> > >
> > > > 2015-01-09 04:41, Ravi Kerur:
> > > > > Thomas,
> > > > >
> > > > > Please let me know how I can move forward on this. If i confine 
> > > > > changes
> > > > in
> > > > > e1000/ directory to e1000_osdep.h file only and the rest in PMD will 
> > > > > that
> > > > > work? The reason I ask is because of following comment  in README 
> > > > > file.
> > > > >
> > > > > ...
> > > > > Few changes to the original FreeBSD sources were made to:
> > > > > - Adopt it for PMD usage mode:
> > > > > e1000_osdep.c
> > > > > e1000_osdep.h
> > > > > ...
> >
> > Yes, if needed you can modify these files.
> > In fact, these files are the only 2 that are allowed to be modified inside 
> > e1000 sub-directory.
> > As I understand you plan to implement E1000_READ_FLASH_REG  and 
> > E1000_WRITE_FLASH_REG
> > macros properly, correct?
> > Konstantin
> >
> 
> As a cleanup we should really look to move these two files out of the e1000
> subdirectory (and similarly for the ixgbe versions etc.), so as to give a 
> cleaner
> and more manageable separation between what can be edited or not.

It was always like that for all Intel PMDs we have:

$ find lib/ -name '*_osdep.*' | grep -v acl
lib/librte_pmd_vmxnet3/vmxnet3/vmxnet3_osdep.h
lib/librte_pmd_ixgbe/ixgbe/ixgbe_osdep.h
lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_osdep.h
lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_osdep.h
lib/librte_pmd_i40e/i40e/i40e_osdep.h
lib/librte_pmd_e1000/e1000/e1000_osdep.c
lib/librte_pmd_e1000/e1000/e1000_osdep.h

As I understand ND has it's own version of _osdep.* for each OS they 
support.
We obviously modify it to fit DPDK purposes.

Konstantin

> 
> /Bruce

[dpdk-dev] Q on Support for I217 and I218 Intel chipsets.

[Bruce Richardson]

On Fri, Jan 16, 2015 at 11:08:46AM +, Ananyev, Konstantin wrote:
> 
> 
> > -Original Message-
> > From: Richardson, Bruce
> > Sent: Friday, January 16, 2015 10:53 AM
> > To: Ananyev, Konstantin
> > Cc: Ravi Kerur; Thomas Monjalon; dev at dpdk.org
> > Subject: Re: [dpdk-dev] Q on Support for I217 and I218 Intel chipsets.
> > 
> > On Thu, Jan 15, 2015 at 11:54:52PM +, Ananyev, Konstantin wrote:
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ravi Kerur
> > > > Sent: Thursday, January 15, 2015 8:34 PM
> > > > To: Thomas Monjalon
> > > > Cc: dev at dpdk.org
> > > > Subject: Re: [dpdk-dev] Q on Support for I217 and I218 Intel chipsets.
> > > >
> > > > On Wed, Jan 14, 2015 at 8:27 AM, Thomas Monjalon  > > > 6wind.com>
> > > > wrote:
> > > >
> > > > > 2015-01-09 04:41, Ravi Kerur:
> > > > > > Thomas,
> > > > > >
> > > > > > Please let me know how I can move forward on this. If i confine 
> > > > > > changes
> > > > > in
> > > > > > e1000/ directory to e1000_osdep.h file only and the rest in PMD 
> > > > > > will that
> > > > > > work? The reason I ask is because of following comment  in README 
> > > > > > file.
> > > > > >
> > > > > > ...
> > > > > > Few changes to the original FreeBSD sources were made to:
> > > > > > - Adopt it for PMD usage mode:
> > > > > > e1000_osdep.c
> > > > > > e1000_osdep.h
> > > > > > ...
> > >
> > > Yes, if needed you can modify these files.
> > > In fact, these files are the only 2 that are allowed to be modified 
> > > inside e1000 sub-directory.
> > > As I understand you plan to implement E1000_READ_FLASH_REG  and 
> > > E1000_WRITE_FLASH_REG
> > > macros properly, correct?
> > > Konstantin
> > >
> > 
> > As a cleanup we should really look to move these two files out of the e1000
> > subdirectory (and similarly for the ixgbe versions etc.), so as to give a 
> > cleaner
> > and more manageable separation between what can be edited or not.
> 
> It was always like that for all Intel PMDs we have:
> 
> $ find lib/ -name '*_osdep.*' | grep -v acl
> lib/librte_pmd_vmxnet3/vmxnet3/vmxnet3_osdep.h
> lib/librte_pmd_ixgbe/ixgbe/ixgbe_osdep.h
> lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_osdep.h
> lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_osdep.h
> lib/librte_pmd_i40e/i40e/i40e_osdep.h
> lib/librte_pmd_e1000/e1000/e1000_osdep.c
> lib/librte_pmd_e1000/e1000/e1000_osdep.h
> 
> As I understand ND has it's own version of _osdep.* for each OS they 
> support.
> We obviously modify it to fit DPDK purposes.
> 
> Konstantin
> 
> > 
> > /Bruce

Yep. Doesn't mean we haven't put it in the wrong place though! :-)

/Bruce

[dpdk-dev] Q on Support for I217 and I218 Intel chipsets.

[Ananyev, Konstantin]

> -Original Message-
> From: Richardson, Bruce
> Sent: Friday, January 16, 2015 11:32 AM
> To: Ananyev, Konstantin
> Cc: Ravi Kerur; Thomas Monjalon; dev at dpdk.org
> Subject: Re: [dpdk-dev] Q on Support for I217 and I218 Intel chipsets.
> 
> On Fri, Jan 16, 2015 at 11:08:46AM +, Ananyev, Konstantin wrote:
> >
> >
> > > -Original Message-
> > > From: Richardson, Bruce
> > > Sent: Friday, January 16, 2015 10:53 AM
> > > To: Ananyev, Konstantin
> > > Cc: Ravi Kerur; Thomas Monjalon; dev at dpdk.org
> > > Subject: Re: [dpdk-dev] Q on Support for I217 and I218 Intel chipsets.
> > >
> > > On Thu, Jan 15, 2015 at 11:54:52PM +, Ananyev, Konstantin wrote:
> > > > Hi,
> > > >
> > > > > -Original Message-
> > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ravi Kerur
> > > > > Sent: Thursday, January 15, 2015 8:34 PM
> > > > > To: Thomas Monjalon
> > > > > Cc: dev at dpdk.org
> > > > > Subject: Re: [dpdk-dev] Q on Support for I217 and I218 Intel chipsets.
> > > > >
> > > > > On Wed, Jan 14, 2015 at 8:27 AM, Thomas Monjalon  > > > > 6wind.com>
> > > > > wrote:
> > > > >
> > > > > > 2015-01-09 04:41, Ravi Kerur:
> > > > > > > Thomas,
> > > > > > >
> > > > > > > Please let me know how I can move forward on this. If i confine 
> > > > > > > changes
> > > > > > in
> > > > > > > e1000/ directory to e1000_osdep.h file only and the rest in PMD 
> > > > > > > will that
> > > > > > > work? The reason I ask is because of following comment  in README 
> > > > > > > file.
> > > > > > >
> > > > > > > ...
> > > > > > > Few changes to the original FreeBSD sources were made to:
> > > > > > > - Adopt it for PMD usage mode:
> > > > > > > e1000_osdep.c
> > > > > > > e1000_osdep.h
> > > > > > > ...
> > > >
> > > > Yes, if needed you can modify these files.
> > > > In fact, these files are the only 2 that are allowed to be modified 
> > > > inside e1000 sub-directory.
> > > > As I understand you plan to implement E1000_READ_FLASH_REG  and 
> > > > E1000_WRITE_FLASH_REG
> > > > macros properly, correct?
> > > > Konstantin
> > > >
> > >
> > > As a cleanup we should really look to move these two files out of the 
> > > e1000
> > > subdirectory (and similarly for the ixgbe versions etc.), so as to give a 
> > > cleaner
> > > and more manageable separation between what can be edited or not.
> >
> > It was always like that for all Intel PMDs we have:
> >
> > $ find lib/ -name '*_osdep.*' | grep -v acl
> > lib/librte_pmd_vmxnet3/vmxnet3/vmxnet3_osdep.h
> > lib/librte_pmd_ixgbe/ixgbe/ixgbe_osdep.h
> > lib/librte_eal/linuxapp/kni/ethtool/ixgbe/ixgbe_osdep.h
> > lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_osdep.h
> > lib/librte_pmd_i40e/i40e/i40e_osdep.h
> > lib/librte_pmd_e1000/e1000/e1000_osdep.c
> > lib/librte_pmd_e1000/e1000/e1000_osdep.h
> >
> > As I understand ND has it's own version of _osdep.* for each OS 
> > they support.
> > We obviously modify it to fit DPDK purposes.
> >
> > Konstantin
> >
> > >
> > > /Bruce
> 
> Yep. Doesn't mean we haven't put it in the wrong place though! :-)

We just don't move it at all :)
It is at the same place where ND puts it, we just modify the contents.
>From my point - current location is perfectly ok.
Konstantin

> 
> /Bruce

[dpdk-dev] [PATCH] bsdapp: replace d_thread_t with struct thread in nic_uio

[Bruce Richardson]

Reported by: John Baldwin 
Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196691

Quote:
"The d_thread_t typedef is a compat shim to support FreeBSD 4.x.  I'm planning 
to remove this shim from 11 and dpdk is very unlikely to ever be ported to 4.x.
 If it does it will need far more changes than just d_thread_t"

Signed-off-by: Bruce Richardson 
---
 lib/librte_eal/bsdapp/nic_uio/nic_uio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/bsdapp/nic_uio/nic_uio.c 
b/lib/librte_eal/bsdapp/nic_uio/nic_uio.c
index ed11d84..5ae8560 100644
--- a/lib/librte_eal/bsdapp/nic_uio/nic_uio.c
+++ b/lib/librte_eal/bsdapp/nic_uio/nic_uio.c
@@ -175,13 +175,13 @@ nic_uio_mmap_single(struct cdev *cdev, vm_ooffset_t 
*offset, vm_size_t size,


 int
-nic_uio_open(struct cdev *dev, int oflags, int devtype, d_thread_t *td)
+nic_uio_open(struct cdev *dev, int oflags, int devtype, struct thread *td)
 {
return 0;
 }

 int
-nic_uio_close(struct cdev *dev, int fflag, int devtype, d_thread_t *td)
+nic_uio_close(struct cdev *dev, int fflag, int devtype, struct thread *td)
 {
return 0;
 }
-- 
2.1.0

[dpdk-dev] [PATCH v3 4/4] docs: Add ABI documentation

[Thomas Monjalon]

2015-01-14 15:07, Neil Horman:
> On Wed, Jan 14, 2015 at 04:59:51PM +0100, Thomas Monjalon wrote:
> > 2014-12-23 10:51, Neil Horman:
> > > Adding a document describing rudimentary ABI policy and adding notice 
> > > space for
> > > any deprecation announcements
> > 
> > We had a good discussion about the policy and its impact:
> > http://thread.gmane.org/gmane.comp.networking.dpdk.devel/8367/focus=8461
> > Sadly nobody else discussed it.
> > I think we should integrate some of the conclusions in this documentation.
> > 
> I'm certainly open to that.  However, I felt like that conversation centered
> more around the debate for the need for ABI versioning, not the mechanics
> thereof.  Are there specific sections of that conversation that you are 
> looking
> to incorporate, or specific topics?

Yes.
In the point number 2, you suggest to skip ABI compatibility (after a
deprecation schedule) for big changes.
In the point 3, you suggest to add new fields at the end of the structure,
even if it's asthetic, with exceptions if performance impact.

Thank you
-- 
Thomas

[dpdk-dev] [DISCUSSION] : ERROR while compiling dpdk-1.7 on ubuntu14.04

[Srinivasreddy R]

hi,
Getting error while compiling dpdk on ubuntu10.04.


export RTE_SDK=$(pwd)
export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"

make CONFIG_RTE_BUILD_COMBINE_LIBS=y CONFIG_RTE_BUILD_SHARED_LIB=y install
T="$RTE_TARGET"


== Build app/test-acl
  CC main.o
  LD testacl
/home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
undefined reference to `log2'
/home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
undefined reference to `ceil'
/home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
undefined reference to `pow'
/home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
undefined reference to `round'
collect2: error: ld returned 1 exit status
make[5]: *** [testacl] Error 1
make[4]: *** [test-acl] Error 2
make[3]: *** [app] Error 2
make[2]: *** [all] Error 2
make[1]: *** [x86_64-ivshmem-linuxapp-gcc_install] Error 2
make: *** [install] Error 2

Following installation procedure at link :
https://github.com/01org/dpdk-ovs/blob/development/docs/01_Installation.md#dpdk


thanks
srinivas.

[dpdk-dev] [DISCUSSION] : ERROR while compiling dpdk-1.7 on ubuntu14.04

[Srinivasreddy R]

sorry typo i am using Ubuntu 14.04.1 LTS .

On Fri, Jan 16, 2015 at 7:06 PM, Srinivasreddy R <
srinivasreddy4390 at gmail.com> wrote:

> hi,
> Getting error while compiling dpdk on ubuntu10.04.
>
>
> export RTE_SDK=$(pwd)
> export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
>
> make CONFIG_RTE_BUILD_COMBINE_LIBS=y CONFIG_RTE_BUILD_SHARED_LIB=y install
> T="$RTE_TARGET"
>
>
> == Build app/test-acl
>   CC main.o
>   LD testacl
> /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
> undefined reference to `log2'
> /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
> undefined reference to `ceil'
> /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
> undefined reference to `pow'
> /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
> undefined reference to `round'
> collect2: error: ld returned 1 exit status
> make[5]: *** [testacl] Error 1
> make[4]: *** [test-acl] Error 2
> make[3]: *** [app] Error 2
> make[2]: *** [all] Error 2
> make[1]: *** [x86_64-ivshmem-linuxapp-gcc_install] Error 2
> make: *** [install] Error 2
>
> Following installation procedure at link :
>
> https://github.com/01org/dpdk-ovs/blob/development/docs/01_Installation.md#dpdk
>
> 
> thanks
> srinivas.
>

[dpdk-dev] [DISCUSSION] : ERROR while compiling dpdk-1.7 on ubuntu14.04

[De Lara Guarch, Pablo]

Hi Srinivas,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Srinivasreddy R
> Sent: Friday, January 16, 2015 1:44 PM
> To: dev at dpdk.org; dpdk-ovs at lists.01.org
> Subject: [dpdk-dev] [DISCUSSION] : ERROR while compiling dpdk-1.7 on
> ubuntu14.04
> 
> sorry typo i am using Ubuntu 14.04.1 LTS .
> 
> On Fri, Jan 16, 2015 at 7:06 PM, Srinivasreddy R <
> srinivasreddy4390 at gmail.com> wrote:
> 
> > hi,
> > Getting error while compiling dpdk on ubuntu10.04.
> >
> >
> > export RTE_SDK=$(pwd)
> > export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
> >
> > make CONFIG_RTE_BUILD_COMBINE_LIBS=y
> CONFIG_RTE_BUILD_SHARED_LIB=y install
> > T="$RTE_TARGET"
> >
> >
> > == Build app/test-acl
> >   CC main.o
> >   LD testacl
> > /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-
> gcc/lib/libintel_dpdk.so:
> > undefined reference to `log2'
> > /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-
> gcc/lib/libintel_dpdk.so:
> > undefined reference to `ceil'
> > /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-
> gcc/lib/libintel_dpdk.so:
> > undefined reference to `pow'
> > /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-
> gcc/lib/libintel_dpdk.so:
> > undefined reference to `round'
> > collect2: error: ld returned 1 exit status
> > make[5]: *** [testacl] Error 1
> > make[4]: *** [test-acl] Error 2
> > make[3]: *** [app] Error 2
> > make[2]: *** [all] Error 2
> > make[1]: *** [x86_64-ivshmem-linuxapp-gcc_install] Error 2
> > make: *** [install] Error 2
> >
> > Following installation procedure at link :
> >
> > https://github.com/01org/dpdk-
> ovs/blob/development/docs/01_Installation.md#dpdk

Could you try with dpdk 1.8? I am not sure if ovs supports DPDK 1.8 right now,
but the problem you are encountering was solved in 1.8.

Thanks,
Pablo

> >
> > 
> > thanks
> > srinivas.
> >

[dpdk-dev] No probed ethernet devices /DPDP 1.7.1 in Fedora 21

[sothy shan]

I guess you are completely wrong.

Becasue when I do

make config T=x86_64-ivshmem-linuxapp-gcc
make

Testpmd works.

When I do  with

export RTE_SDK=$(pwd)export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
make CONFIG_RTE_BUILD_COMBINE_LIBS=y CONFIG_RTE_BUILD_SHARED_LIB=y
install T="$RTE_TARGET"


I get same error. I guess there are some problems in above two config
variables. I see some email post over some changes.But I didnt get the
point, but working on it.

It is just information for you.


Best regards

Sothy



On Sat, Jan 10, 2015 at 1:44 PM, Neil Horman  wrote:

> On Fri, Jan 09, 2015 at 05:20:31PM +0100, sothy shan wrote:
> > According to your argument,
> >
> > I compiled qemu in DPDK OVS as provided with command.
> >
> > After that, I compiled as stated here.
> >
> > cd DPDK # DPDK sub-directoryexport
> > RTE_SDK=$(pwd)export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
> > make CONFIG_RTE_BUILD_COMBINE_LIBS=y CONFIG_RTE_BUILD_SHARED_LIB=y
> > install T="$RTE_TARGET"
> >
> > Then I try to run the command for testpmd. I got same error. Any idea
> > where is the mistake? Thanks
> >
> > DPDK 1.7.1 in Fedora 21. PLease see the error here
> >
> >
> Did you run qemu and create an ivshmem device?  Thats why you needed qemu
> support so that you could run it and have qemu create a network device
> that had
> a ivshmem interface
> Neil
>
> >
> >
> >
> > [cubiq at localhost dpdk-1.7.1]$ sudo
> > ./x86_64-ivshmem-linuxapp-gcc/app/testpmd -c7 -n3 -- -i --nb-cores=2
> > --nb-ports=2
> > EAL: Detected lcore 0 as core 0 on socket 0
> > EAL: Detected lcore 1 as core 1 on socket 0
> > EAL: Detected lcore 2 as core 2 on socket 0
> > EAL: Detected lcore 3 as core 3 on socket 0
> > EAL: Detected lcore 4 as core 0 on socket 0
> > EAL: Detected lcore 5 as core 1 on socket 0
> > EAL: Detected lcore 6 as core 2 on socket 0
> > EAL: Detected lcore 7 as core 3 on socket 0
> > EAL: Support maximum 64 logical core(s) by configuration.
> > EAL: Detected 8 lcore(s)
> > EAL: Searching for IVSHMEM devices...
> > EAL: No IVSHMEM configuration found!
> > EAL: Setting up memory...
> > EAL: Ask a virtual area of 0x180 bytes
> > EAL: Virtual area found at 0x7fbe5100 (size = 0x180)
> > EAL: Ask a virtual area of 0x140 bytes
> > EAL: Virtual area found at 0x7fbe4fa0 (size = 0x140)
> > EAL: Ask a virtual area of 0x80 bytes
> > EAL: Virtual area found at 0x7fbe52a0 (size = 0x80)
> > EAL: Ask a virtual area of 0x200 bytes
> > EAL: Virtual area found at 0x7fbe4d80 (size = 0x200)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fbe4d20 (size = 0x40)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fbe4cc0 (size = 0x40)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fbe4c60 (size = 0x40)
> > EAL: Ask a virtual area of 0x1c0 bytes
> > EAL: Virtual area found at 0x7fbe4a80 (size = 0x1c0)
> > EAL: Ask a virtual area of 0x40 bytes
> > EAL: Virtual area found at 0x7fbe4a20 (size = 0x40)
> > EAL: Requesting 64 pages of size 2MB from socket 0
> > EAL: TSC frequency is ~3691108 KHz
> > EAL: Master core 0 is ready (tid=98377940)
> > EAL: Core 2 is ready (tid=491fd700)
> > EAL: Core 1 is ready (tid=499fe700)
> > EAL: PCI device :06:00.0 on NUMA socket 0
> > EAL:   probe driver: 8086:154d rte_ixgbe_pmd
> > EAL:   :06:00.0 not managed by VFIO driver, skipping
> > EAL:   :06:00.0 not managed by UIO driver, skipping
> > EAL: PCI device :06:00.1 on NUMA socket 0
> > EAL:   probe driver: 8086:154d rte_ixgbe_pmd
> > EAL:   :06:00.1 not managed by VFIO driver, skipping
> > EAL:   :06:00.1 not managed by UIO driver, skipping
> > EAL: Error - exiting with code: 1
> >   Cause: No probed ethernet devices - check that
> > CONFIG_RTE_LIBRTE_IGB_PMD=y and that CONFIG_RTE_LIBRTE_EM_PMD=y and that
> > CONFIG_RTE_LIBRTE_IXGBE_PMD=y in your configuration file
> >
> >
> >
> > On Fri, Dec 26, 2014 at 3:37 PM, Neil Horman 
> wrote:
> >
> > > On Fri, Dec 26, 2014 at 09:01:13AM +0100, sothy shan wrote:
> > > > On Thu, Dec 25, 2014 at 6:08 PM, Neil Horman 
> > > wrote:
> > > >
> > > > > On Thu, Dec 25, 2014 at 10:11:51AM +0100, sothy shan wrote:
> > > > > > On Wed, Dec 24, 2014 at 4:04 PM, Neil Horman <
> nhorman at tuxdriver.com>
> > > > > wrote:
> > > > > >
> > > > > > > On Wed, Dec 24, 2014 at 02:26:21PM +0100, sothy shan wrote:
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > I am playing with DPDK 1.7.1 in Fedora.
> > > > > > > >
> > > > > > > > When I do like this:
> > > > > > > >
> > > > > > > > export RTE_SDK=$(pwd)export
> > > RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
> > > > > > > > make install T="$RTE_TARGET"
> > > > > > > >
> > > > > > > > It worked. Means Testpmd is running.
> > > > > > > >
> > > > > > > > When I run as mentioned below:
> > > > > > > >
> > > > > > > > make CONFIG_RTE_BUILD_SHARED_LIB=y  install T="$RTE_TARGET"
> >

[dpdk-dev] No probed ethernet devices /DPDP 1.7.1 in Fedora 21

[Olivier MATZ]

Hi Sothy,

On 01/16/2015 03:10 PM, sothy shan wrote:
> I guess you are completely wrong.
> 
> Becasue when I do
> 
> make config T=x86_64-ivshmem-linuxapp-gcc
> make
> 
> Testpmd works.
> 
> When I do  with
> 
> export RTE_SDK=$(pwd)export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
> make CONFIG_RTE_BUILD_COMBINE_LIBS=y CONFIG_RTE_BUILD_SHARED_LIB=y
> install T="$RTE_TARGET"

Are you sure that this syntax is supported by the build system?

As far as I know, RTE_SDK and RTE_TARGET must be defined when building
an external application (like in examples), not when building test-pmd
app which is a sdk built-in.

Also, I'm not sure passing a CONFIG_XYZ=y variable will be properly
taken in account by the build system. Where did you found this syntax?
The proper way is:

  make config T=x86_64-ivshmem-linuxapp-gcc O=my_dir
  ${EDITOR} my_dir/.config
  make O=my_dir

One last comment, please be careful when copy/pasting commands in
mails as there are typos in some of your commands. A reader could
expect that your problem comes from this:

  $ export RTE_SDK=$(pwd)export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
  $ echo $RTE_SDK
  /home/userexport

Regards,
Olivier

[dpdk-dev] [PATCH] librte_eal: Add fscanf return value test

[Tomasz Kulasek]

The lack of result checking of fscanf function, brakes compilation for default 
"-Werror=unused-result" flag.

Signed-off-by: Tomasz Kulasek 
---
 lib/librte_eal/linuxapp/eal/eal.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 648ef81..f99e158 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -865,6 +865,7 @@ rte_eal_check_module(const char *module_name)
 {
char mod_name[30]; /* Any module names can be longer than 30 bytes? */
int ret = 0;
+   int n;

if (NULL == module_name)
return -1;
@@ -876,8 +877,8 @@ rte_eal_check_module(const char *module_name)
return -1;
}
while (!feof(fd)) {
-   fscanf(fd, "%29s %*[^\n]", mod_name);
-   if (!strcmp(mod_name, module_name)) {
+   n = fscanf(fd, "%29s %*[^\n]", mod_name);
+   if ((n == 1) && !strcmp(mod_name, module_name)) {
ret = 1;
break;
}
-- 
1.7.9.5

--
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] more maintainers with sub-trees

[Thomas Monjalon]

2014-12-23 13:58, Neil Horman:
> On Tue, Dec 23, 2014 at 06:08:26PM +0100, Thomas Monjalon wrote:
> > Hello all,
> > 
> > We now have 2 new maintainers managing their own sub-tree for some
> > specific areas of DPDK:
> > - Stephen Hemminger will maintain the driver bnx2x
> > - Helin Zhang will maintain the driver i40e
> > 
> > These repositories can be browsed from the "next" section of this page:
> > http://dpdk.org/browse/
> > 
> > Patches should still be sent to dev at dpdk.org for review.
> > They will be applied to the sub-tree first, and will be merged in dpdk.git
> > after a pull request is submitted.
> > 
> > More sub-trees can be created on demand.
> > 
> Can you describe the expected workflow for these subtrees?  I ask because it
> seems a bit odd to have a separate subtrees for bnx2x (which doesn't appear to
> exist in either tree yet) and i40e, while other pmd's all ostensibly still go
> through your tree.  I presume that Stephen and Helin will send you merge
> requests prior to -rc releases, and that for changes that affect pmd's
> tree-wide, we can circumvent the subtree with Stephen/Helin's signoff?

As discussed in another thread, these are the first trials of sub-trees.
We could adjust the workflow step by step when walking.
The idea is to make pull requests during first phases but last patches during
-rc phase would probably be directly integrated into the main repository.
This sub-tree could provide a convenient source for testers before pushing
into the main tree.

Intel expressed an interest in trying this workflow.
Stephen (Brocade) needs it to work on first public version of their PMDs.

-- 
Thomas

[dpdk-dev] Why nothing since 1.8.0?

[Marc Sune]

On 15/01/15 19:51, Neil Horman wrote:
> On Thu, Jan 15, 2015 at 06:25:33PM +0100, Thomas Monjalon wrote:
>> 2015-01-15 08:06, Neil Horman:
>>> On Thu, Jan 15, 2015 at 10:51:38AM +0100, Thomas Monjalon wrote:
 2015-01-15 04:27, Ouyang, Changchun:
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
>>> On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger wrote:
 Ok, so 1.8.0 came out almost a month ago and none of the patches
 that were deferred waiting for the release got merged since then.
 Last commit in git is the 1.8.0 release.

 Where is the post-merge window bundle, where are the later commits?
 Lots of patches are sitting rotting in patchwork...
>>> +1, I've had the same questions.
>>> Neil
>> +1, Some patch set might be ready for being merged.
> +1,  the earlier some patches are merged into mainline, and the easier 
> those
> sequent patch sets can resolve their conflicts.
 +1, there are some patches which are properly reviewed

 Reminder: sub-tree to manage specific part of DPDK can be open on request
>>> Ok, I think what you're saying here is you're too busy to handle all the 
>>> patches
>>> comming in at the moment.  As such I'd like to propose a sub-tree 
>>> encompassing
>>> all the pmds in DPDK.  I would envision that including all the acutal pmd's 
>>> in
>>> the tree, as well as the infrastructure that is used to interface them to 
>>> the
>>> core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the patch 
>>> pool
>>> and send you pull requests.
>> [snip]
>> And that doesn't account for the ~500 patches that come in via pull 
>> request from the wireless subtree. Nor does it account for the merge 
>> window for net-next being 2 months instead of dpdk's 6 months.

Neil,

I don't want to hinder the discussion but: could you please point me out 
where this wireless subtree is?

Maybe I am too blind, but I cannot see it here:

http://dpdk.org/browse/

We are interested in acceleration for wireless NICs.

Marc

[snip]

[dpdk-dev] [PATCH] librte_eal: Add fscanf return value test

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz Kulasek
> Sent: Friday, January 16, 2015 2:28 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] librte_eal: Add fscanf return value test
> 
> The lack of result checking of fscanf function, brakes compilation for default
> "-Werror=unused-result" flag.
> 
> Signed-off-by: Tomasz Kulasek 

Acked-by: Pablo de Lara 

[dpdk-dev] [PATCH] bsdapp: replace d_thread_t with struct thread in nic_uio

[Thomas Monjalon]

2015-01-16 12:24, Bruce Richardson:
> Reported by: John Baldwin 
> Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196691
> 
> Quote:
> "The d_thread_t typedef is a compat shim to support FreeBSD 4.x.  I'm 
> planning to remove this shim from 11 and dpdk is very unlikely to ever be 
> ported to 4.x.
>  If it does it will need far more changes than just d_thread_t"
> 
> Signed-off-by: Bruce Richardson 

Applied
http://dpdk.org/browse/dpdk/commit/?id=01e66999

Note that the definitive title starts with nic_uio and describe the goal
of the patch. I use this kind of command to remember which keyword must be used:
git log --oneline lib/librte_eal/bsdapp/nic_uio
I also try to keep a consistent formatting for keywords like Reported-by.

Thanks
-- 
Thomas

[dpdk-dev] [PATCH] eal / malloc : alignment parameter check failing due to changes in rte_is_power_of_2

[Declan Doherty]

In commit 2fc8d6d the behaviour of function rte_is_power_of_2 was
changed to not return true for 0. memzone_reserve_aligned_thread_unsafe
and rte_malloc_socket both make the assumption that for align = 0
!rte_is_power_of_2(align) will return false. This patch adds a check
that align parameter is non-zero before doing the power of 2 check

Signed-off-by: Declan Doherty 
---
 lib/librte_eal/common/eal_common_memzone.c | 2 +-
 lib/librte_malloc/rte_malloc.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_memzone.c 
b/lib/librte_eal/common/eal_common_memzone.c
index b5a5d72..3f09338 100644
--- a/lib/librte_eal/common/eal_common_memzone.c
+++ b/lib/librte_eal/common/eal_common_memzone.c
@@ -156,7 +156,7 @@ memzone_reserve_aligned_thread_unsafe(const char *name, 
size_t len,
}

/* if alignment is not a power of two */
-   if (!rte_is_power_of_2(align)) {
+   if (align ? !rte_is_power_of_2(align) : 0) {
RTE_LOG(ERR, EAL, "%s(): Invalid alignment: %u\n", __func__,
align);
rte_errno = EINVAL;
diff --git a/lib/librte_malloc/rte_malloc.c b/lib/librte_malloc/rte_malloc.c
index b966fc7..15c7e20 100644
--- a/lib/librte_malloc/rte_malloc.c
+++ b/lib/librte_malloc/rte_malloc.c
@@ -75,7 +75,7 @@ rte_malloc_socket(const char *type, size_t size, unsigned 
align, int socket_arg)
void *ret;

/* return NULL if size is 0 or alignment is not power-of-2 */
-   if (size == 0 || !rte_is_power_of_2(align))
+   if (size == 0 || align ? !rte_is_power_of_2(align) : 0)
return NULL;

if (socket_arg == SOCKET_ID_ANY)
-- 
1.7.12.2

[dpdk-dev] [PATCH v5 1/4] compat: Add infrastructure to support symbol versioning

[Neil Horman]

Add initial pass header files to support symbol versioning.

Signed-off-by: Neil Horman 
CC: Thomas Monjalon 
CC: "Richardson, Bruce" 
CC: "Gonzalez Monroy, Sergio" 

---
Change Notes:
V2)
Moved ifeq to _INSTALL target

V3)
Undo V2 changes and make librte_compat use the rte.install.mk file
instead

v4)
changed --version-script to accept SRCDIR in this patch at per request
documented versioning macros
cleaned up macro parameter consistency
converted SA macro to RTE_STR macro
fixed copyright
---
 lib/Makefile   |   1 +
 lib/librte_compat/Makefile |  38 +
 lib/librte_compat/rte_compat.h | 117 +
 mk/rte.lib.mk  |   4 ++
 4 files changed, 160 insertions(+)
 create mode 100644 lib/librte_compat/Makefile
 create mode 100644 lib/librte_compat/rte_compat.h

diff --git a/lib/Makefile b/lib/Makefile
index 0ffc982..d617d81 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -31,6 +31,7 @@

 include $(RTE_SDK)/mk/rte.vars.mk

+DIRS-y += librte_compat
 DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal
 DIRS-$(CONFIG_RTE_LIBRTE_MALLOC) += librte_malloc
 DIRS-$(CONFIG_RTE_LIBRTE_RING) += librte_ring
diff --git a/lib/librte_compat/Makefile b/lib/librte_compat/Makefile
new file mode 100644
index 000..0bab870
--- /dev/null
+++ b/lib/librte_compat/Makefile
@@ -0,0 +1,38 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2013 Neil Horman 
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+
+# install includes
+SYMLINK-y-include := rte_compat.h
+
+include $(RTE_SDK)/mk/rte.install.mk
diff --git a/lib/librte_compat/rte_compat.h b/lib/librte_compat/rte_compat.h
new file mode 100644
index 000..d7cc176
--- /dev/null
+++ b/lib/librte_compat/rte_compat.h
@@ -0,0 +1,117 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) 2010 Neil Horman .
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF TH

[dpdk-dev] [PATCH v5 2/4] Provide initial versioning for all DPDK libraries

[Neil Horman]

Add linker version script files to each DPDK library to put a stake in the
ground from which we can start cleaning up API's

Signed-off-by: Neil Horman 
CC: Thomas Monjalon 
CC: "Richardson, Bruce" 

---
Change Notes:

v2)
* Updated export map to not require full path
---
 lib/librte_acl/Makefile|   2 +
 lib/librte_acl/rte_acl_version.map |  21 
 lib/librte_cfgfile/Makefile|   2 +
 lib/librte_cfgfile/rte_cfgfile_version.map |  14 +++
 lib/librte_cmdline/Makefile|   2 +
 lib/librte_cmdline/rte_cmdline_version.map |  69 +
 lib/librte_distributor/Makefile|   2 +
 lib/librte_distributor/rte_distributor_version.map |  16 +++
 lib/librte_eal/bsdapp/eal/Makefile |   2 +
 lib/librte_eal/bsdapp/eal/rte_eal_version.map  |  90 
 lib/librte_eal/linuxapp/eal/Makefile   |   2 +
 lib/librte_eal/linuxapp/eal/rte_eal_version.map|  90 
 lib/librte_ether/Makefile  |   2 +
 lib/librte_ether/rte_ether_version.map | 113 +
 lib/librte_hash/Makefile   |   2 +
 lib/librte_hash/rte_hash_version.map   |  18 
 lib/librte_ip_frag/Makefile|   2 +
 lib/librte_ip_frag/rte_ipfrag_version.map  |  14 +++
 lib/librte_ivshmem/Makefile|   2 +
 lib/librte_ivshmem/rte_ivshmem_version.map |  13 +++
 lib/librte_kni/Makefile|   2 +
 lib/librte_kni/rte_kni_version.map |  20 
 lib/librte_kvargs/Makefile |   2 +
 lib/librte_kvargs/rte_kvargs_version.map   |  10 ++
 lib/librte_lpm/Makefile|   2 +
 lib/librte_lpm/rte_lpm_version.map |  24 +
 lib/librte_malloc/Makefile |   2 +
 lib/librte_malloc/rte_malloc_version.map   |  19 
 lib/librte_mbuf/Makefile   |   2 +
 lib/librte_mbuf/rte_mbuf_version.map   |  14 +++
 lib/librte_mempool/Makefile|   2 +
 lib/librte_mempool/rte_mempool_version.map |  18 
 lib/librte_meter/Makefile  |   2 +
 lib/librte_meter/rte_meter_version.map |  13 +++
 lib/librte_pipeline/Makefile   |   2 +
 lib/librte_pipeline/rte_pipeline_version.map   |  23 +
 lib/librte_pmd_af_packet/Makefile  |   2 +
 .../rte_pmd_af_packet_version.map  |   7 ++
 lib/librte_pmd_bond/Makefile   |   2 +
 lib/librte_pmd_bond/rte_eth_bond_version.map   |  21 
 lib/librte_pmd_e1000/Makefile  |   2 +
 lib/librte_pmd_e1000/rte_pmd_e1000_version.map |   5 +
 lib/librte_pmd_enic/Makefile   |   2 +
 lib/librte_pmd_enic/rte_pmd_enic_version.map   |   5 +
 lib/librte_pmd_i40e/Makefile   |   2 +
 lib/librte_pmd_i40e/rte_pmd_i40e_version.map   |   5 +
 lib/librte_pmd_ixgbe/Makefile  |   2 +
 lib/librte_pmd_ixgbe/rte_pmd_ixgbe_version.map |   5 +
 lib/librte_pmd_pcap/Makefile   |   2 +
 lib/librte_pmd_pcap/rte_pmd_pcap_version.map   |   5 +
 lib/librte_pmd_ring/Makefile   |   2 +
 lib/librte_pmd_ring/rte_eth_ring.c |   2 +-
 lib/librte_pmd_ring/rte_eth_ring.h |   6 --
 lib/librte_pmd_ring/rte_eth_ring_version.map   |  10 ++
 lib/librte_pmd_virtio/Makefile |   1 +
 lib/librte_pmd_virtio/rte_pmd_virtio_version.map   |   5 +
 lib/librte_pmd_vmxnet3/Makefile|   2 +
 lib/librte_pmd_vmxnet3/rte_pmd_vmxnet3_version.map |   5 +
 lib/librte_pmd_xenvirt/Makefile|   2 +
 lib/librte_pmd_xenvirt/rte_eth_xenvirt_version.map |   8 ++
 lib/librte_port/Makefile   |   2 +
 lib/librte_port/rte_port_version.map   |  18 
 lib/librte_power/Makefile  |   2 +
 lib/librte_power/rte_power_version.map |  18 
 lib/librte_ring/Makefile   |   2 +
 lib/librte_ring/rte_ring_version.map   |  12 +++
 lib/librte_sched/Makefile  |   2 +
 lib/librte_sched/rte_sched_version.map |  22 
 lib/librte_table/Makefile  |   2 +
 lib/librte_table/rte_table_version.map |  22 
 lib/librte_timer/Makefile  |   2 +
 lib/librte_timer/rte_timer_version.map |  16 +++
 lib/librte_vhost/Makefile  |   2 +
 lib/librte_vhost/rte_vhost_version.map |  14 +++
 74 files changed, 874 insertions(+), 7 deletions(-)
 create mode 100644 lib/librte_acl/rte_acl_version.map
 create mode 100644 lib/librte_cfgfile/rte_cfg

[dpdk-dev] [PATCH v5 3/4] Add library version extenstion

[Neil Horman]

To differentiate libraries that break ABI, we add a library version number
suffix to the library, which must be incremented when a given libraries ABI is
broken.  This patch enforces that addition, sets the initial abi soname
extension to 1 for each library and creates a symlink to the base SONAME so that
the test applications will link properly.

Signed-off-by: Neil Horman 
CC: Thomas Monjalon 
CC: "Richardson, Bruce" 

---
Change Notes:
v3)
Made symlinking of libraries conditional on a DSO build

v4) Removed erroneous newline
changed @exit 1 to @false
changed ./$(LIB) to $<
---
 lib/librte_acl/Makefile  |  2 ++
 lib/librte_cfgfile/Makefile  |  2 ++
 lib/librte_cmdline/Makefile  |  2 ++
 lib/librte_compat/Makefile   |  2 ++
 lib/librte_distributor/Makefile  |  2 ++
 lib/librte_eal/bsdapp/eal/Makefile   |  2 ++
 lib/librte_eal/linuxapp/eal/Makefile |  2 ++
 lib/librte_ether/Makefile|  2 ++
 lib/librte_hash/Makefile |  2 ++
 lib/librte_ip_frag/Makefile  |  2 ++
 lib/librte_ivshmem/Makefile  |  2 ++
 lib/librte_kni/Makefile  |  2 ++
 lib/librte_kvargs/Makefile   |  2 ++
 lib/librte_lpm/Makefile  |  2 ++
 lib/librte_malloc/Makefile   |  2 ++
 lib/librte_mbuf/Makefile |  2 ++
 lib/librte_mempool/Makefile  |  2 ++
 lib/librte_meter/Makefile|  2 ++
 lib/librte_pipeline/Makefile |  2 ++
 lib/librte_pmd_af_packet/Makefile|  2 ++
 lib/librte_pmd_bond/Makefile |  2 ++
 lib/librte_pmd_e1000/Makefile|  2 ++
 lib/librte_pmd_enic/Makefile |  2 ++
 lib/librte_pmd_i40e/Makefile |  2 ++
 lib/librte_pmd_ixgbe/Makefile|  2 ++
 lib/librte_pmd_pcap/Makefile |  2 ++
 lib/librte_pmd_ring/Makefile |  2 ++
 lib/librte_pmd_virtio/Makefile   |  2 ++
 lib/librte_pmd_vmxnet3/Makefile  |  2 ++
 lib/librte_pmd_xenvirt/Makefile  |  2 ++
 lib/librte_port/Makefile |  2 ++
 lib/librte_power/Makefile|  2 ++
 lib/librte_ring/Makefile |  2 ++
 lib/librte_sched/Makefile|  2 ++
 lib/librte_table/Makefile|  2 ++
 lib/librte_timer/Makefile|  2 ++
 lib/librte_vhost/Makefile|  2 ++
 mk/rte.lib.mk| 12 ++--
 38 files changed, 84 insertions(+), 2 deletions(-)

diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile
index 45cbf80..765deb1 100644
--- a/lib/librte_acl/Makefile
+++ b/lib/librte_acl/Makefile
@@ -39,6 +39,8 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)

 EXPORT_MAP := rte_acl_version.map

+LIBABIVER := 1
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_ACL) += tb_mem.c

diff --git a/lib/librte_cfgfile/Makefile b/lib/librte_cfgfile/Makefile
index a4f73de..032c240 100644
--- a/lib/librte_cfgfile/Makefile
+++ b/lib/librte_cfgfile/Makefile
@@ -41,6 +41,8 @@ CFLAGS += $(WERROR_FLAGS)

 EXPORT_MAP := rte_cfgfile_version.map

+LIBABIVER := 1
+
 #
 # all source are stored in SRCS-y
 #
diff --git a/lib/librte_cmdline/Makefile b/lib/librte_cmdline/Makefile
index 3c71831..719dff6 100644
--- a/lib/librte_cmdline/Makefile
+++ b/lib/librte_cmdline/Makefile
@@ -38,6 +38,8 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3

 EXPORT_MAP := rte_cmdline_version.map

+LIBABIVER := 1
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) := cmdline.c
 SRCS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_cirbuf.c
diff --git a/lib/librte_compat/Makefile b/lib/librte_compat/Makefile
index 0bab870..0c57533 100644
--- a/lib/librte_compat/Makefile
+++ b/lib/librte_compat/Makefile
@@ -32,6 +32,8 @@
 include $(RTE_SDK)/mk/rte.vars.mk


+LIBABIVER := 1
+
 # install includes
 SYMLINK-y-include := rte_compat.h

diff --git a/lib/librte_distributor/Makefile b/lib/librte_distributor/Makefile
index 3674a2c..4c9af17 100644
--- a/lib/librte_distributor/Makefile
+++ b/lib/librte_distributor/Makefile
@@ -39,6 +39,8 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)

 EXPORT_MAP := rte_distributor_version.map

+LIBABIVER := 1
+
 # all source are stored in SRCS-y
 SRCS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) := rte_distributor.c

diff --git a/lib/librte_eal/bsdapp/eal/Makefile 
b/lib/librte_eal/bsdapp/eal/Makefile
index 0b5f9d9..ae214a4 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -48,6 +48,8 @@ CFLAGS += $(WERROR_FLAGS) -O3

 EXPORT_MAP := rte_eal_version.map

+LIBABIVER := 1
+
 # specific to linuxapp exec-env
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) := eal.c
 SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_memory.c
diff --git a/lib/librte_eal/linuxapp/eal/Makefile 
b/lib/librte_eal/linuxapp/eal/Makefile
index bae8af1..e117cec 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -35,6 +35,8 @@ LIB = librte_eal.a

 EXPORT_MAP := rte_eal_version.map

+LIBABIVER := 1
+
 VPATH += $(RTE_SDK)/lib/librte_eal/common

 CFLAGS += -I$(SRCDI

[dpdk-dev] [PATCH v5 4/4] docs: Add ABI documentation

[Neil Horman]

Adding a document describing rudimentary ABI policy and adding notice space for
any deprecation announcements

Signed-off-by: Neil Horman 
CC: Thomas Monjalon 
CC: "Richardson, Bruce" 

---
Change notes:

v5) Updated documentation to add notes from Thomas M.
---
 doc/abi.txt | 36 
 1 file changed, 36 insertions(+)
 create mode 100644 doc/abi.txt

diff --git a/doc/abi.txt b/doc/abi.txt
new file mode 100644
index 000..14be464
--- /dev/null
+++ b/doc/abi.txt
@@ -0,0 +1,36 @@
+ABI policy:
+   ABI versions are set at the time of major release labeling, and ABI may
+change multiple times between the last labeling and the HEAD label of the git
+tree without warning
+
+   ABI versions, once released are available until such time as their
+deprecation has been noted here for at least one major release cycle, after it
+has been tagged.  E.g. the ABI for DPDK 1.8 is shipped, and then the decision 
to
+remove it is made during the development of DPDK 1.9.  The decision will be
+recorded here, shipped with the DPDK 1.9 release, and actually removed when 
DPDK
+1.10 ships.
+
+   ABI versions may be deprecated in whole, or in part as needed by a given
+update.
+
+   Some ABI changes may be too significant to reasonably maintain multiple
+versions of.  In those events ABI's may be updated without backward
+compatibility provided.  The requirements for doing so are:
+   1) At least 3 acknoweldgements of the need on the dpdk.org
+   2) A full deprecation cycle must be made to offer downstream consumers
+sufficient warning of the change.  E.g. if dpdk 2.0 is under development when
+the change is proposed, a deprecation notice must be added to this file, and
+released with dpdk 2.0.  Then the change may be incorporated for dpdk 2.1
+   3) The LIBABIVER variable in the makefilei(s) where the ABI changes are
+incorporated must be incremented in parallel with the ABI changes themselves
+
+   Note that the above process for ABI deprecation should not be undertaken
+lightly.  ABI stability is extreemely important for downstream consumers of the
+DPDK, especially when distributed in shared object form.  Every effort should 
be
+made to preserve ABI whenever possible.  For instance, reorganizing public
+structure field for astetic or readability purposes should be avoided as it 
will
+cause ABI breakage.  Only significant (e.g. performance) reasons should be seen
+as cause to alter ABI.
+  
+Deprecation Notices:
+
-- 
2.1.0

[dpdk-dev] [PATCH] eal / malloc : alignment parameter check failing due to changes in rte_is_power_of_2

[De Lara Guarch, Pablo]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty
> Sent: Friday, January 16, 2015 3:11 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] eal / malloc : alignment parameter check failing
> due to changes in rte_is_power_of_2
> 
> In commit 2fc8d6d the behaviour of function rte_is_power_of_2 was
> changed to not return true for 0. memzone_reserve_aligned_thread_unsafe
> and rte_malloc_socket both make the assumption that for align = 0
> !rte_is_power_of_2(align) will return false. This patch adds a check
> that align parameter is non-zero before doing the power of 2 check
> 
> Signed-off-by: Declan Doherty 

Acked-by: Pablo de Lara 

[dpdk-dev] No probed ethernet devices /DPDP 1.7.1 in Fedora 21

[sothy shan]

On Fri, Jan 16, 2015 at 3:27 PM, Olivier MATZ  wrote:
> Hi Sothy,
>
> On 01/16/2015 03:10 PM, sothy shan wrote:
>> I guess you are completely wrong.
>>
>> Becasue when I do
>>
>> make config T=x86_64-ivshmem-linuxapp-gcc
>> make
>>
>> Testpmd works.
>>
>> When I do  with
>>
>> export RTE_SDK=$(pwd)export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
>> make CONFIG_RTE_BUILD_COMBINE_LIBS=y CONFIG_RTE_BUILD_SHARED_LIB=y
>> install T="$RTE_TARGET"
>
> Are you sure that this syntax is supported by the build system?

I am tryiting to build DPDK OVS and found  the instruction in
https://github.com/01org/dpdk-ovs/blob/development/docs/01_Installation.md


>
> As far as I know, RTE_SDK and RTE_TARGET must be defined when building
> an external application (like in examples), not when building test-pmd
> app which is a sdk built-in.

If I understand the your idea, I should compile and run DPDK OVS
directly rather than DPDK testpmd. Isnt it? I will try now this.

Before, I tries testpmd and then go for DPDK OVS.

>
> Also, I'm not sure passing a CONFIG_XYZ=y variable will be properly
> taken in account by the build system. Where did you found this syntax?

https://github.com/01org/dpdk-ovs/blob/development/docs/01_Installation.md

> The proper way is:
>
>   make config T=x86_64-ivshmem-linuxapp-gcc O=my_dir
>   ${EDITOR} my_dir/.config
>   make O=my_dir
>
> One last comment, please be careful when copy/pasting commands in
> mails as there are typos in some of your commands. A reader could
> expect that your problem comes from this:
>
>   $ export RTE_SDK=$(pwd)export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
>   $ echo $RTE_SDK
>   /home/userexport
>

Sorry for mistake and I will do with care nw.

> Regards,
> Olivier

[dpdk-dev] No probed ethernet devices /DPDP 1.7.1 in Fedora 21

[Olivier MATZ]

Hi Sothy,

On 01/16/2015 05:07 PM, sothy shan wrote:
> On Fri, Jan 16, 2015 at 3:27 PM, Olivier MATZ  
> wrote:
>>> When I do  with
>>>
>>> export RTE_SDK=$(pwd)export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
>>> make CONFIG_RTE_BUILD_COMBINE_LIBS=y CONFIG_RTE_BUILD_SHARED_LIB=y
>>> install T="$RTE_TARGET"
>>
>> Are you sure that this syntax is supported by the build system?
> 
> I am tryiting to build DPDK OVS and found  the instruction in
> https://github.com/01org/dpdk-ovs/blob/development/docs/01_Installation.md

I just noticed the syntax is strange, you can check the supported
options here:

http://dpdk.org/doc/guides/prog_guide/dev_kit_build_system.html#makefile-description

I'm not sure the CONFIG_ will be taken in account when generating
rte_config.h (see rte.sdkconfig.mk and scripts/gen-config-h.sh). But
maybe it's not related to your issue.

Regards,
Olivier

[dpdk-dev] Does I210 NIC support Flow director filters?

[Kamraan Nasim]

Hi Bruce,
Perhaps this can be worked around by setting  rx_drop_en in the
rte_eth_rxconf  and
using small values for number of rx descripters so that the NIC drops when
it is out of RX descriptors for that queue?

As long as NIC can still provide q_ipackets/q_errors then this might be
faster than doing a RX in software and drop.

--Kam

On Fri, Jan 16, 2015 at 5:56 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:

> On Thu, Jan 15, 2015 at 08:06:52PM -0500, Kamraan Nasim wrote:
> > >>> update the RSS RETA table so that traffic doesn't get sent
> > >> to that queue via RSS. Is that what you are asking?
> >
> > Thanks Bruce, that's exactly it.  Basically each filter will forward
> > traffic to a unique RSS queue which can allow me to calculate filter
> match
> > statistics for that queue(or filter). At that point I would like to drop
> > the filtered packet. Is there any way to drop the filtered packet in the
> > RSS queue without doing a rte_eth_rx_burst() and dropping it then?
> >
> > --Kam
> >
> I don't believe there is any other way to drop them from the queue other
> than
> RX and drop. It's not the most efficient way to do so (since you have to
> allocate,
> fill and free an mbuf), but it's the only way that an app can do so without
> adding new functions to the driver(s).
>
> /Bruce
>

[dpdk-dev] [PATCH 0/2] support TSO on i40e

[Ananyev, Konstantin]

> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> Sent: Friday, January 16, 2015 2:31 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 0/2] support TSO on i40e
> 
> This patch set enables i40e TSO feature for both non-tunneling packet and UDP 
> tunneling packet.
> 
> Jijiang Liu (2):
>   support i40e TSO
>   csum fwd engine testpmd change
> 
>  app/test-pmd/csumonly.c   |7 +-
>  lib/librte_pmd_i40e/i40e_ethdev.c |3 +-
>  lib/librte_pmd_i40e/i40e_rxtx.c   |  111 +++-
>  lib/librte_pmd_i40e/i40e_rxtx.h   |   13 
>  4 files changed, 102 insertions(+), 32 deletions(-)
> 

Acked-by: Konstantin Ananyev 

> --
> 1.7.7.6

[dpdk-dev] No probed ethernet devices /DPDP 1.7.1 in Fedora 21

[sothy shan]

On Fri, Jan 16, 2015 at 5:35 PM, Olivier MATZ  wrote:
> Hi Sothy,
>
> On 01/16/2015 05:07 PM, sothy shan wrote:
>> On Fri, Jan 16, 2015 at 3:27 PM, Olivier MATZ  
>> wrote:
 When I do  with

 export RTE_SDK=$(pwd)export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
 make CONFIG_RTE_BUILD_COMBINE_LIBS=y CONFIG_RTE_BUILD_SHARED_LIB=y
 install T="$RTE_TARGET"
>>>
>>> Are you sure that this syntax is supported by the build system?
>>
>> I am tryiting to build DPDK OVS and found  the instruction in
>> https://github.com/01org/dpdk-ovs/blob/development/docs/01_Installation.md
>
> I just noticed the syntax is strange, you can check the supported
> options here:
>
> http://dpdk.org/doc/guides/prog_guide/dev_kit_build_system.html#makefile-description

For me, I followed the top leve compilation and compilation went well.
https://github.com/01org/dpdk-ovs/blob/development/docs/01_Installation.md
It means those paremeters are taken into account somewhere.

Now I didnt check testpmd command and directly went to run ovs-dpdk in
Fedora 20 with DPDK OVS 1.2

I am in another problem. I guess it is out of your focus, I just give
you the idea.



sudo ./datapath/dpdk/ovs-dpdk -c 0x1E -n 4 --proc

-type
primary --huge-dir=/mnt/huge -- --stats_core=4 --stats=5 -p 0x07
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 0 on socket 0
EAL: Detected lcore 5 as core 1 on socket 0
EAL: Detected lcore 6 as core 2 on socket 0
EAL: Detected lcore 7 as core 3 on socket 0
EAL: Support maximum 64 logical core(s) by configuration.
EAL: Detected 8 lcore(s)
EAL:   cannot open VFIO container, error 2 (No such file or directory)
EAL: VFIO support could not be initialized
EAL: Searching for IVSHMEM devices...
EAL: No IVSHMEM configuration found!
EAL: Setting up memory...
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fcb5b40 (size = 0x20)
EAL: Ask a virtual area of 0x300 bytes
EAL: Virtual area found at 0x7fcb5820 (size = 0x300)
EAL: Ask a virtual area of 0x380 bytes
EAL: Virtual area found at 0x7fcb5480 (size = 0x380)
EAL: Ask a virtual area of 0x100 bytes
EAL: Virtual area found at 0x7fcb5360 (size = 0x100)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7fcb5300 (size = 0x40)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7fcb52c0 (size = 0x20)
EAL: Requesting 64 pages of size 2MB from socket 0
EAL: TSC frequency is ~3691107 KHz
EAL: Master core 1 is ready (tid=5b701940)
EAL: Core 4 is ready (tid=513fc700)
EAL: Core 3 is ready (tid=51bfd700)
EAL: Core 2 is ready (tid=523fe700)
EAL: PCI device :03:00.0 on NUMA socket -1
EAL:   probe driver: 8086:150e rte_igb_pmd
EAL:   PCI memory mapped at 0x7fcb5b645000
EAL:   PCI memory mapped at 0x7fcb5b70a000
EAL: PCI device :03:00.1 on NUMA socket -1
EAL:   probe driver: 8086:150e rte_igb_pmd
EAL:   PCI memory mapped at 0x7fcb5b38
EAL:   PCI memory mapped at 0x7fcb5b706000
EAL: PCI device :03:00.2 on NUMA socket -1
EAL:   probe driver: 8086:150e rte_igb_pmd
EAL:   PCI memory mapped at 0x7fcb5b30
EAL:   PCI memory mapped at 0x7fcb5b641000
EAL: PCI device :03:00.3 on NUMA socket -1
EAL:   probe driver: 8086:150e rte_igb_pmd
EAL:   PCI memory mapped at 0x7fcb5b28
EAL:   PCI memory mapped at 0x7fcb5b63d000
EAL: PCI device :06:00.0 on NUMA socket -1
EAL:   probe driver: 8086:154d rte_ixgbe_pmd
EAL:   :06:00.0 not managed by UIO driver, skipping
EAL: PCI device :06:00.1 on NUMA socket -1
EAL:   probe driver: 8086:154d rte_ixgbe_pmd
EAL:   :06:00.1 not managed by UIO driver, skipping
PANIC in ovdk_mempools_init():
Cannot create ctrlmbuf mempool 'OVDK_Ctrlmbuf_Mempool' (Cannot allocate memory)
1: [/home/cubiq/sothy/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.s


  o(rte_dump_stack+0x18) [0x7fcb5b7922d8]]


 ?
>
> I'm not sure the CONFIG_ will be taken in account when generating
> rte_config.h (see rte.sdkconfig.mk and scripts/gen-config-h.sh). But
> maybe it's not related to your issue.

Yes, Atleast build and check :-) Thanks a lot
>
> Regards,
> Olivier

[dpdk-dev] Why nothing since 1.8.0?

[Neil Horman]

On Thu, Jan 15, 2015 at 09:55:00PM +, O'driscoll, Tim wrote:
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > Sent: Thursday, January 15, 2015 6:51 PM
> > To: Thomas Monjalon
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] Why nothing since 1.8.0?
> > 
> > On Thu, Jan 15, 2015 at 06:25:33PM +0100, Thomas Monjalon wrote:
> > > 2015-01-15 08:06, Neil Horman:
> > > > On Thu, Jan 15, 2015 at 10:51:38AM +0100, Thomas Monjalon wrote:
> > > > > 2015-01-15 04:27, Ouyang, Changchun:
> > > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
> > > > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil
> > Horman
> > > > > > > > On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger
> > wrote:
> > > > > > > > > Ok, so 1.8.0 came out almost a month ago and none of the
> > patches
> > > > > > > > > that were deferred waiting for the release got merged since
> > then.
> > > > > > > > > Last commit in git is the 1.8.0 release.
> > > > > > > > >
> > > > > > > > > Where is the post-merge window bundle, where are the later
> > commits?
> > > > > > > > > Lots of patches are sitting rotting in patchwork...
> > > > > > > >
> > > > > > > > +1, I've had the same questions.
> > > > > > > > Neil
> > > > > > >
> > > > > > > +1, Some patch set might be ready for being merged.
> > > > > >
> > > > > > +1,  the earlier some patches are merged into mainline, and the 
> > > > > > easier
> > those
> > > > > > sequent patch sets can resolve their conflicts.
> > > > >
> > > > > +1, there are some patches which are properly reviewed
> > > > >
> > > > > Reminder: sub-tree to manage specific part of DPDK can be open on
> > request
> > > >
> > > > Ok, I think what you're saying here is you're too busy to handle all the
> > patches
> > > > comming in at the moment.  As such I'd like to propose a sub-tree
> > encompassing
> > > > all the pmds in DPDK.  I would envision that including all the acutal 
> > > > pmd's
> > in
> > > > the tree, as well as the infrastructure that is used to interface them 
> > > > to the
> > > > core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the 
> > > > patch pool
> > > > and send you pull requests.
> > >
> > > The list of PMDs is increasing:
> > >   librte_pmd_af_packet
> > >   librte_pmd_bond
> > >   librte_pmd_e1000
> > >   librte_pmd_enic
> > >   librte_pmd_i40e
> > >   librte_pmd_ixgbe
> > >   librte_pmd_pcap
> > >   librte_pmd_ring
> > >   librte_pmd_virtio
> > >   librte_pmd_vmxnet3
> > >   librte_pmd_xenvirt
> > > There is already some sub-trees for bnx2x, fm10k and i40e:
> > >   http://dpdk.org/browse/
> > >
> > Yes, and I've mentioned before that that is an absolutely silly way to break
> > out
> > subtrees.  You have to find a balance of workload distribution and developer
> > convienience.
> > 
> > I also note that these are problematic because you're not merging anything
> > from them. Is it your intention to keep bnx2 and fm10k separate in
> > perpituity?
> > If so, thats a real problem, because then we effectively just have several 
> > out
> > of tree drivers, and thats just unacceptible.
> > 
> > > > If you could set me up with a login to dpdk.org, I'd appreciate it.
> > >
> > > It is preferred to have 1 sub-tree per module.
> > > What do you think of managing contributions for af_packet and/or virtio?
> > > It would make sense as virtio is a RedHat technology.
> > > Maybe it could include vhost lib and example.
> > >
> > No, for reasons I've mentioned before.  If you take each pmd/library and
> > create
> > a subtree for it, you've created the most fine grained control of subtrees 
> > you
> > could ask for, but you've created a nighmare of a burden on developers who
> > want
> > to update any code, especially if they have patches that hit multiple trees.
> > 
> > Look at some of the stats in the dpdk tree:
> > 
> > Library Commits between 1.7.0 and 1.8.0
> > librte_acl  5
> > librte_cfgfile  0
> > librte_cmdline  4
> > librte_compat   0
> > librte_distributor  5
> > librte_eal  125
> > librte_ether31
> > librte_hash 1
> > librte_ip_frag  5
> > librte_ivshmem  0
> > librte_kni  2
> > librte_kvargs   0
> > librte_lpm  1
> > librte_malloc   1
> > librte_mbuf 39
> > librte_mempool  4
> > librte_meter0
> > librte_net  4
> > librte_pipeline 0
> > librte_pmd_af_packet4
> > librte_pmd_bond 20
> > librte_pmd_e100021
> > librte_pmd_enic 12
> > librte_pmd_i40e 90
> > librte_pmd_ixgbe83
> > librte_pmd_pcap 4
> > librte_pmd_ring 0
> > librte_pmd_virtio   21
> > librte_pmd_vmxnet3  21
> > librte_pmd_xenvirt  6
> > librte_port 6
> > librte_power3
> > librte_ring 2
> > librte_sched1
> 

[dpdk-dev] Why nothing since 1.8.0?

[Neil Horman]

On Fri, Jan 16, 2015 at 03:51:55PM +0100, Marc Sune wrote:
> 
> On 15/01/15 19:51, Neil Horman wrote:
> >On Thu, Jan 15, 2015 at 06:25:33PM +0100, Thomas Monjalon wrote:
> >>2015-01-15 08:06, Neil Horman:
> >>>On Thu, Jan 15, 2015 at 10:51:38AM +0100, Thomas Monjalon wrote:
> 2015-01-15 04:27, Ouyang, Changchun:
> >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zhang, Helin
> >>From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> >>>On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger wrote:
> Ok, so 1.8.0 came out almost a month ago and none of the patches
> that were deferred waiting for the release got merged since then.
> Last commit in git is the 1.8.0 release.
> 
> Where is the post-merge window bundle, where are the later commits?
> Lots of patches are sitting rotting in patchwork...
> >>>+1, I've had the same questions.
> >>>Neil
> >>+1, Some patch set might be ready for being merged.
> >+1,  the earlier some patches are merged into mainline, and the easier 
> >those
> >sequent patch sets can resolve their conflicts.
> +1, there are some patches which are properly reviewed
> 
> Reminder: sub-tree to manage specific part of DPDK can be open on request
> >>>Ok, I think what you're saying here is you're too busy to handle all the 
> >>>patches
> >>>comming in at the moment.  As such I'd like to propose a sub-tree 
> >>>encompassing
> >>>all the pmds in DPDK.  I would envision that including all the acutal 
> >>>pmd's in
> >>>the tree, as well as the infrastructure that is used to interface them to 
> >>>the
> >>>core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the patch 
> >>>pool
> >>>and send you pull requests.
> >>[snip]
> >>And that doesn't account for the ~500 patches that come in via pull
> >>request from the wireless subtree. Nor does it account for the merge
> >>window for net-next being 2 months instead of dpdk's 6 months.
> 
> Neil,
> 
> I don't want to hinder the discussion but: could you please point me out
> where this wireless subtree is?
> 
There is none for DPDK, I'm drawing a comparison here.  The DPDK is trying to
split out subtrees at a granularity of 1 tree per pmd, which I am aruging
against because a maintainer for a pmd doesn't need their own tree to push to.

Instead I'm proposing a large granularity of where all drivers (or drivers of a
certain type) are housed in the same tree, like net-next:
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/
or wireless:
https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/

where one tree maintainer relies on the review of many subject matter experts to
validate the patches that they merge.

I'm making the comparison to argue for workflow process, nothing more.  You
won't find any wireless pmds anywhere at the moment.
Neil

> Maybe I am too blind, but I cannot see it here:
> 
> http://dpdk.org/browse/
> 
> We are interested in acceleration for wireless NICs.
> 
> Marc
> 
> [snip]
> 

[dpdk-dev] [PATCH] eal / malloc : alignment parameter check failing due to changes in rte_is_power_of_2

[Thomas Monjalon]

2015-01-16 15:10, Declan Doherty:
> In commit 2fc8d6d the behaviour of function rte_is_power_of_2 was
> changed to not return true for 0. memzone_reserve_aligned_thread_unsafe
> and rte_malloc_socket both make the assumption that for align = 0
> !rte_is_power_of_2(align) will return false. This patch adds a check
> that align parameter is non-zero before doing the power of 2 check
> 
> Signed-off-by: Declan Doherty 
[...]
> - if (!rte_is_power_of_2(align)) {
> + if (align ? !rte_is_power_of_2(align) : 0) {
[...]
> - if (size == 0 || !rte_is_power_of_2(align))
> + if (size == 0 || align ? !rte_is_power_of_2(align) : 0)

I don't understand why you write "align ? !rte_is_power_of_2(align) : 0"
instead of the more readable "align && !rte_is_power_of_2(align)" ?

Pablo acked it so I guess there is something obvious I'm missing.

-- 
Thomas

[dpdk-dev] [PATCH] ethdev: fix missing parenthesis

[Thomas Monjalon]

2015-01-16 09:40, Wodkowski, PawelX:
> > Good catch!
> > Was introduced in commit 4bdefaade6d1 (VMDQ enhancements).
> > Note that quite often, when a patch contains too much things,
> > we miss this kind of bugs. That's a reason to well split patches.
> 
> What is most surprising I did not spotted this, neither  the compiler
> what I think it should. It was my IDE which pointed possible bug.
> 
> Are we using '-Wparentheses' switch? If not, we should consider
> to use this switch?

It's already included in -Wall which is set in WERROR_FLAGS.

-- 
Thomas

[dpdk-dev] [PATCH] librte_eal: Add fscanf return value test

[Thomas Monjalon]

> > The lack of result checking of fscanf function, brakes compilation for 
> > default
> > "-Werror=unused-result" flag.
> > 
> > Signed-off-by: Tomasz Kulasek 
> 
> Acked-by: Pablo de Lara 

Applied

Thanks
-- 
Thomas

[dpdk-dev] Why nothing since 1.8.0?

[Neil Horman]

On Thu, Jan 15, 2015 at 11:23:28PM +0100, Thomas Monjalon wrote:
> 2015-01-15 13:51, Neil Horman:
> > On Thu, Jan 15, 2015 at 06:25:33PM +0100, Thomas Monjalon wrote:
> > > 2015-01-15 08:06, Neil Horman:
> > > > Ok, I think what you're saying here is you're too busy to handle all 
> > > > the patches
> > > > comming in at the moment.  As such I'd like to propose a sub-tree 
> > > > encompassing
> > > > all the pmds in DPDK.  I would envision that including all the acutal 
> > > > pmd's in
> > > > the tree, as well as the infrastructure that is used to interface them 
> > > > to the
> > > > core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the 
> > > > patch pool
> > > > and send you pull requests.
> > > 
> > > The list of PMDs is increasing:
> > >   librte_pmd_af_packet
> > >   librte_pmd_bond
> > >   librte_pmd_e1000
> > >   librte_pmd_enic
> > >   librte_pmd_i40e
> > >   librte_pmd_ixgbe
> > >   librte_pmd_pcap
> > >   librte_pmd_ring
> > >   librte_pmd_virtio
> > >   librte_pmd_vmxnet3
> > >   librte_pmd_xenvirt
> > > There is already some sub-trees for bnx2x, fm10k and i40e:
> > >   http://dpdk.org/browse/
> > > 
> > Yes, and I've mentioned before that that is an absolutely silly way to 
> > break out
> > subtrees.  You have to find a balance of workload distribution and developer
> > convienience.
> 
> Intel requested fm10k and i40e sub-trees because there are many developments
> in progress. We want to experience this model.
> 
Ok, but thats not the point.  Just because a given pmd has lots of changes
doesn't mean it itself needs its own tree.  With the right separation of
responsibilities all the pmds can be managed from one tree more easily and with
less distractions to the developers doing the work for those libraries.

> > I also note that these are problematic because you're not merging anything
> > from them. Is it your intention to keep bnx2 and fm10k separate in 
> > perpituity?
> 
> No, I'll merge them on pull requests.
> Note that they are planned for version 2.0 but not available yet.
> 
Ok, good on the pull request, but I don't really see that happening.  According
to this:
http://git.dpdk.org/dev/roadmap#cycle
If we plan a 2.0 release for mid march, counting backwards, we should be at the
review period stage.  As of today in patchwork, I see 6 patches with I40e in the
title. Of those 3 have been acked, only one by someone who I think is likely a
subject matter expert on I40e.

Some of those patches have been sitting on the list since November 20th of last
year.

I think we're missing the point of a subtree.  Its created to both take some of
the load off of the upstream tree maintainer when the volume gets too high, and
it provides a location for developers to get bleeding edge code for a given
aspect of a project they might be interested in.  Neither of these things are
happening here.

> > If so, thats a real problem, because then we effectively just have several 
> > out
> > of tree drivers, and thats just unacceptible.
> 
> I don't understand what make you thinking that. They are -next tree, not out 
> of tree.
> 
If they are the -next tree, then I apologize, because it certainly doesn't seem
that way so far.  But if they are, so be it.  That still leaves the outstanding
question though of, why one tree per pmd?  As I noted in other notes, the roles
of tree maintainer and driver maintainer (or as I would refer to it, subject
matter expert, for clairity) are separate ones.  The former is focused on the
merging of patches and general SCM process, while the latter is focused on
reviewing code within their purview.  When done properly, a single tree
maintainer can simply rely on the ACKs of the SME's to gate the merging of code,
and both parties can do their jobs much more efficiently.

> > > > If you could set me up with a login to dpdk.org, I'd appreciate it.
> > > 
> > > It is preferred to have 1 sub-tree per module.
> > > What do you think of managing contributions for af_packet and/or virtio?
> > > It would make sense as virtio is a RedHat technology.
> > > Maybe it could include vhost lib and example.
> > > 
> > No, for reasons I've mentioned before.  If you take each pmd/library and 
> > create
> > a subtree for it, you've created the most fine grained control of subtrees 
> > you
> > could ask for, but you've created a nighmare of a burden on developers who 
> > want
> > to update any code, especially if they have patches that hit multiple trees.
> 
> It's not planned to have a sub-tree for each library.
> And some sub-trees can be closed when activity decrease.
> 
But that need not happen.  If you create a single sub-tree for all the PMD's, it
will have a long life, and developers will have a long lived canonical source
from which to get the latest pmd code, and will enjoy the benefits of more
rapidly merged/reviewed code, if we follow the dual role approach that I've been
advocating.

> > Look at some of the stats in the dpdk tree:
> > 
> > Library Comm

[dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine

[Olivier MATZ]

Hi Konstantin, Hi Jijiang,

On 01/15/2015 02:31 PM, Ananyev, Konstantin wrote:
> To be honest, there are so many mails around that subject, so I am already 
> lost :)
> Oliver, as I understand you are not happy with the test-pmd commands Frank is 
> proposing.
> Both syntax and semantics.
> Is that correct?
> If so, could you suggest something from your side?
> That would allow to configure test-pmd to behave in any of 4 possible ways we 
> discussed previously:
> http://dpdk.org/ml/archives/dev/2014-December/009213.html

I first wanted to send a mail to describe the current problem with
testpmd command line and the 2 solutions (Jijiang's and mine).
But, first, I think we need to fully clarify the checksum offload
API through examples as it will help to implement testpmd and do
the documentation. They are based on Jijiang's previous mail [1].

I will submit a patchset fixing the problems described below in
the coming days. If we agree on it, I'll submit another one for testpmd.

Let's use the following packet for all the examples below:
  out_eth / out_ip / out_udp / vxlan / in_eth / in_ip / in_tcp


The following cases are supposed to work on niantic and fortville:

case 1) calculate checksum of out_ip  (was case A in [1])

   mb->l2_len = len(out_eth)
   mb->l3_len = len(out_ip)
   mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CSUM
   set out_ip checksum to 0 in the packet

   supported on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM

case 2) calculate checksum of out_ip and out_udp

   mb->l2_len = len(out_eth)
   mb->l3_len = len(out_ip)
   mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CSUM | PKT_TX_UDP_CKSUM
   set out_ip checksum to 0 in the packet
   set out_udp checksum to pseudo header using rte_ipv4_phdr_cksum()

   supported on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM and
   DEV_TX_OFFLOAD_UDP_CKSUM

   *Problem 1*: The comment above PKT_TX_IPV4 says "Packet is IPv4
   without requiring IP checksum offload" [2], and the help of L4
   checksum and TSO says that it is required to set the PKT_TX_IPV4
   flag [3]. This is not coherent.

   We are back on the debate about the meaning of PKT_TX_IPV4 vs
   PKT_TX_IP_CSUM from [4]. This incoherency in comments are introduced
   by patch [5]. The question is "when an application should set
   this flag? for any IP packet that does not require IP checksum?".
   This would break many applications. I think a good definition would
   be:

   Packet is IPv4. This flag must be set when using any offload
   feature (TSO, L3 or L4 checksum) to tell the NIC that the packet
   is an IPv4 packet.

   That's why I added PKT_TX_IPV4 in the examples.

case 3) calculate checksum of in_ip

   mb->l2_len = len(out_eth + out_ip + out_udp + vxlan + in_eth)
   mb->l3_len = len(in_ip)
   mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CSUM
   set in_ip checksum to 0 in the packet

   This is similar to case 1), but l2_len is different.

   supported on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM

   Note that it can only work if outer L4 checksum is 0.

case 4) calculate checksum of in_ip and in_tcp  (was case B.2 in [1])

   mb->l2_len = len(out_eth + out_ip + out_udp + vxlan + in_eth)
   mb->l3_len = len(in_ip)
   mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CSUM | PKT_TX_TCP_CKSUM
   set in_ip checksum to 0 in the packet
   set in_tcp checksum to pseudo header using rte_ipv4_phdr_cksum()

   This is similar to case 2), but l2_len is different.

   supported on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM and
   DEV_TX_OFFLOAD_TCP_CKSUM

   Note that it can only work if outer L4 checksum is 0.

case 5) segment inner TCP

   mb->l2_len = len(out_eth + out_ip + out_udp + vxlan + in_eth)
   mb->l3_len = len(in_ip)
   mb->l4_len = len(in_tcp)
   mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CKSUM | PKT_TX_TCP_CKSUM |
 PKT_TX_TCP_SEG;
   set in_ip checksum to 0 in the packet
   set in_tcp checksum to pseudo header without including the IP
 payload length using rte_ipv4_phdr_cksum()

   supported on hardware advertising DEV_TX_OFFLOAD_TCP_TSO.

   Note that it can only work if outer L4 checksum is 0.

   Problem 1 is also visible here.


The following cases are supposed to *work on fortville*:

case 6) calculate checksum of out_ip, in_ip, in_tcp (was case C in [1])

   mb->outer_l2_len = len(out_eth)
   mb->outer_l3_len = len(out_ip)
   mb->l2_len = len(out_udp + vxlan + in_eth)
   mb->l3_len = len(in_ip)
   mb->ol_flags |= PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IP_CKSUM  | \
 PKT_TX_IP_CKSUM |  PKT_TX_TCP_CKSUM;
   set out_ip checksum to 0 in the packet
   set in_ip checksum to 0 in the packet
   set in_tcp checksum to pseudo header using rte_ipv4_phdr_cksum()

   supported on hardware advertising DEV_TX_OFFLOAD_IPV4_CKSUM,
   DEV_TX_OFFLOAD_UDP_CKSUM and DEV_TX_OFFLOAD_OUTER_IPV4_CKSUM

   *Problem 2*: it is not written in the API comments that out_ip
   checksum field should be set to 0 by the application. They should
   be enhanced.

   *Problem 3*: without using the word "fortville", i

[dpdk-dev] [PATCH 2/2] app/testpmd:csum fwd engine change

[Olivier MATZ]

Hi Jijiang,

On 01/16/2015 03:31 AM, Jijiang Liu wrote:
> change the palce of setting UDP tunneling packet offload flag.

typo here

> 
> Signed-off-by: Jijiang Liu 
> ---
>  app/test-pmd/csumonly.c |7 ---
>  1 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> index 41711fd..57afdfc 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -256,9 +256,6 @@ process_outer_cksums(void *outer_l3_hdr, uint16_t 
> outer_ethertype,
>   struct udp_hdr *udp_hdr;
>   uint64_t ol_flags = 0;
>  
> - if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
> - ol_flags |= PKT_TX_UDP_TUNNEL_PKT;
> -
>   if (outer_ethertype == _htons(ETHER_TYPE_IPv4)) {
>   ipv4_hdr->hdr_checksum = 0;
>  
> @@ -392,6 +389,10 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
>   tunnel = 1;
>  
>   if (tunnel == 1) {
> + if (testpmd_ol_flags &
> + TESTPMD_TX_OFFLOAD_VXLAN_CKSUM)
> + ol_flags |= PKT_TX_UDP_TUNNEL_PKT;
> +
>   outer_ethertype = ethertype;
>   outer_l2_len = l2_len;
>   outer_l3_len = l3_len;
> 

Can you explain why you are moving this code?

Regards,
Olivier

[dpdk-dev] Does I210 NIC support Flow director filters?

[Bruce Richardson]

On Fri, Jan 16, 2015 at 11:42:42AM -0500, Kamraan Nasim wrote:
> Hi Bruce,
> Perhaps this can be worked around by setting  rx_drop_en in the
> rte_eth_rxconf  and
> using small values for number of rx descripters so that the NIC drops when
> it is out of RX descriptors for that queue?
> 
> As long as NIC can still provide q_ipackets/q_errors then this might be
> faster than doing a RX in software and drop.
> 
> --Kam

Yes, so long as packets dropped for that queue are counted against that queue,
then yes.

/Bruce

> 
> On Fri, Jan 16, 2015 at 5:56 AM, Bruce Richardson <
> bruce.richardson at intel.com> wrote:
> 
> > On Thu, Jan 15, 2015 at 08:06:52PM -0500, Kamraan Nasim wrote:
> > > >>> update the RSS RETA table so that traffic doesn't get sent
> > > >> to that queue via RSS. Is that what you are asking?
> > >
> > > Thanks Bruce, that's exactly it.  Basically each filter will forward
> > > traffic to a unique RSS queue which can allow me to calculate filter
> > match
> > > statistics for that queue(or filter). At that point I would like to drop
> > > the filtered packet. Is there any way to drop the filtered packet in the
> > > RSS queue without doing a rte_eth_rx_burst() and dropping it then?
> > >
> > > --Kam
> > >
> > I don't believe there is any other way to drop them from the queue other
> > than
> > RX and drop. It's not the most efficient way to do so (since you have to
> > allocate,
> > fill and free an mbuf), but it's the only way that an app can do so without
> > adding new functions to the driver(s).
> >
> > /Bruce
> >

[dpdk-dev] [PATCH 1/2] i40e:support i40e TSO

[Olivier MATZ]

Hi Jijiang,

On 01/16/2015 03:31 AM, Jijiang Liu wrote:
> This patch enables i40e TSO feature for both non-tunneling packet and UDP 
> tunneling packet.
> 
> Signed-off-by: Jijiang Liu 
> Signed-off-by: Miroslaw Walukiewicz 
> ---
>  lib/librte_pmd_i40e/i40e_ethdev.c |3 +-
>  lib/librte_pmd_i40e/i40e_rxtx.c   |  111 +++-
>  lib/librte_pmd_i40e/i40e_rxtx.h   |   13 
>  3 files changed, 98 insertions(+), 29 deletions(-)

At first sight, the patch looks good, but I think one information
is missing: how it was validated?

Did you use csumonly? As we have a pending discussion on how to
rework it, I think I should include this test case in the
specification.

A description of which mbufs fields should be filled in case of
tunneling packet would be useful for people willing to use this
API. Does it match the case 8) of
http://dpdk.org/ml/archives/dev/2015-January/011127.html ?

Regards,
Olivier

[dpdk-dev] Why nothing since 1.8.0?

[Thomas Monjalon]

2015-01-16 12:20, Neil Horman:
> On Thu, Jan 15, 2015 at 11:23:28PM +0100, Thomas Monjalon wrote:
> > 2015-01-15 13:51, Neil Horman:
> > > On Thu, Jan 15, 2015 at 06:25:33PM +0100, Thomas Monjalon wrote:
> > > > 2015-01-15 08:06, Neil Horman:
> > > > > Ok, I think what you're saying here is you're too busy to handle all 
> > > > > the patches
> > > > > comming in at the moment.  As such I'd like to propose a sub-tree 
> > > > > encompassing
> > > > > all the pmds in DPDK.  I would envision that including all the acutal 
> > > > > pmd's in
> > > > > the tree, as well as the infrastructure that is used to interface 
> > > > > them to the
> > > > > core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the 
> > > > > patch pool
> > > > > and send you pull requests.
> > > > 
> > > > The list of PMDs is increasing:
> > > > librte_pmd_af_packet
> > > > librte_pmd_bond
> > > > librte_pmd_e1000
> > > > librte_pmd_enic
> > > > librte_pmd_i40e
> > > > librte_pmd_ixgbe
> > > > librte_pmd_pcap
> > > > librte_pmd_ring
> > > > librte_pmd_virtio
> > > > librte_pmd_vmxnet3
> > > > librte_pmd_xenvirt
> > > > There is already some sub-trees for bnx2x, fm10k and i40e:
> > > > http://dpdk.org/browse/
> > > > 
> > > Yes, and I've mentioned before that that is an absolutely silly way to 
> > > break out
> > > subtrees.  You have to find a balance of workload distribution and 
> > > developer
> > > convienience.
> > 
> > Intel requested fm10k and i40e sub-trees because there are many developments
> > in progress. We want to experience this model.
> > 
> Ok, but thats not the point.  Just because a given pmd has lots of changes
> doesn't mean it itself needs its own tree.  With the right separation of
> responsibilities all the pmds can be managed from one tree more easily and 
> with
> less distractions to the developers doing the work for those libraries.
> 
> > > I also note that these are problematic because you're not merging anything
> > > from them. Is it your intention to keep bnx2 and fm10k separate in 
> > > perpituity?
> > 
> > No, I'll merge them on pull requests.
> > Note that they are planned for version 2.0 but not available yet.
> > 
> Ok, good on the pull request, but I don't really see that happening.  
> According
> to this:
> http://git.dpdk.org/dev/roadmap#cycle
> If we plan a 2.0 release for mid march, counting backwards, we should be at 
> the
> review period stage.

?? We are January 16 today, so according to http://dpdk.org/dev/roadmap#dates,
we are not yet in review period.

> As of today in patchwork, I see 6 patches with I40e in the
> title. Of those 3 have been acked, only one by someone who I think is likely a
> subject matter expert on I40e.
> 
> Some of those patches have been sitting on the list since November 20th of 
> last
> year.
> 
> I think we're missing the point of a subtree.  Its created to both take some 
> of
> the load off of the upstream tree maintainer when the volume gets too high, 
> and
> it provides a location for developers to get bleeding edge code for a given
> aspect of a project they might be interested in.  Neither of these things are
> happening here.

Please let the things happen.
If our experience shows that this subtree is not needed, it is possible to 
close it.
I feel it can be convenient for first releases of new drivers.

> > 
> > > If so, thats a real problem, because then we effectively just have 
> > > several out
> > > of tree drivers, and thats just unacceptible.
> > 
> > I don't understand what make you thinking that. They are -next tree, not 
> > out of tree.
> > 
> If they are the -next tree, then I apologize, because it certainly doesn't 
> seem
> that way so far.  But if they are, so be it.  That still leaves the 
> outstanding
> question though of, why one tree per pmd?  As I noted in other notes, the 
> roles
> of tree maintainer and driver maintainer (or as I would refer to it, subject
> matter expert, for clairity) are separate ones.  The former is focused on the
> merging of patches and general SCM process, while the latter is focused on
> reviewing code within their purview.  When done properly, a single tree
> maintainer can simply rely on the ACKs of the SME's to gate the merging of 
> code,
> and both parties can do their jobs much more efficiently.
> 
> > > > > If you could set me up with a login to dpdk.org, I'd appreciate it.
> > > > 
> > > > It is preferred to have 1 sub-tree per module.
> > > > What do you think of managing contributions for af_packet and/or virtio?
> > > > It would make sense as virtio is a RedHat technology.
> > > > Maybe it could include vhost lib and example.
> > > > 
> > > No, for reasons I've mentioned before.  If you take each pmd/library and 
> > > create
> > > a subtree for it, you've created the most fine grained control of 
> > > subtrees you
> > > could ask for, but you've created a nighmare of a burden on deve

[dpdk-dev] Why nothing since 1.8.0?

[Matthew Hall]

On Fri, Jan 16, 2015 at 07:18:19PM +0100, Thomas Monjalon wrote:
> I'd like to try solving the review challenge first and see what else can be 
> done after that. Step by step.

FWIW, I know the kernel guys seem to really love it, but not everybody else 
has much fun trying to do the reviews reading huge patch emails. I lose a lot 
of context trying to stare at them in mutt 80x25 console etc. It would be nice 
if we could have a visual interface with syntax highlighting and comment 
capabilities, that's easier to read through quickly and clearly, like 
ReviewBoard, GitHub Pull Request UI, etc. If it had email integration to reply 
to the patch threads that'd be great too.

Also if we had some branches available where conceptually related changes are 
grouped, somebody could check out the branch with some feature they wanted to 
try, get all the related patches, integrate with their app of choice, and see 
if the app works successfully with the new feature.

Some of these things like DPDK, it isn't obvious how the feature will help or 
hurt, until you write some code against it and/or benchmark it first, because 
some of these features are kind of complicated.

Another thing... if we had some kind of wiki page, where some of the backend 
coders could mark themselves as maintainers of all the different features they 
work on, and more client-side network stack guys like me could express 
interest in certain features, we could connect the two sides so any given guy 
knows who can review his bugfix he found, or try out his new patchset to see 
if it works well in an app.

Matthew.

[dpdk-dev] Why nothing since 1.8.0?

[Neil Horman]

On Fri, Jan 16, 2015 at 07:18:19PM +0100, Thomas Monjalon wrote:
> 2015-01-16 12:20, Neil Horman:
> > On Thu, Jan 15, 2015 at 11:23:28PM +0100, Thomas Monjalon wrote:
> > > 2015-01-15 13:51, Neil Horman:
> > > > On Thu, Jan 15, 2015 at 06:25:33PM +0100, Thomas Monjalon wrote:
> > > > > 2015-01-15 08:06, Neil Horman:
> > > > > > Ok, I think what you're saying here is you're too busy to handle 
> > > > > > all the patches
> > > > > > comming in at the moment.  As such I'd like to propose a sub-tree 
> > > > > > encompassing
> > > > > > all the pmds in DPDK.  I would envision that including all the 
> > > > > > acutal pmd's in
> > > > > > the tree, as well as the infrastructure that is used to interface 
> > > > > > them to the
> > > > > > core (i.e. the ethdev/rte_ether library).  I'll gladly maintain the 
> > > > > > patch pool
> > > > > > and send you pull requests.
> > > > > 
> > > > > The list of PMDs is increasing:
> > > > >   librte_pmd_af_packet
> > > > >   librte_pmd_bond
> > > > >   librte_pmd_e1000
> > > > >   librte_pmd_enic
> > > > >   librte_pmd_i40e
> > > > >   librte_pmd_ixgbe
> > > > >   librte_pmd_pcap
> > > > >   librte_pmd_ring
> > > > >   librte_pmd_virtio
> > > > >   librte_pmd_vmxnet3
> > > > >   librte_pmd_xenvirt
> > > > > There is already some sub-trees for bnx2x, fm10k and i40e:
> > > > >   http://dpdk.org/browse/
> > > > > 
> > > > Yes, and I've mentioned before that that is an absolutely silly way to 
> > > > break out
> > > > subtrees.  You have to find a balance of workload distribution and 
> > > > developer
> > > > convienience.
> > > 
> > > Intel requested fm10k and i40e sub-trees because there are many 
> > > developments
> > > in progress. We want to experience this model.
> > > 
> > Ok, but thats not the point.  Just because a given pmd has lots of changes
> > doesn't mean it itself needs its own tree.  With the right separation of
> > responsibilities all the pmds can be managed from one tree more easily and 
> > with
> > less distractions to the developers doing the work for those libraries.
> > 
> > > > I also note that these are problematic because you're not merging 
> > > > anything
> > > > from them. Is it your intention to keep bnx2 and fm10k separate in 
> > > > perpituity?
> > > 
> > > No, I'll merge them on pull requests.
> > > Note that they are planned for version 2.0 but not available yet.
> > > 
> > Ok, good on the pull request, but I don't really see that happening.  
> > According
> > to this:
> > http://git.dpdk.org/dev/roadmap#cycle
> > If we plan a 2.0 release for mid march, counting backwards, we should be at 
> > the
> > review period stage.
> 
> ?? We are January 16 today, so according to http://dpdk.org/dev/roadmap#dates,
> we are not yet in review period.
> 
Ok, you still have two weeks, but my point still stands.  At least for I40e,
several of the outstanding patches have been on the list since November of last
year, and have been Acked. If we're separating the trees out, why are we waiting
so long to merge them, shouldn't that have been done by the subtree maintainer
by now?  The merge window is called a merge window for a reason, its the time
that code gets merged.


> > As of today in patchwork, I see 6 patches with I40e in the
> > title. Of those 3 have been acked, only one by someone who I think is 
> > likely a
> > subject matter expert on I40e.
> > 
> > Some of those patches have been sitting on the list since November 20th of 
> > last
> > year.
> > 
> > I think we're missing the point of a subtree.  Its created to both take 
> > some of
> > the load off of the upstream tree maintainer when the volume gets too high, 
> > and
> > it provides a location for developers to get bleeding edge code for a given
> > aspect of a project they might be interested in.  Neither of these things 
> > are
> > happening here.
> 
> Please let the things happen.
> If our experience shows that this subtree is not needed, it is possible to 
> close it.
> I feel it can be convenient for first releases of new drivers.
> 
I'm not disagreeing, I'm advocating for the fact that theres no need to open and
close trees as it becomes (in)convienient.  At least not at such a fine
granularity.  A single subtree for all the pmds with one tree maintainer and
several subject matter experts to do reviews has proven to be highly efficient
and flexible in many other projects (most notably the linux kernel).

> > > 
> > > > If so, thats a real problem, because then we effectively just have 
> > > > several out
> > > > of tree drivers, and thats just unacceptible.
> > > 
> > > I don't understand what make you thinking that. They are -next tree, not 
> > > out of tree.
> > > 
> > If they are the -next tree, then I apologize, because it certainly doesn't 
> > seem
> > that way so far.  But if they are, so be it.  That still leaves the 
> > outstanding
> > question though of, why one tree per pmd?  As I noted in other notes, the 
> > ro

[dpdk-dev] Why nothing since 1.8.0?

[Neil Horman]

On Fri, Jan 16, 2015 at 10:58:52AM -0800, Matthew Hall wrote:
> On Fri, Jan 16, 2015 at 07:18:19PM +0100, Thomas Monjalon wrote:
> > I'd like to try solving the review challenge first and see what else can be 
> > done after that. Step by step.
> 
> FWIW, I know the kernel guys seem to really love it, but not everybody else 
> has much fun trying to do the reviews reading huge patch emails. I lose a lot 
> of context trying to stare at them in mutt 80x25 console etc.
Well, ok, then don't use mutt, no one mandates it.  You can setup
outlook/thunderbird/evolution/MTA of choice to format email properly for lkml
pretty easily.

> It would be nice 
> if we could have a visual interface with syntax highlighting and comment 
> capabilities, that's easier to read through quickly and clearly, like 
> ReviewBoard, GitHub Pull Request UI, etc. If it had email integration to 
> reply 
> to the patch threads that'd be great too.
> 
Like Gerrit:
https://code.google.com/p/gerrit/

Its easy enough to setup your own instance and point it at your own tree for
review purposes.

> Also if we had some branches available where conceptually related changes are 
> grouped, somebody could check out the branch with some feature they wanted to 
> try, get all the related patches, integrate with their app of choice, and see 
> if the app works successfully with the new feature.
> 
That would be the master branch of a subtree, if the granularity was correct.

> Some of these things like DPDK, it isn't obvious how the feature will help or 
> hurt, until you write some code against it and/or benchmark it first, because 
> some of these features are kind of complicated.
> 
> Another thing... if we had some kind of wiki page, where some of the backend 
> coders could mark themselves as maintainers of all the different features 
> they 
> work on, and more client-side network stack guys like me could express 
> interest in certain features, we could connect the two sides so any given guy 
> knows who can review his bugfix he found, or try out his new patchset to see 
> if it works well in an app.
> 
Thats what the MAINTAINERS file and --subject-prefix options in git-send-email
are commonly used for

Neil

[dpdk-dev] Why nothing since 1.8.0?

[Matthew Hall]

On Fri, Jan 16, 2015 at 03:00:57PM -0500, Neil Horman wrote:
> Like Gerrit:
> https://code.google.com/p/gerrit/

Maybe we could work on setting up a community copy? I'd prefer if we could 
avoid n=1 and make our community as strong as possible.

Matthew.

[dpdk-dev] [DISCUSSION] : ERROR while compiling dpdk-1.7 on ubuntu14.04

[Wiles, Keith]

On 1/16/15, 7:43 AM, "Srinivasreddy R"  wrote:

>sorry typo i am using Ubuntu 14.04.1 LTS .
>
>On Fri, Jan 16, 2015 at 7:06 PM, Srinivasreddy R <
>srinivasreddy4390 at gmail.com> wrote:
>
>> hi,
>> Getting error while compiling dpdk on ubuntu10.04.
>>
>>
>> export RTE_SDK=$(pwd)
>> export RTE_TARGET="x86_64-ivshmem-linuxapp-gcc"
>>
>> make CONFIG_RTE_BUILD_COMBINE_LIBS=y CONFIG_RTE_BUILD_SHARED_LIB=y
>>install
>> T="$RTE_TARGET"

Check to make sure you are linking in the math lib -lm you can add a V=1
to the command line and see the linker lines.



>>
>>
>> == Build app/test-acl
>>   CC main.o
>>   LD testacl
>> /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
>> undefined reference to `log2'
>> /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
>> undefined reference to `ceil'
>> /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
>> undefined reference to `pow'
>> /home/DPDK/dpdk-1.7.1/x86_64-ivshmem-linuxapp-gcc/lib/libintel_dpdk.so:
>> undefined reference to `round'
>> collect2: error: ld returned 1 exit status
>> make[5]: *** [testacl] Error 1
>> make[4]: *** [test-acl] Error 2
>> make[3]: *** [app] Error 2
>> make[2]: *** [all] Error 2
>> make[1]: *** [x86_64-ivshmem-linuxapp-gcc_install] Error 2
>> make: *** [install] Error 2
>>
>> Following installation procedure at link :
>>
>> 
>>https://github.com/01org/dpdk-ovs/blob/development/docs/01_Installation.m
>>d#dpdk
>>
>> 
>> thanks
>> srinivas.
>>

[dpdk-dev] Why nothing since 1.8.0?

[Neil Horman]

On Fri, Jan 16, 2015 at 12:38:48PM -0800, Matthew Hall wrote:
> On Fri, Jan 16, 2015 at 03:00:57PM -0500, Neil Horman wrote:
> > Like Gerrit:
> > https://code.google.com/p/gerrit/
> 
> Maybe we could work on setting up a community copy? I'd prefer if we could 
> avoid n=1 and make our community as strong as possible.
> 
Sure, Its a bit orthogonal to this conversation, but I think its a fine idea to
have if it aids in general reviewing.  Thomas can it be setup on dpdk.org?

Neil
> Matthew.
> 

[dpdk-dev] Why nothing since 1.8.0?

[Matthew Hall]

On Fri, Jan 16, 2015 at 04:14:38PM -0500, Neil Horman wrote:
> Sure, Its a bit orthogonal to this conversation, but I think its a fine idea 
> to
> have if it aids in general reviewing.  Thomas can it be setup on dpdk.org?
> 
> Neil

Admittedly I'm not a PMD expert to comment on all the specifics of what you 
said about subtrees. But I do like to think out of the box and look at the big 
picture of what people have to say in the various threads. Your points about 
making the community strong seemed important, so I thought about the various 
subproblems to solve the whole topic:

1) some logical subtrees as you advised,

2) a clarification of who runs the subtrees and who does the -next mergeups,

3) feature branches or some other way for end users to validate new related 
functionality all together as a kind of integration testing,

4) a MAINTAINERS file, and maybe a TESTERS file, or tester / end-user entries 
in MAINTAINERS,

5) a really good friend way to review the new code like Gerrit as you advised

I think if we attack all of these we should be in good shape as the community 
continues to grow and mature.

Matthew.