[dpdk-dev] [PATCH v5 resend 07/12] virtio: resolve for control queue

[Steffen Bauch]

On 10/12/2015 10:39 AM, Yuanhan Liu wrote:
> Hi,
>
> I just recognized that this dead loop is the same one that I have
> experienced (see
> http://dpdk.org/ml/archives/dev/2015-October/024737.html for
> reference). Just applying the changes in this patch (only 07/12)
> will not fix the dead loop at least in my setup.
> Try to enable CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT, and dump more log?
I enabled the additional debug output. First try was without any 
additional changes in master, but it blocked also. Second try was with

[dpdk-dev] [PATCH v6 06/13] virtio: read virtio_net_config correctly

applied, but same result.

If you want to recreate my setup, just follow instructions in

http://dpdk.org/ml/archives/dev/2015-October/024737.html


vagrant at vagrant-ubuntu-vivid-64:~/dpdk$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git checkout -- ..." to discard changes in working directory)

 modified:   config/defconfig_x86_64-native-linuxapp-gcc

..

vagrant at vagrant-ubuntu-vivid-64:~/dpdk/x86_64-native-linuxapp-gcc/app$ 
sudo ./testpmd -b :00:03.0 -c 3 -n 1 -- -i
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 2 lcore(s)
EAL: VFIO modules not all loaded, skip VFIO support...
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7f2a3a80 (size = 0x40)
EAL: Ask a virtual area of 0xe00 bytes
EAL: Virtual area found at 0x7f2a2c60 (size = 0xe00)
EAL: Ask a virtual area of 0x30c0 bytes
EAL: Virtual area found at 0x7f29fb80 (size = 0x30c0)
EAL: Ask a virtual area of 0x40 bytes
EAL: Virtual area found at 0x7f29fb20 (size = 0x40)
EAL: Ask a virtual area of 0xa0 bytes
EAL: Virtual area found at 0x7f29fa60 (size = 0xa0)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f29fa20 (size = 0x20)
EAL: Requesting 512 pages of size 2MB from socket 0
EAL: TSC frequency is ~2198491 KHz
EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using 
unreliable clock cycles !
EAL: Master lcore 0 is ready (tid=3c9938c0;cpuset=[0])
EAL: lcore 1 is ready (tid=fa1ff700;cpuset=[1])
EAL: PCI device :00:03.0 on NUMA socket -1
EAL:   probe driver: 1af4:1000 rte_virtio_pmd
EAL:   Device is blacklisted, not initializing
EAL: PCI device :00:08.0 on NUMA socket -1
EAL:   probe driver: 1af4:1000 rte_virtio_pmd
PMD: parse_sysfs_value(): parse_sysfs_value(): cannot open sysfs value 
/sys/bus/pci/devices/:00:08.0/uio/uio0/portio/port0/size
PMD: virtio_resource_init_by_uio(): virtio_resource_init_by_uio(): 
cannot parse size
PMD: virtio_resource_init_by_ioports(): PCI Port IO found start=0xd040 
with size=0x20
PMD: virtio_negotiate_features(): guest_features before negotiate = cf8020
PMD: virtio_negotiate_features(): host_features before negotiate = 410fdda3
PMD: virtio_negotiate_features(): features after negotiate = f8020
PMD: eth_virtio_dev_init(): PORT MAC: 08:00:27:CC:DE:CD
PMD: eth_virtio_dev_init(): VIRTIO_NET_F_MQ is not supported
PMD: virtio_dev_cq_queue_setup():  >>
PMD: virtio_dev_queue_setup(): selecting queue: 2
PMD: virtio_dev_queue_setup(): vq_size: 16 nb_desc:0
PMD: virtio_dev_queue_setup(): vring_size: 4228, rounded_vring_size: 8192
PMD: virtio_dev_queue_setup(): vq->vq_ring_mem:  0x67b54000
PMD: virtio_dev_queue_setup(): vq->vq_ring_virt_mem: 0x7f29fb354000
PMD: eth_virtio_dev_init(): config->max_virtqueue_pairs=1
PMD: eth_virtio_dev_init(): config->status=1
PMD: eth_virtio_dev_init(): PORT MAC: 08:00:27:CC:DE:CD
PMD: eth_virtio_dev_init(): hw->max_rx_queues=1 hw->max_tx_queues=1
PMD: eth_virtio_dev_init(): port 0 vendorID=0x1af4 deviceID=0x1000
PMD: virtio_dev_vring_start():  >>
EAL: PCI device :00:09.0 on NUMA socket -1
EAL:   probe driver: 1af4:1000 rte_virtio_pmd
PMD: parse_sysfs_value(): parse_sysfs_value(): cannot open sysfs value 
/sys/bus/pci/devices/:00:09.0/uio/uio1/portio/port0/size
PMD: virtio_resource_init_by_uio(): virtio_resource_init_by_uio(): 
cannot parse size
PMD: virtio_resource_init_by_ioports(): PCI Port IO found start=0xd060 
with size=0x20
PMD: virtio_negotiate_features(): guest_features before negotiate = cf8020
PMD: virtio_negotiate_features(): host_features before negotiate = 410fdda3
PMD: virtio_negotiate_features(): features after negotiate = f8020
PMD: eth_virtio_dev_init(): PORT MAC: 08:00:27:07:D3:F5
PMD: eth_virtio_dev_init(): VIRTIO_NET_F_MQ is not supported
PMD: virtio_dev_cq_queue_setup():  >>
PMD: virtio_dev_queue_setup(): selecting queue: 2
PMD: virtio_dev_queue_setup(): vq_size: 16 nb_desc:0
PMD: virtio_dev_queue_setup(): vring_size: 4228, rounded_vring_size: 8192
PMD: virtio_dev_queue_setup(): vq->vq_ring_mem:  0x67b5
PMD: virtio_dev_queue_setup(): 

[dpdk-dev] Segmentation fault when bonding ports on Mellanox ConnectX-3

[Jesper Wramberg]

Hi again,

The patches worked great and the DPDK bonding API functions with the
ConnectX-3 now.. yay :-)

I have run into some new trouble however and since its related I figured I
would ask here if anyone could help. I am using SR-IOV to create a
dual-port VF. When trying to bond the ports on this VF it seems that DPDK
cannot set the mac address on the slaves. As a result, I am unable to
receive data on the bonded port. As a workaround, I can set the mac address
on the two VF ports manually in Linux using "ip link set  vf
0 mac ..." after which I can start DPDK and receive data on the bonded port
as wanted.

Is there a way to allow DPDK to change the mac address so I avoid the
workaround ? I have done some searching but couldn't find anything.

Regards,
Jesper Wramberg



2015-10-09 0:29 GMT+02:00 Olga Shern :

> For the sake of clarity, I assume you mean the patches about:
>
> "eal: new interrupt handler type"
>
> "mlx4: handle interrupts"
>
> *[Olga ] Yes, you are right *
>
>
>
> Best Regards,
>
> Olga
>
>
>
> 2015-10-08 17:36 GMT+02:00 Olga Shern :
>
>
>
>
>
> Hi Jesper,
>
>
>
> Bonding pmd is not supported with dpdk 2.1 on Mellanox nic
>
> We just sent patches to support async link events. Without these patches
> it will  not work.
>
>
>
> Best Regards
>
> Olga
>
> Sent from Samsung Mobile.
>
>
>
>  Original message 
>
> From: Jesper Wramberg
>
> Date:08/10/2015 4:25 PM (GMT+00:00)
>
> To: dev at dpdk.org
>
> Subject: [dpdk-dev] Segmentation fault when bonding ports on Mellanox
> ConnectX-3
>
>
>
> Hi all,
>
> I was wondering if anyone has any experience with the ConnectX-3 card from
> Mellanox ? I have a server with such a card I can't seem to get link
> bonding to work.
>
> I've installed the necessary kernel modules, etc. and the card works as
> expected when testing it using e.g. the layer 2 forwarding example. If i
> try to run the bond example, however, I get a segmentation fault when the
> "rte_eth_bond_slave_add" function is called. Originally I wanted to bond
> the ports using the EAL cmd line option but the card only has one pci
> address :(
>
> Does anyone have any idea what could be causing this behavior ?
> I am running fw version 2.30.x which I have considered upgrading. Besides
> this I have been wondering if I have to do anything in Linux since the PMD
> uses the Linux drivers for control. I haven't been able to find any
> information on it though.
>
> Regards,
> Jesper Wramberg
>
>
>

[dpdk-dev] [PATCH 2/2] igb: fix VF statistic wraparound handling macro

[Harry van Haaren]

Fix a misinterpreatation of VF statistic macro in e1000/igb.

Signed-off-by: Harry van Haaren 
---
 drivers/net/e1000/igb_ethdev.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 848ef6e..e4911fc 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -246,11 +246,10 @@ static void eth_igb_configure_msix_intr(struct 
rte_eth_dev *dev);
 #define UPDATE_VF_STAT(reg, last, cur)\
 { \
u32 latest = E1000_READ_REG(hw, reg); \
-   cur += latest - last; \
+   cur += (latest-last) & UINT_MAX;  \
last = latest;\
 }

-
 #define IGB_FC_PAUSE_TIME 0x0680
 #define IGB_LINK_UPDATE_CHECK_TIMEOUT  90  /* 9s */
 #define IGB_LINK_UPDATE_CHECK_INTERVAL 100 /* ms */
-- 
1.9.1

[dpdk-dev] [PATCH 1/2] ixgbe: fix VF statistic wraparound handling macro

[Harry van Haaren]

Fix a misinterpretation of VF stats in ixgbe

Signed-off-by: Harry van Haaren 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index ec2918c..86dcd87 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -329,10 +329,10 @@ static int ixgbe_timesync_read_tx_timestamp(struct 
rte_eth_dev *dev,
 /*
  * Define VF Stats MACRO for Non "cleared on read" register
  */
-#define UPDATE_VF_STAT(reg, last, cur) \
+#define UPDATE_VF_STAT(reg, last, cur)  \
 {   \
uint32_t latest = IXGBE_READ_REG(hw, reg);  \
-   cur += latest - last;   \
+   cur += (latest-last) & UINT_MAX;\
last = latest;  \
 }

-- 
1.9.1

[dpdk-dev] [PATCH 0/2] fix vf statistic wraparound handling in macro

[Harry van Haaren]

The following two patches fix a misinterpretation of the cyclic
counters of igb and ixgbe VF. When the 32bit value wraps around,
the code now handles the wrapped new value appropriatly.

v2:
- Reimplemented with Alex's suggested fix for off-by-one

v1:
- Initial implementation

Harry van Haaren (2):
  ixgbe: fix VF statistic wraparound handling macro
  igb: fix VF statistic wraparound handling macro

 drivers/net/e1000/igb_ethdev.c   | 3 +--
 drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)

-- 
1.9.1

[dpdk-dev] Proposals from project governance meeting at DPDK Userspace (was Notes from ...)

[Dave Neary]

Hi,

To explicitly call out the proposals and action items from the meeting:

- Legal entity proposal:
   - PROPOSAL: Chris proposes moving DPDK to Linux Foundation, with low
overhead option
   - Minimal governance, event, marketing budget
   - Legal governance around project name, trademark

- Project leadership proposal (roadmap, scope)
   - ACTION: Venky to write a proposal for broadening scope as a patch
to the website
   - PROPOSAL: Thomas proposes several smaller projects, rather than one
umbrella project as scope broadens
   - ACTION: Jim proposed documenting current decision process, and
improving on it - documenting it will help make it better.
   - ACTION: Tim proposed to resurface his TSC proposal and drive it to
agreement and action
   - Proposed criteria which should be met by any technical governance
model:
1. Everyone has a voice
2. Some voices carry more weight than others, based on technical
seniority and participation in the community
3. Decisions should be time bound - after community debate, decision
should converge quickly one way or the other to give clarity

- Day to day patch review:
   - PROPOSAL: Thomas: Create hierarchical review process with
maintainers responsible for sub-trees (to be housed in DPDK Git)
   - ACTION: (without owner?) Subtrees and maintainers to be identified,
-next, crypto and (drivers, IIRC?) to be first trees
   - PROPOSAL: Thomas to identify replacement maintainers short-term
when he is unable to do it (vacation, sickness, etc)

- Stable patch maintenance
   - PROPOSAL: Maintain one release per year as a long term release,
with point releases being made regularly (based on patch volume), with
branches maintained for 2 years (2 stable branches + 1 devel branch
active at all times).

In addition to Thomas's notes, does this cover all of the conclusions
that came out of the meeting?

Thanks,
Dave.

On 10/11/2015 01:36 AM, Dave Neary wrote:
> Hi everyone,
> 
> I took some notes from a discussion we had at the end of DPDK Userspace
> in Dublin, concerning the growth and project structure for DPDK. If I
> missed anyone's name, I apologise - there were many active contributors,
> including most prominently Venky, Jim St Leger, Bruce Richardson,
> Stephen Hemminger, Chris Wright, myself, Keith Wiles, Cristian
> Dumitrescu, Tim O'Driscoll, Thomas Monjalon, and (until he had to leave)
> Vincent Jardin. There were a few others from Intel, ARM, and others, but
> I didn't get all the names during the discussion. If you see a comment
> you made and would like attribution, reply - especially if it doesn't
> quite match your view.
> 
> The discussion was wide ranging and we didn't quite stay on one topic
> until we reached a conclusion, so some of these notes are not in strict
> time order.
> 
> These are a mixture of notes and proposals for the project coming out of
> the meeting - comments are welcome, all proposals are up for discussion,
> and nothing has been decided on the basis of this meeting. However, all
> present expressed agreement that there are issues we need to address in
> the near future.
> 
> Apologies for the non-linear note taking, for those who were not there I
> hope they're useful.
> 
> Thanks,
> Dave.
> 
> 
> 
> Topic 1: Legal entity
> =
> 
> Do we need/want a legal entity independent of a commercial vendor who
> can represent the project?
> 
> Things a legal entity could do:
> - Sign contracts and raise money for events
> - Organise events
> - Own the trademark
> - Own project infrastructure like DNS, website infrastructure
> - Centralised pool for marketing budget?
> - Brand awareness?
> 
> There was agreement that legal governance should be lightweight, and
> completely independent of technical governance. Vincent insisted on the
> low cost structure for entities like 6WIND who would not be able to
> justify a 6 figure membership fee.
> 
> Topic 2: Technical governance (roadmap, project scope)
> ==
> 
> Jim: What if soeone proposes a feature that competes with a commercial
> offering from an incumbent? Is it rejected, accepted, ignored?
> 
> Thomas: Issue is one of trust - is Thomas a good maintainer or not?
> (language moderated ;-) If we trust the maintainer, then no problem. If
> people disagree with Thomas as maintainer, then there are multiple ways
> around it - gang up on Thomas & change maintainer, or fork.
> 
> Scope is a big question - is (say) a TCP stack in scope, or not? Website
> says no. Thomas replies that website can be changed by a patch - patch
> submission would be the start of a scope discussion, and the community
> will decide. Venky: Scope narrowed compared to his initial goal -
> satisfy needs of high volume servers.
> 
> How about ODP/DPDK convergence/co-operation? (nothing major noted,
> beyond "the topic came up")
> 
> Do we want/need a TSC (Technical Steering Committee)? Do we need a
> public roadmap?
> 
> Dave: If we have a TSC, then its 

[dpdk-dev] [PATCH v3 20/20] vmxnet3: copy pci device info to eth_dev data

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c 
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index a70be5c..2beee3e 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -235,6 +235,8 @@ eth_vmxnet3_dev_init(struct rte_eth_dev *eth_dev)
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;

+   rte_eth_copy_dev_info(eth_dev, pci_dev);
+
/* Vendor and Device ID need to be set before init of shared code */
hw->device_id = pci_dev->id.device_id;
hw->vendor_id = pci_dev->id.vendor_id;
-- 
1.9.1

[dpdk-dev] [PATCH v3 19/20] virtio: copy pci device info to eth_dev data

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 drivers/net/virtio/virtio_ethdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 465d3cd..20059a0 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1185,6 +1185,9 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
}

pci_dev = eth_dev->pci_dev;
+
+   rte_eth_copy_dev_info(eth_dev, pci_dev);
+
if (virtio_resource_init(pci_dev) < 0)
return -1;

-- 
1.9.1

[dpdk-dev] [PATCH v3 18/20] mlx4: copy pci device info to eth_dev data

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 drivers/net/mlx4/mlx4.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 2f49ed5..e7b38da 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -4973,6 +4973,9 @@ mlx4_pci_devinit(struct rte_pci_driver *pci_drv, struct 
rte_pci_device *pci_dev)

eth_dev->data->dev_private = priv;
eth_dev->pci_dev = pci_dev;
+
+   rte_eth_copy_dev_info(eth_dev, pci_dev);
+
eth_dev->driver = _driver;
eth_dev->data->rx_mbuf_alloc_failed = 0;
eth_dev->data->mtu = ETHER_MTU;
-- 
1.9.1

[dpdk-dev] [PATCH v3 17/20] enic: copy pci device info to eth_dev data

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 drivers/net/enic/enic_ethdev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index e385560..95baa8a 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -597,6 +597,7 @@ static int eth_enicpmd_dev_init(struct rte_eth_dev *eth_dev)
eth_dev->tx_pkt_burst = _xmit_pkts;

pdev = eth_dev->pci_dev;
+   rte_eth_copy_dev_info(eth_dev, pdev);
enic->pdev = pdev;
addr = >addr;

-- 
1.9.1

[dpdk-dev] [PATCH v3 16/20] cxgbe: copy pci device info to eth_dev data

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 drivers/net/cxgbe/cxgbe_ethdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 478051a..f081879 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -744,6 +744,9 @@ static int eth_cxgbe_dev_init(struct rte_eth_dev *eth_dev)
return 0;

pci_dev = eth_dev->pci_dev;
+
+   rte_eth_copy_dev_info(eth_dev, pci_dev);
+
snprintf(name, sizeof(name), "cxgbeadapter%d", eth_dev->data->port_id);
adapter = rte_zmalloc(name, sizeof(*adapter), 0);
if (!adapter)
-- 
1.9.1

[dpdk-dev] [PATCH v3 15/20] bnx2x: copy pci device info to eth_dev data

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 drivers/net/bnx2x/bnx2x_ethdev.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 09b5920..fbcd5f4 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -419,6 +419,9 @@ bnx2x_common_dev_init(struct rte_eth_dev *eth_dev, int 
is_vf)

eth_dev->dev_ops = is_vf ? _eth_dev_ops : _eth_dev_ops;
pci_dev = eth_dev->pci_dev;
+
+   rte_eth_copy_dev_info(eth_dev, pci_dev);
+
sc = eth_dev->data->dev_private;
sc->pcie_bus= pci_dev->addr.bus;
sc->pcie_device = pci_dev->addr.devid;
-- 
1.9.1

[dpdk-dev] [PATCH v3 14/20] fm10k: copy pci device info to eth_dev data

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 drivers/net/fm10k/fm10k_ethdev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index a69c990..12be227 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -2075,6 +2075,8 @@ eth_fm10k_dev_init(struct rte_eth_dev *dev)
if (rte_eal_process_type() != RTE_PROC_PRIMARY)
return 0;

+   rte_eth_copy_dev_info(dev, dev->pci_dev);
+
macvlan = FM10K_DEV_PRIVATE_TO_MACVLAN(dev->data->dev_private);
memset(macvlan, 0, sizeof(*macvlan));
/* Vendor and Device ID need to be set before init of shared code */
-- 
1.9.1

[dpdk-dev] [PATCH v3 13/20] i40e: copy pci device info to eth_dev data

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 drivers/net/i40e/i40e_ethdev.c| 3 +++
 drivers/net/i40e/i40e_ethdev_vf.c | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2dd9fdc..bd81d4e 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -408,6 +408,9 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
return 0;
}
pci_dev = dev->pci_dev;
+
+   rte_eth_copy_dev_info(dev, pci_dev);
+
pf->adapter = I40E_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private);
pf->adapter->eth_dev = dev;
pf->dev_data = dev->data;
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index b694400..ab718fb 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1187,6 +1187,8 @@ i40evf_dev_init(struct rte_eth_dev *eth_dev)
return 0;
}

+   rte_eth_copy_dev_info(eth_dev, eth_dev->pci_dev);
+
hw->vendor_id = eth_dev->pci_dev->id.vendor_id;
hw->device_id = eth_dev->pci_dev->id.device_id;
hw->subsystem_vendor_id = eth_dev->pci_dev->id.subsystem_vendor_id;
-- 
1.9.1

[dpdk-dev] [PATCH v3 12/20] e1000: copy pci device info to eth_dev data

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 drivers/net/e1000/em_ethdev.c  | 3 +++
 drivers/net/e1000/igb_ethdev.c | 5 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 912f5dd..aa1bf48 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -232,6 +232,9 @@ eth_em_dev_init(struct rte_eth_dev *eth_dev)
E1000_DEV_PRIVATE_TO_VFTA(eth_dev->data->dev_private);

pci_dev = eth_dev->pci_dev;
+
+   rte_eth_copy_dev_info(eth_dev, pci_dev);
+
eth_dev->dev_ops = _em_ops;
eth_dev->rx_pkt_burst = (eth_rx_burst_t)_em_recv_pkts;
eth_dev->tx_pkt_burst = (eth_tx_burst_t)_em_xmit_pkts;
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 848ef6e..2a7aa31 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -531,6 +531,9 @@ eth_igb_dev_init(struct rte_eth_dev *eth_dev)
uint32_t ctrl_ext;

pci_dev = eth_dev->pci_dev;
+
+   rte_eth_copy_dev_info(eth_dev, pci_dev);
+
eth_dev->dev_ops = _igb_ops;
eth_dev->rx_pkt_burst = _igb_recv_pkts;
eth_dev->tx_pkt_burst = _igb_xmit_pkts;
@@ -739,6 +742,8 @@ eth_igbvf_dev_init(struct rte_eth_dev *eth_dev)

pci_dev = eth_dev->pci_dev;

+   rte_eth_copy_dev_info(eth_dev, pci_dev);
+
hw->device_id = pci_dev->id.device_id;
hw->vendor_id = pci_dev->id.vendor_id;
hw->hw_addr = (void *)pci_dev->mem_resource[0].addr;
-- 
1.9.1

[dpdk-dev] [PATCH v3 11/20] ixgbe: copy pci device info to eth_dev data

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index ec2918c..08b5cbb 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -887,6 +887,8 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
}
pci_dev = eth_dev->pci_dev;

+   rte_eth_copy_dev_info(eth_dev, pci_dev);
+
/* Vendor and Device ID need to be set before init of shared code */
hw->device_id = pci_dev->id.device_id;
hw->vendor_id = pci_dev->id.vendor_id;
@@ -1155,6 +1157,8 @@ eth_ixgbevf_dev_init(struct rte_eth_dev *eth_dev)

pci_dev = eth_dev->pci_dev;

+   rte_eth_copy_dev_info(eth_dev, pci_dev);
+
hw->device_id = pci_dev->id.device_id;
hw->vendor_id = pci_dev->id.vendor_id;
hw->hw_addr = (void *)pci_dev->mem_resource[0].addr;
-- 
1.9.1

[dpdk-dev] [PATCH v3 10/20] mpipe: remove pci device driver

[Bernard Iremonger]

From: David Hunt 

initialise dev_flags, kdrv, driver, drv_name and numa_node in eth_dev data.

Signed-off-by: David Hunt 
Signed-off-by: Bernard Iremonger 
---
 drivers/net/mpipe/mpipe_tilegx.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index 743feef..5afd191 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -122,7 +122,6 @@ struct mpipe_dev_priv {
int channel;/* Device channel. */
int port_id;/* DPDK port index. */
struct rte_eth_dev *eth_dev;/* DPDK device. */
-   struct rte_pci_device pci_dev;  /* PCI device data. */
struct rte_mbuf **tx_comps; /* TX completion array. */
struct rte_mempool *rx_mpool;   /* mpool used by the rx queues. */
unsigned rx_offset; /* Receive head room. */
@@ -1567,7 +1566,6 @@ rte_pmd_mpipe_devinit(const char *ifname,
priv->context = context;
priv->instance = instance;
priv->is_xaui = (strncmp(ifname, "xgbe", 4) == 0);
-   priv->pci_dev.numa_node = instance;
priv->channel = -1;

mac = priv->mac_addr.addr_bytes;
@@ -1591,9 +1589,14 @@ rte_pmd_mpipe_devinit(const char *ifname,
priv->eth_dev = eth_dev;
priv->port_id = eth_dev->data->port_id;
eth_dev->data->dev_private = priv;
-   eth_dev->pci_dev = >pci_dev;
eth_dev->data->mac_addrs = >mac_addr;

+   eth_dev->data->dev_flags = 0;
+   eth_dev->data->kdrv = RTE_KDRV_NONE;
+   eth_dev->driver = NULL;
+   eth_dev->data->drv_name = NULL;
+   eth_dev->data->numa_node = instance;
+
eth_dev->dev_ops  = _dev_ops;
eth_dev->rx_pkt_burst = _recv_pkts;
eth_dev->tx_pkt_burst = _xmit_pkts;
-- 
1.9.1

[dpdk-dev] [PATCH v3 09/20] xenvirt: remove pci device driver

[Bernard Iremonger]

From: David Hunt 

Initialise dev_flags, driver, kdrv, drv_name and numa_node in eth_dev data.

Signed-off-by: David Hunt 
Signed-off-by: Bernard Iremonger 
---
 drivers/net/xenvirt/rte_eth_xenvirt.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/net/xenvirt/rte_eth_xenvirt.c 
b/drivers/net/xenvirt/rte_eth_xenvirt.c
index 73e8bce..b3383af 100644
--- a/drivers/net/xenvirt/rte_eth_xenvirt.c
+++ b/drivers/net/xenvirt/rte_eth_xenvirt.c
@@ -617,7 +617,6 @@ eth_dev_xenvirt_create(const char *name, const char *params,
 enum dev_action action)
 {
struct rte_eth_dev_data *data = NULL;
-   struct rte_pci_device *pci_dev = NULL;
struct pmd_internals *internals = NULL;
struct rte_eth_dev *eth_dev = NULL;
struct xenvirt_dict dict;
@@ -639,10 +638,6 @@ eth_dev_xenvirt_create(const char *name, const char 
*params,
if (data == NULL)
goto err;

-   pci_dev = rte_zmalloc_socket(name, sizeof(*pci_dev), 0, numa_node);
-   if (pci_dev == NULL)
-   goto err;
-
internals = rte_zmalloc_socket(name, sizeof(*internals), 0, numa_node);
if (internals == NULL)
goto err;
@@ -652,8 +647,6 @@ eth_dev_xenvirt_create(const char *name, const char *params,
if (eth_dev == NULL)
goto err;

-   pci_dev->numa_node = numa_node;
-
data->dev_private = internals;
data->port_id = eth_dev->data->port_id;
data->nb_rx_queues = (uint16_t)1;
@@ -668,7 +661,11 @@ eth_dev_xenvirt_create(const char *name, const char 
*params,

eth_dev->data = data;
eth_dev->dev_ops = 
-   eth_dev->pci_dev = pci_dev;
+   eth_dev->data->dev_flags = 0;
+   eth_dev->data->kdrv = RTE_KDRV_NONE;
+   eth_dev->data->drv_name = NULL;
+   eth_dev->driver = NULL;
+   eth_dev->data->numa_node = numa_node;

eth_dev->rx_pkt_burst = eth_xenvirt_rx;
eth_dev->tx_pkt_burst = eth_xenvirt_tx;
@@ -680,7 +677,6 @@ eth_dev_xenvirt_create(const char *name, const char *params,

 err:
rte_free(data);
-   rte_free(pci_dev);
rte_free(internals);

return -1;
-- 
1.9.1

[dpdk-dev] [PATCH v3 08/20] af_packet: remove pci device driver

[Bernard Iremonger]

From: David Hunt 

initialise dev_flags, driver, kdrv, drv_name and numa_node fileds in eth_dev 
data.

Signed-off-by: David Hunt 
Signed-off-by: Bernard Iremonger 
---
 drivers/net/af_packet/rte_eth_af_packet.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/net/af_packet/rte_eth_af_packet.c 
b/drivers/net/af_packet/rte_eth_af_packet.c
index bdd9628..7c3c455 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -5,7 +5,7 @@
  *
  *   Originally based upon librte_pmd_pcap code:
  *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  *   Copyright(c) 2014 6WIND S.A.
  *   All rights reserved.
  *
@@ -431,7 +431,6 @@ rte_pmd_init_internals(const char *name,
struct rte_kvargs *kvlist)
 {
struct rte_eth_dev_data *data = NULL;
-   struct rte_pci_device *pci_dev = NULL;
struct rte_kvargs_pair *pair = NULL;
struct ifreq ifr;
size_t ifnamelen;
@@ -469,10 +468,6 @@ rte_pmd_init_internals(const char *name,
if (data == NULL)
goto error;

-   pci_dev = rte_zmalloc_socket(name, sizeof(*pci_dev), 0, numa_node);
-   if (pci_dev == NULL)
-   goto error;
-
*internals = rte_zmalloc_socket(name, sizeof(**internals),
0, numa_node);
if (*internals == NULL)
@@ -655,8 +650,8 @@ rte_pmd_init_internals(const char *name,
/*
 * now put it all together
 * - store queue data in internals,
-* - store numa_node info in pci_driver
-* - point eth_dev_data to internals and pci_driver
+* - store numa_node info in eth_dev
+* - point eth_dev_data to internals
 * - and point eth_dev structure to new eth_dev_data structure
 */

@@ -669,17 +664,18 @@ rte_pmd_init_internals(const char *name,
data->dev_link = pmd_link;
data->mac_addrs = &(*internals)->eth_addr;

-   pci_dev->numa_node = numa_node;
-
(*eth_dev)->data = data;
(*eth_dev)->dev_ops = 
-   (*eth_dev)->pci_dev = pci_dev;
+   (*eth_dev)->data->dev_flags = 0;
+   (*eth_dev)->driver = NULL;
+   (*eth_dev)->data->drv_name = NULL;
+   (*eth_dev)->data->kdrv = RTE_KDRV_NONE;
+   (*eth_dev)->data->numa_node = numa_node;

return 0;

 error:
rte_free(data);
-   rte_free(pci_dev);

if (*internals) {
for (q = 0; q < nb_queues; q++) {
-- 
1.9.1

[dpdk-dev] [PATCH v3 07/20] pcap: remove pci device driver

[Bernard Iremonger]

remove rte_pcap_pmd and pci_dev.
initialise dev_flags, driver, drv_name, kdrv and numa_node fields in eth_dev 
data

Signed-off-by: Bernard Iremonger 
---
 drivers/net/pcap/rte_eth_pcap.c | 31 +--
 1 file changed, 9 insertions(+), 22 deletions(-)

diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index f2e4634..5f416f4 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  *   Copyright(c) 2014 6WIND S.A.
  *   All rights reserved.
  *
@@ -617,13 +617,6 @@ static const struct eth_dev_ops ops = {
.stats_reset = eth_stats_reset,
 };

-static struct eth_driver rte_pcap_pmd = {
-   .pci_drv = {
-   .name = "rte_pcap_pmd",
-   .drv_flags = RTE_PCI_DRV_DETACHABLE,
-   },
-};
-
 /*
  * Function handler that opens the pcap file for reading a stores a
  * reference of it for use it later on.
@@ -806,7 +799,6 @@ rte_pmd_init_internals(const char *name, const unsigned 
nb_rx_queues,
struct rte_kvargs *kvlist)
 {
struct rte_eth_dev_data *data = NULL;
-   struct rte_pci_device *pci_dev = NULL;
unsigned k_idx;
struct rte_kvargs_pair *pair = NULL;

@@ -819,17 +811,13 @@ rte_pmd_init_internals(const char *name, const unsigned 
nb_rx_queues,
RTE_LOG(INFO, PMD,
"Creating pcap-backed ethdev on numa socket %u\n", 
numa_node);

-   /* now do all data allocation - for eth_dev structure, dummy pci driver
+   /* now do all data allocation - for eth_dev structure
 * and internal (private) data
 */
data = rte_zmalloc_socket(name, sizeof(*data), 0, numa_node);
if (data == NULL)
goto error;

-   pci_dev = rte_zmalloc_socket(name, sizeof(*pci_dev), 0, numa_node);
-   if (pci_dev == NULL)
-   goto error;
-
*internals = rte_zmalloc_socket(name, sizeof(**internals), 0, 
numa_node);
if (*internals == NULL)
goto error;
@@ -845,8 +833,8 @@ rte_pmd_init_internals(const char *name, const unsigned 
nb_rx_queues,

/* now put it all together
 * - store queue data in internals,
-* - store numa_node info in pci_driver
-* - point eth_dev_data to internals and pci_driver
+* - store numa_node info in eth_dev
+* - point eth_dev_data to internals
 * - and point eth_dev structure to new eth_dev_data structure
 */
/* NOTE: we'll replace the data element, of originally allocated eth_dev
@@ -860,8 +848,6 @@ rte_pmd_init_internals(const char *name, const unsigned 
nb_rx_queues,
else
(*internals)->if_index = if_nametoindex(pair->value);

-   pci_dev->numa_node = numa_node;
-
data->dev_private = *internals;
data->port_id = (*eth_dev)->data->port_id;
snprintf(data->name, sizeof(data->name), "%s", (*eth_dev)->data->name);
@@ -874,14 +860,16 @@ rte_pmd_init_internals(const char *name, const unsigned 
nb_rx_queues,

(*eth_dev)->data = data;
(*eth_dev)->dev_ops = 
-   (*eth_dev)->pci_dev = pci_dev;
-   (*eth_dev)->driver = _pcap_pmd;
+   (*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
+   (*eth_dev)->driver = NULL;
+   (*eth_dev)->data->kdrv = RTE_KDRV_NONE;
+   (*eth_dev)->data->drv_name = NULL;
+   (*eth_dev)->data->numa_node = numa_node;

return 0;

 error:
rte_free(data);
-   rte_free(pci_dev);
rte_free(*internals);

return -1;
@@ -1096,7 +1084,6 @@ rte_pmd_pcap_devuninit(const char *name)

rte_free(eth_dev->data->dev_private);
rte_free(eth_dev->data);
-   rte_free(eth_dev->pci_dev);

rte_eth_dev_release_port(eth_dev);

-- 
1.9.1

[dpdk-dev] [PATCH v3 06/20] bonding: remove pci device driver

[Bernard Iremonger]

remove pci_dev, pci_drv, rte_bond_pmd and pci_id_table.
initialise dev_flags, kdrv, driver, drv_name and numa_node fields in eth_dev 
data.
handle numa_node for vdevs
handle RTE_ETH_DEV_INTR_LSC for vdevs
rename valid_bonded_device to check_for_bonded_device

Signed-off-by: Bernard Iremonger 
---
 drivers/net/bonding/rte_eth_bond_alb.c |  2 +-
 drivers/net/bonding/rte_eth_bond_api.c | 58 +-
 drivers/net/bonding/rte_eth_bond_pmd.c | 16 -
 drivers/net/bonding/rte_eth_bond_private.h |  2 +-
 4 files changed, 26 insertions(+), 52 deletions(-)

diff --git a/drivers/net/bonding/rte_eth_bond_alb.c 
b/drivers/net/bonding/rte_eth_bond_alb.c
index 6df318e..3157543 100644
--- a/drivers/net/bonding/rte_eth_bond_alb.c
+++ b/drivers/net/bonding/rte_eth_bond_alb.c
@@ -65,7 +65,7 @@ bond_mode_alb_enable(struct rte_eth_dev *bond_dev)

uint16_t data_size;
char mem_name[RTE_ETH_NAME_MAX_LEN];
-   int socket_id = bond_dev->pci_dev->numa_node;
+   int socket_id = bond_dev->data->numa_node;

/* Fill hash table with initial values */
memset(hash_table, 0, sizeof(struct client_data) * ALB_HASH_TABLE_SIZE);
diff --git a/drivers/net/bonding/rte_eth_bond_api.c 
b/drivers/net/bonding/rte_eth_bond_api.c
index 0681d1a..55f028f 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -45,14 +45,17 @@
 #define DEFAULT_POLLING_INTERVAL_10_MS (10)

 int
-valid_bonded_ethdev(const struct rte_eth_dev *eth_dev)
+check_for_bonded_ethdev(const struct rte_eth_dev *eth_dev)
 {
/* Check valid pointer */
-   if (eth_dev->driver->pci_drv.name == NULL)
+   if (!eth_dev)
return -1;

-   /* return 0 if driver name matches */
-   return eth_dev->driver->pci_drv.name != pmd_bond_driver_name;
+   /* return 0 if bonded device */
+   if (eth_dev->data->dev_flags & RTE_ETH_DEV_BONDED)
+   return 0;
+   else
+   return 1;
 }

 int
@@ -61,7 +64,7 @@ valid_bonded_port_id(uint8_t port_id)
if (!rte_eth_dev_is_valid_port(port_id))
return -1;

-   return valid_bonded_ethdev(_eth_devices[port_id]);
+   return check_for_bonded_ethdev(_eth_devices[port_id]);
 }

 int
@@ -72,7 +75,7 @@ valid_slave_port_id(uint8_t port_id)
return -1;

/* Verify that port_id refers to a non bonded port */
-   if (!valid_bonded_ethdev(_eth_devices[port_id]))
+   if (check_for_bonded_ethdev(_eth_devices[port_id]) == 0)
return -1;

return 0;
@@ -163,30 +166,11 @@ number_of_sockets(void)
return ++sockets;
 }

-const char pmd_bond_driver_name[] = "rte_bond_pmd";
-
-static struct rte_pci_id pci_id_table = {
-   .device_id = PCI_ANY_ID,
-   .subsystem_device_id = PCI_ANY_ID,
-   .vendor_id = PCI_ANY_ID,
-   .subsystem_vendor_id = PCI_ANY_ID,
-};
-
-static struct eth_driver rte_bond_pmd = {
-   .pci_drv = {
-   .name = pmd_bond_driver_name,
-   .drv_flags = RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_DETACHABLE,
-   .id_table = _id_table,
-   },
-};
-
 int
 rte_eth_bond_create(const char *name, uint8_t mode, uint8_t socket_id)
 {
-   struct rte_pci_device *pci_dev = NULL;
struct bond_dev_private *internals = NULL;
struct rte_eth_dev *eth_dev = NULL;
-   struct rte_pci_driver *pci_drv = NULL;

/* now do all data allocation - for eth_dev structure, dummy pci driver
 * and internal (private) data
@@ -203,14 +187,6 @@ rte_eth_bond_create(const char *name, uint8_t mode, 
uint8_t socket_id)
goto err;
}

-   pci_dev = rte_zmalloc_socket(name, sizeof(*pci_dev), 0, socket_id);
-   if (pci_dev == NULL) {
-   RTE_BOND_LOG(ERR, "Unable to malloc pci dev on socket");
-   goto err;
-   }
-
-   pci_drv = _bond_pmd.pci_drv;
-
internals = rte_zmalloc_socket(name, sizeof(*internals), 0, socket_id);
if (internals == NULL) {
RTE_BOND_LOG(ERR, "Unable to malloc internals on socket");
@@ -224,11 +200,6 @@ rte_eth_bond_create(const char *name, uint8_t mode, 
uint8_t socket_id)
goto err;
}

-   pci_dev->numa_node = socket_id;
-   pci_drv->name = pmd_bond_driver_name;
-   pci_dev->driver = pci_drv;
-
-   eth_dev->driver = _bond_pmd;
eth_dev->data->dev_private = internals;
eth_dev->data->nb_rx_queues = (uint16_t)1;
eth_dev->data->nb_tx_queues = (uint16_t)1;
@@ -250,7 +221,12 @@ rte_eth_bond_create(const char *name, uint8_t mode, 
uint8_t socket_id)
eth_dev->data->all_multicast = 0;

eth_dev->dev_ops = _dev_ops;
-   eth_dev->pci_dev = pci_dev;
+   eth_dev->data->dev_flags = RTE_ETH_DEV_INTR_LSC |
+   RTE_ETH_DEV_DETACHABLE | RTE_ETH_DEV_BONDED;
+   eth_dev->driver = NULL;
+   eth_dev->data->kdrv = RTE_KDRV_NONE;
+   

[dpdk-dev] [PATCH v3 05/20] ring: remove pci device driver

[Bernard Iremonger]

remove rte_ring_pmd and pci_dev.
initialise dev_flags, driver, drv_name, kdrv and numa_node fields in eth_dev 
data.

Signed-off-by: Bernard Iremonger 
---
 drivers/net/ring/rte_eth_ring.c | 37 -
 1 file changed, 8 insertions(+), 29 deletions(-)

diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 0ba36d5..65608b2 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -44,8 +44,6 @@
 #define ETH_RING_ACTION_CREATE "CREATE"
 #define ETH_RING_ACTION_ATTACH "ATTACH"

-static const char *ring_ethdev_driver_name = "Ring PMD";
-
 static const char *valid_arguments[] = {
ETH_RING_NUMA_NODE_ACTION_ARG,
NULL
@@ -252,15 +250,6 @@ static const struct eth_dev_ops ops = {
.mac_addr_add = eth_mac_addr_add,
 };

-static struct eth_driver rte_ring_pmd = {
-   .pci_drv = {
-   .name = "rte_ring_pmd",
-   .drv_flags = RTE_PCI_DRV_DETACHABLE,
-   },
-};
-
-static struct rte_pci_id id_table;
-
 int
 rte_eth_from_rings(const char *name, struct rte_ring *const rx_queues[],
const unsigned nb_rx_queues,
@@ -269,7 +258,6 @@ rte_eth_from_rings(const char *name, struct rte_ring *const 
rx_queues[],
const unsigned numa_node)
 {
struct rte_eth_dev_data *data = NULL;
-   struct rte_pci_device *pci_dev = NULL;
struct pmd_internals *internals = NULL;
struct rte_eth_dev *eth_dev = NULL;

@@ -291,10 +279,6 @@ rte_eth_from_rings(const char *name, struct rte_ring 
*const rx_queues[],
if (data == NULL)
goto error;

-   pci_dev = rte_zmalloc_socket(name, sizeof(*pci_dev), 0, numa_node);
-   if (pci_dev == NULL)
-   goto error;
-
internals = rte_zmalloc_socket(name, sizeof(*internals), 0, numa_node);
if (internals == NULL)
goto error;
@@ -304,11 +288,10 @@ rte_eth_from_rings(const char *name, struct rte_ring 
*const rx_queues[],
if (eth_dev == NULL)
goto error;

-
/* now put it all together
 * - store queue data in internals,
-* - store numa_node info in pci_driver
-* - point eth_dev_data to internals and pci_driver
+* - store numa_node info in eth_dev_data
+* - point eth_dev_data to internals
 * - and point eth_dev structure to new eth_dev_data structure
 */
/* NOTE: we'll replace the data element, of originally allocated eth_dev
@@ -323,12 +306,6 @@ rte_eth_from_rings(const char *name, struct rte_ring 
*const rx_queues[],
internals->tx_ring_queues[i].rng = tx_queues[i];
}

-   rte_ring_pmd.pci_drv.name = ring_ethdev_driver_name;
-   rte_ring_pmd.pci_drv.id_table = _table;
-
-   pci_dev->numa_node = numa_node;
-   pci_dev->driver = _ring_pmd.pci_drv;
-
data->dev_private = internals;
data->port_id = eth_dev->data->port_id;
memmove(data->name, eth_dev->data->name, sizeof(data->name));
@@ -338,9 +315,13 @@ rte_eth_from_rings(const char *name, struct rte_ring 
*const rx_queues[],
data->mac_addrs = >address;

eth_dev->data = data;
-   eth_dev->driver = _ring_pmd;
+   eth_dev->driver = NULL;
eth_dev->dev_ops = 
-   eth_dev->pci_dev = pci_dev;
+   eth_dev->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
+   eth_dev->data->kdrv = RTE_KDRV_NONE;
+   eth_dev->data->drv_name = NULL;
+   eth_dev->data->numa_node = numa_node;
+
TAILQ_INIT(&(eth_dev->link_intr_cbs));

/* finally assign rx and tx ops */
@@ -351,7 +332,6 @@ rte_eth_from_rings(const char *name, struct rte_ring *const 
rx_queues[],

 error:
rte_free(data);
-   rte_free(pci_dev);
rte_free(internals);

return -1;
@@ -561,7 +541,6 @@ rte_pmd_ring_devuninit(const char *name)
eth_dev_stop(eth_dev);
rte_free(eth_dev->data->dev_private);
rte_free(eth_dev->data);
-   rte_free(eth_dev->pci_dev);

rte_eth_dev_release_port(eth_dev);
return 0;
-- 
1.9.1

[dpdk-dev] [PATCH v3 04/20] null: remove pci device driver

[Bernard Iremonger]

remove rte_null_pmd and pci_dev.
initialise dev_flags, driver, drv_name, kdrv and numa_node fields in eth_dev 
data

Signed-off-by: Bernard Iremonger 
---
 drivers/net/null/rte_eth_null.c | 28 +++-
 1 file changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index e244595..fb7473f 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -340,13 +340,6 @@ eth_stats_reset(struct rte_eth_dev *dev)
}
 }

-static struct eth_driver rte_null_pmd = {
-   .pci_drv = {
-   .name = "rte_null_pmd",
-   .drv_flags = RTE_PCI_DRV_DETACHABLE,
-   },
-};
-
 static void
 eth_queue_release(void *q)
 {
@@ -386,7 +379,6 @@ eth_dev_null_create(const char *name,
const unsigned nb_rx_queues = 1;
const unsigned nb_tx_queues = 1;
struct rte_eth_dev_data *data = NULL;
-   struct rte_pci_device *pci_dev = NULL;
struct pmd_internals *internals = NULL;
struct rte_eth_dev *eth_dev = NULL;

@@ -403,10 +395,6 @@ eth_dev_null_create(const char *name,
if (data == NULL)
goto error;

-   pci_dev = rte_zmalloc_socket(name, sizeof(*pci_dev), 0, numa_node);
-   if (pci_dev == NULL)
-   goto error;
-
internals = rte_zmalloc_socket(name, sizeof(*internals), 0, numa_node);
if (internals == NULL)
goto error;
@@ -418,8 +406,7 @@ eth_dev_null_create(const char *name,

/* now put it all together
 * - store queue data in internals,
-* - store numa_node info in pci_driver
-* - point eth_dev_data to internals and pci_driver
+* - point eth_dev_data to internals
 * - and point eth_dev structure to new eth_dev_data structure
 */
/* NOTE: we'll replace the data element, of originally allocated eth_dev
@@ -431,8 +418,6 @@ eth_dev_null_create(const char *name,
internals->packet_copy = packet_copy;
internals->numa_node = numa_node;

-   pci_dev->numa_node = numa_node;
-
data->dev_private = internals;
data->port_id = eth_dev->data->port_id;
data->nb_rx_queues = (uint16_t)nb_rx_queues;
@@ -443,8 +428,11 @@ eth_dev_null_create(const char *name,

eth_dev->data = data;
eth_dev->dev_ops = 
-   eth_dev->pci_dev = pci_dev;
-   eth_dev->driver = _null_pmd;
+   eth_dev->driver = NULL;
+   eth_dev->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
+   eth_dev->data->kdrv = RTE_KDRV_NONE;
+   eth_dev->data->drv_name = NULL;
+   eth_dev->data->numa_node = numa_node;

/* finally assign rx and tx ops */
if (packet_copy) {
@@ -459,7 +447,6 @@ eth_dev_null_create(const char *name,

 error:
rte_free(data);
-   rte_free(pci_dev);
rte_free(internals);

return -1;
@@ -562,14 +549,13 @@ rte_pmd_null_devuninit(const char *name)
RTE_LOG(INFO, PMD, "Closing null ethdev on numa socket %u\n",
rte_socket_id());

-   /* reserve an ethdev entry */
+   /* find the ethdev entry */
eth_dev = rte_eth_dev_allocated(name);
if (eth_dev == NULL)
return -1;

rte_free(eth_dev->data->dev_private);
rte_free(eth_dev->data);
-   rte_free(eth_dev->pci_dev);

rte_eth_dev_release_port(eth_dev);

-- 
1.9.1

[dpdk-dev] [PATCH v3 03/20] librte_ether: add function rte_eth_copy_dev_info()

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 lib/librte_ether/rte_ethdev.c  | 14 ++
 lib/librte_ether/rte_ethdev.h  | 14 ++
 lib/librte_ether/rte_ether_version.map |  7 +++
 3 files changed, 35 insertions(+)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 4187595..2fce370 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -3336,3 +3336,17 @@ rte_eth_dev_set_eeprom(uint8_t port_id, struct 
rte_dev_eeprom_info *info)
FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_eeprom, -ENOTSUP);
return (*dev->dev_ops->set_eeprom)(dev, info);
 }
+
+void
+rte_eth_copy_dev_info(struct rte_eth_dev *eth_dev, struct rte_pci_device 
*pci_dev)
+{
+   if ((eth_dev == NULL) || (pci_dev == NULL)) {
+   PMD_DEBUG_TRACE("NULL pointer eth_dev=%p pci_dev=%p\n",
+   eth_dev, pci_dev);
+   }
+
+   eth_dev->data->dev_flags = pci_dev->driver->drv_flags;
+   eth_dev->data->kdrv = pci_dev->kdrv;
+   eth_dev->data->numa_node = pci_dev->numa_node;
+   eth_dev->data->drv_name = pci_dev->driver->name;
+}
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index d440bd6..815e2fc 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -3613,6 +3613,20 @@ extern int rte_eth_timesync_read_rx_timestamp(uint8_t 
port_id,
 extern int rte_eth_timesync_read_tx_timestamp(uint8_t port_id,
  struct timespec *timestamp);

+/**
+ * Copy pci device info to the Ethernet device data.
+ *
+ * @param eth_dev
+ * The *eth_dev* pointer is the address of the *rte_eth_dev* structure.
+ * @param pci_dev
+ * The *pci_dev* pointer is the address of the *rte_pci_device* structure.
+ *
+ * @return
+ *   - 0 on success, negative on error
+ */
+extern void rte_eth_copy_dev_info(struct rte_eth_dev *eth_dev, struct 
rte_pci_device *pci_dev);
+
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/librte_ether/rte_ether_version.map 
b/lib/librte_ether/rte_ether_version.map
index 8345a6c..e6a43be 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -127,3 +127,10 @@ DPDK_2.1 {
rte_eth_timesync_read_tx_timestamp;

 } DPDK_2.0;
+
+DPDK_2.2 {
+   global:
+
+   rte_eth_copy_dev_info;
+
+} DPDK_2.1;
-- 
1.9.1

[dpdk-dev] [PATCH v3 02/20] librte_ether: add fields from rte_pci_driver to rte_eth_dev_data

[Bernard Iremonger]

add dev_flags to rte_eth_dev_data, add macros for dev_flags.
add kdrv to rte_eth_dev_data.
add numa_node to rte_eth_dev_data.
add drv_name to rte_eth_dev_data.
use dev_type to distinguish between vdev's and pdev's.
remove pci_dev branches.

Signed-off-by: Bernard Iremonger 
---
 lib/librte_ether/rte_ethdev.c | 40 +---
 lib/librte_ether/rte_ethdev.h | 15 +++
 2 files changed, 32 insertions(+), 23 deletions(-)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index f593f6e..4187595 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -424,7 +424,7 @@ rte_eth_dev_socket_id(uint8_t port_id)
 {
if (!rte_eth_dev_is_valid_port(port_id))
return -1;
-   return rte_eth_devices[port_id].pci_dev->numa_node;
+   return rte_eth_devices[port_id].data->numa_node;
 }

 uint8_t
@@ -503,27 +503,25 @@ rte_eth_dev_get_name_by_port(uint8_t port_id, char *name)
 static int
 rte_eth_dev_is_detachable(uint8_t port_id)
 {
-   uint32_t drv_flags;
+   uint32_t dev_flags;

if (!rte_eth_dev_is_valid_port(port_id)) {
PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
return -EINVAL;
}

-   if (rte_eth_devices[port_id].dev_type == RTE_ETH_DEV_PCI) {
-   switch (rte_eth_devices[port_id].pci_dev->kdrv) {
-   case RTE_KDRV_IGB_UIO:
-   case RTE_KDRV_UIO_GENERIC:
-   case RTE_KDRV_NIC_UIO:
-   break;
-   case RTE_KDRV_VFIO:
-   default:
-   return -ENOTSUP;
-   }
+   switch (rte_eth_devices[port_id].data->kdrv) {
+   case RTE_KDRV_IGB_UIO:
+   case RTE_KDRV_UIO_GENERIC:
+   case RTE_KDRV_NIC_UIO:
+   case RTE_KDRV_NONE:
+   break;
+   case RTE_KDRV_VFIO:
+   default:
+   return -ENOTSUP;
}
-
-   drv_flags = rte_eth_devices[port_id].driver->pci_drv.drv_flags;
-   return !(drv_flags & RTE_PCI_DRV_DETACHABLE);
+   dev_flags = rte_eth_devices[port_id].data->dev_flags;
+   return !(dev_flags & RTE_ETH_DEV_DETACHABLE);
 }

 /* attach the new physical device, then store port_id of the device */
@@ -1143,14 +1141,11 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t 
nb_rx_q, uint16_t nb_tx_q,
 * If link state interrupt is enabled, check that the
 * device supports it.
 */
-   if (dev_conf->intr_conf.lsc == 1) {
-   const struct rte_pci_driver *pci_drv = >driver->pci_drv;
-
-   if (!(pci_drv->drv_flags & RTE_PCI_DRV_INTR_LSC)) {
+   if ((dev_conf->intr_conf.lsc == 1) &&
+   (!(dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC))) {
PMD_DEBUG_TRACE("driver %s does not support lsc\n",
-   pci_drv->name);
+   dev->data->drv_name);
return -EINVAL;
-   }
}

/*
@@ -1795,8 +1790,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct 
rte_eth_dev_info *dev_info)
FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
dev_info->pci_dev = dev->pci_dev;
-   if (dev->driver)
-   dev_info->driver_name = dev->driver->pci_drv.name;
+   dev_info->driver_name = dev->data->drv_name;
 }

 void
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 8a8c82b..d440bd6 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1471,8 +1471,23 @@ struct rte_eth_dev_data {
all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */
dev_started : 1,   /**< Device state: STARTED(1) / STOPPED(0). 
*/
lro : 1;   /**< RX LRO is ON(1) / OFF(0) */
+   uint32_t dev_flags; /**< Flags controlling handling of device. */
+   enum rte_kernel_driver kdrv;/**< Kernel driver passthrough */
+   int numa_node;
+   const char *drv_name;
 };

+/** Device needs PCI BAR mapping (done with either IGB_UIO or VFIO) */
+#define RTE_ETH_DEV_DRV_NEED_MAPPING   RTE_PCI_DRV_NEED_MAPPING
+/** Device needs to be unbound even if no module is provided */
+#define RTE_ETH_DEV_DRV_FORCE_UNBIND   RTE_PCI_DRV_FORCE_UNBIND
+/** Device supports link state interrupt */
+#define RTE_ETH_DEV_INTR_LSC   RTE_PCI_DRV_INTR_LSC
+/** Device  supports detaching capability */
+#define RTE_ETH_DEV_DETACHABLE RTE_PCI_DRV_DETACHABLE
+/** Device  is a bonded device */
+#define RTE_ETH_DEV_BONDED 0x0020
+
 /**
  * @internal
  * The pool of *rte_eth_dev* structures. The size of the pool
-- 
1.9.1

[dpdk-dev] [PATCH v3 01/20] librte_eal: add RTE_KDRV_NONE for vdevs

[Bernard Iremonger]

Signed-off-by: Bernard Iremonger 
---
 lib/librte_eal/common/include/rte_pci.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/librte_eal/common/include/rte_pci.h 
b/lib/librte_eal/common/include/rte_pci.h
index 83e3c28..334c12e 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -149,6 +149,7 @@ enum rte_kernel_driver {
RTE_KDRV_VFIO,
RTE_KDRV_UIO_GENERIC,
RTE_KDRV_NIC_UIO,
+   RTE_KDRV_NONE,
 };

 /**
-- 
1.9.1

[dpdk-dev] [PATCH v3 00/20] remove pci driver from vdevs

[Bernard Iremonger]

There is a dummy pci driver in the vdev PMD's at present.
This patch set removes the pci driver from the vdev PMD's.
Changes have been made to librte_ether to handle vdevs and pdevs in the same 
way.

The following vdev PMD's have had the pci driver removed:

null
ring
bonding
pcap
af_packet
xenvirt
mpipe

All the pdev PMD's have been modified to copy the pci device info into ethdev 
data.

Changes in v3:
rebase to latest code.
restructure patches 0002 and 0003 to fix compile issue in patch 0002.

Changes in V2:
rebase to latest code.
fix compile error in rte_ethdev.c when debug disabled.
remove intel copyright from bnx2x, cxgbe, enic, mlx4, mpipe and null PMD's.

Bernard Iremonger (17):
  librte_eal: add RTE_KDRV_NONE for vdevs
  librte_ether: add fields from rte_pci_driver to rte_eth_dev_data
  librte_ether: add function rte_eth_copy_dev_info()
  null: remove pci device driver
  ring: remove pci device driver
  bonding: remove pci device driver
  pcap: remove pci device driver
  ixgbe: copy pci device info to eth_dev data
  e1000: copy pci device info to eth_dev data
  i40e: copy pci device info to eth_dev data
  fm10k: copy pci device info to eth_dev data
  bnx2x: copy pci device info to eth_dev data
  cxgbe: copy pci device info to eth_dev data
  enic: copy pci device info to eth_dev data
  mlx4: copy pci device info to eth_dev data
  virtio: copy pci device info to eth_dev data
  vmxnet3: copy pci device info to eth_dev data

David Hunt (3):
  af_packet: remove pci device driver
  xenvirt: remove pci device driver
  mpipe: remove pci device driver

 drivers/net/af_packet/rte_eth_af_packet.c  | 20 +--
 drivers/net/bnx2x/bnx2x_ethdev.c   |  3 ++
 drivers/net/bonding/rte_eth_bond_alb.c |  2 +-
 drivers/net/bonding/rte_eth_bond_api.c | 58 +-
 drivers/net/bonding/rte_eth_bond_pmd.c | 16 -
 drivers/net/bonding/rte_eth_bond_private.h |  2 +-
 drivers/net/cxgbe/cxgbe_ethdev.c   |  3 ++
 drivers/net/e1000/em_ethdev.c  |  3 ++
 drivers/net/e1000/igb_ethdev.c |  5 +++
 drivers/net/enic/enic_ethdev.c |  1 +
 drivers/net/fm10k/fm10k_ethdev.c   |  2 ++
 drivers/net/i40e/i40e_ethdev.c |  3 ++
 drivers/net/i40e/i40e_ethdev_vf.c  |  2 ++
 drivers/net/ixgbe/ixgbe_ethdev.c   |  4 +++
 drivers/net/mlx4/mlx4.c|  3 ++
 drivers/net/mpipe/mpipe_tilegx.c   |  9 +++--
 drivers/net/null/rte_eth_null.c| 28 ---
 drivers/net/pcap/rte_eth_pcap.c| 31 +---
 drivers/net/ring/rte_eth_ring.c| 37 +--
 drivers/net/virtio/virtio_ethdev.c |  3 ++
 drivers/net/vmxnet3/vmxnet3_ethdev.c   |  2 ++
 drivers/net/xenvirt/rte_eth_xenvirt.c  | 14 +++-
 lib/librte_eal/common/include/rte_pci.h|  3 +-
 lib/librte_ether/rte_ethdev.c  | 54 
 lib/librte_ether/rte_ethdev.h  | 29 +++
 lib/librte_ether/rte_ether_version.map |  7 
 26 files changed, 172 insertions(+), 172 deletions(-)

-- 
1.9.1

[dpdk-dev] [Pktgen] [PATCH] pktgen_setup_packets: fix race for packet header

[Ilya Maximets]

Sorry for pinging, but have you tried to merge this patch?

Best regards, Ilya Maximets.

On 02.10.2015 14:25, Wiles, Keith wrote:
> I looked at the code and everything looks good. I will try to merge the
> code next week as I am traveling again :-(
> 
> Thanks for the patch, I am glad you found this problem as I believe
> someone else reported something odd in that area, but was not able to give
> me many details.
> ? 
> Regards,
> ++Keith Wiles
> 
> Intel Corporation
> 
> 
> 
> 
> On 10/2/15, 10:23 AM, "Ilya Maximets"  wrote:
> 
>> Ping.
>>
>> On 17.09.2015 08:55, Ilya Maximets wrote:
>>> Ok. Thank you. I'll wait.
>>>
>>> On 16.09.2015 18:37, Wiles, Keith wrote:
 Thanks the patch looks fine, but I have not had a lot of time to
 review it
 detail. I hope to get to it next week after I return back home.

 On 9/16/15, 2:09 AM, "Ilya Maximets"  wrote:

> Ping.
>
> On 09.09.2015 17:22, Ilya Maximets wrote:
>> While pktgen_setup_packets() all threads of one port uses same
>> info->seq_pkt. This leads to constructing packets in the same memory
>> region
>> (>hdr). As a result, pktgen_setup_packets generates random
>> headers.
>>
>> Fix that by making a local copy of info->seq_pkt and using it for
>> constructing of packets.
>>
>> Signed-off-by: Ilya Maximets 
>> ---
>>  app/pktgen-arp.c  |  2 +-
>>  app/pktgen-cmds.c | 40 
>>  app/pktgen-ipv4.c |  2 +-
>>  app/pktgen.c  | 39 +++
>>  app/pktgen.h  |  4 ++--
>>  app/t/pktgen.t.c  |  6 +++---
>>  6 files changed, 54 insertions(+), 39 deletions(-)
>>
>> diff --git a/app/pktgen-arp.c b/app/pktgen-arp.c
>> index c378880..b7040d7 100644
>> --- a/app/pktgen-arp.c
>> +++ b/app/pktgen-arp.c
>> @@ -190,7 +190,7 @@ pktgen_process_arp( struct rte_mbuf * m, uint32_t
>> pid, uint32_t vlan )
>>  
>>  rte_memcpy(>eth_dst_addr, 
>> >sha, 6);
>>  for (i = 0; i < info->seqCnt; i++)
>> -pktgen_packet_ctor(info, i, -1);
>> +pktgen_packet_ctor(info, i, -1, 
>> NULL);
>>  }
>>  
>>  // Swap the two MAC addresses
>> diff --git a/app/pktgen-cmds.c b/app/pktgen-cmds.c
>> index da040e5..a6abb41 100644
>> --- a/app/pktgen-cmds.c
>> +++ b/app/pktgen-cmds.c
>> @@ -931,7 +931,7 @@ pktgen_set_proto(port_info_t * info, char type)
>>  if ( type == 'i' )
>>  info->seq_pkt[SINGLE_PKT].ethType = ETHER_TYPE_IPv4;
>>  
>> -pktgen_packet_ctor(info, SINGLE_PKT, -1);
>> +pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>  }
>>  
>>  
>>
>> /*
>> ***
>> **//**
>> @@ -1067,7 +1067,7 @@ pktgen_set_pkt_type(port_info_t * info, const
>> char * type)
>>  
>> (type[3] == '6') ? ETHER_TYPE_IPv6 :
>>  
>> /* TODO print error: unknown type */ ETHER_TYPE_IPv4;
>>  
>> -pktgen_packet_ctor(info, SINGLE_PKT, -1);
>> +pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>  }
>>  
>>  
>>
>> /*
>> ***
>> **//**
>> @@ -1092,7 +1092,7 @@ pktgen_set_vlan(port_info_t * info, uint32_t
>> onOff)
>>  }
>>  else
>>  pktgen_clr_port_flags(info, SEND_VLAN_ID);
>> -pktgen_packet_ctor(info, SINGLE_PKT, -1);
>> +pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>  }
>>  
>>  
>>
>> /*
>> ***
>> **//**
>> @@ -1112,7 +1112,7 @@ pktgen_set_vlanid(port_info_t * info, uint16_t
>> vlanid)
>>  {
>>  info->vlanid = vlanid;
>>  info->seq_pkt[SINGLE_PKT].vlanid = info->vlanid;
>> -pktgen_packet_ctor(info, SINGLE_PKT, -1);
>> +pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>  }
>>  
>>  
>>
>> /*
>> ***
>> **//**
>> @@ -1137,7 +1137,7 @@ pktgen_set_mpls(port_info_t * info, uint32_t
>> onOff)
>>  }
>>  else
>>  pktgen_clr_port_flags(info, SEND_MPLS_LABEL);
>> -pktgen_packet_ctor(info, SINGLE_PKT, -1);
>> +pktgen_packet_ctor(info, SINGLE_PKT, -1, NULL);
>>  }
>>  
>>  
>>
>> 

[dpdk-dev] dpdk 2.1.0: 40gig ports link is down

[Shaham Fridenberg]

Hey Stephen,

Thanks for your help.

I tried updating i40e driver to the latest version (from 1.0.11-k to 1.3.39.1) 
but it didn't help.

By 'Compile i40e with DEBUG flag' you mean adding "CONFIG_RTE_LOG_LEVEL=8" to 
defconfig_x86_64-wsm-linuxapp-gcc (assuming I'm compiling for westmere)?

Also, is there any log file generated in that case?

Thanks,
Shaham

-Original Message-
From: Stephen Hemminger [mailto:step...@networkplumber.org] 
Sent: Monday, October 12, 2015 6:39 PM
To: Shaham Fridenberg
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] dpdk 2.1.0: 40gig ports link is down

On Mon, 12 Oct 2015 13:29:42 +
Shaham Fridenberg  wrote:

> Hey all,
> 
> I upgraded from dpdk 1.8.0 to 2.1.0 and now my 40gig ports (rte_i40e_pmd) 
> link is down.
> 
> Any idea what might be the issue?
> 
> Thanks,
> Shaham

Compile i40e with DEBUG flag enabled in config and make sure LOGLEVEL is set to 
8 to show debug output.

It maybe something related to firmware versions.
Make sure you have updated firmware (see Intel tool).

[dpdk-dev] [PATCH v3] ip_pipeline: add flow id parameter to flow classification

[Jasvinder Singh]

This patch adds flow id field to the flow
classification table entries and adds table action
handlers to read flow id from table entry and
write it into the packet meta-data. The flow_id
(32-bit) parameter is also added to CLI commands
flow add, flow delete, etc.

*v2
fixed bug: flow table entry size power of 2

*v3
fixed bug: changed LRU hash table operation to
extendible bucket hash table operation

Signed-off-by: Jasvinder Singh 
---
 .../pipeline/pipeline_flow_classification.c| 206 ++---
 .../pipeline/pipeline_flow_classification.h|   4 +-
 .../pipeline/pipeline_flow_classification_be.c | 117 +++-
 .../pipeline/pipeline_flow_classification_be.h |   2 +
 4 files changed, 297 insertions(+), 32 deletions(-)

diff --git a/examples/ip_pipeline/pipeline/pipeline_flow_classification.c 
b/examples/ip_pipeline/pipeline/pipeline_flow_classification.c
index 4b82180..04b6915 100644
--- a/examples/ip_pipeline/pipeline/pipeline_flow_classification.c
+++ b/examples/ip_pipeline/pipeline/pipeline_flow_classification.c
@@ -152,6 +152,7 @@ app_pipeline_fc_key_convert(struct pipeline_fc_key *key_in,
 struct app_pipeline_fc_flow {
struct pipeline_fc_key key;
uint32_t port_id;
+   uint32_t flow_id;
uint32_t signature;
void *entry_ptr;

@@ -280,7 +281,8 @@ int
 app_pipeline_fc_add(struct app_params *app,
uint32_t pipeline_id,
struct pipeline_fc_key *key,
-   uint32_t port_id)
+   uint32_t port_id,
+   uint32_t flow_id)
 {
struct app_pipeline_fc *p;
struct app_pipeline_fc_flow *flow;
@@ -325,6 +327,7 @@ app_pipeline_fc_add(struct app_params *app,
req->subtype = PIPELINE_FC_MSG_REQ_FLOW_ADD;
app_pipeline_fc_key_convert(key, req->key, );
req->port_id = port_id;
+   req->flow_id = flow_id;

/* Send request and wait for response */
rsp = app_msg_send_recv(app, pipeline_id, req, MSG_TIMEOUT_DEFAULT);
@@ -348,6 +351,7 @@ app_pipeline_fc_add(struct app_params *app,
memset(>key, 0, sizeof(flow->key));
memcpy(>key, key, sizeof(flow->key));
flow->port_id = port_id;
+   flow->flow_id = flow_id;
flow->signature = signature;
flow->entry_ptr = rsp->entry_ptr;

@@ -370,6 +374,7 @@ app_pipeline_fc_add_bulk(struct app_params *app,
uint32_t pipeline_id,
struct pipeline_fc_key *key,
uint32_t *port_id,
+   uint32_t *flow_id,
uint32_t n_keys)
 {
struct app_pipeline_fc *p;
@@ -389,6 +394,7 @@ app_pipeline_fc_add_bulk(struct app_params *app,
if ((app == NULL) ||
(key == NULL) ||
(port_id == NULL) ||
+   (flow_id == NULL) ||
(n_keys == 0))
return -1;

@@ -496,6 +502,7 @@ app_pipeline_fc_add_bulk(struct app_params *app,
flow_req[i].key,
[i]);
flow_req[i].port_id = port_id[i];
+   flow_req[i].flow_id = flow_id[i];
}

req->type = PIPELINE_MSG_REQ_CUSTOM;
@@ -535,6 +542,7 @@ app_pipeline_fc_add_bulk(struct app_params *app,
for (i = 0; i < rsp->n_keys; i++) {
memcpy([i]->key, [i], sizeof(flow[i]->key));
flow[i]->port_id = port_id[i];
+   flow[i]->flow_id = flow_id[i];
flow[i]->signature = signature[i];
flow[i]->entry_ptr = flow_rsp[i].entry_ptr;

@@ -731,13 +739,15 @@ print_fc_qinq_flow(struct app_pipeline_fc_flow *flow)
 {
printf("(SVLAN = %" PRIu32 ", "
"CVLAN = %" PRIu32 ") => "
-   "Port = %" PRIu32 " "
+   "Port = %" PRIu32 ", "
+   "Flow ID = %" PRIu32 ", "
"(signature = 0x%08" PRIx32 ", "
"entry_ptr = %p)\n",

flow->key.key.qinq.svlan,
flow->key.key.qinq.cvlan,
flow->port_id,
+   flow->flow_id,
flow->signature,
flow->entry_ptr);
 }
@@ -750,7 +760,8 @@ print_fc_ipv4_5tuple_flow(struct app_pipeline_fc_flow *flow)
   "SP = %" PRIu32 ", "
   "DP = %" PRIu32 ", "
   "Proto = %" PRIu32 ") => "
-  "Port = %" PRIu32 " "
+  "Port = %" PRIu32 ", "
+  "Flow ID = %" PRIu32 " "
   "(signature = 0x%08" PRIx32 ", "
   "entry_ptr = %p)\n",

@@ -770,6 +781,7 @@ print_fc_ipv4_5tuple_flow(struct app_pipeline_fc_flow *flow)
   flow->key.key.ipv4_5tuple.proto,

   flow->port_id,
+  flow->flow_id,
   flow->signature,
   flow->entry_ptr);
 }
@@ -787,7 +799,8 @@ print_fc_ipv6_5tuple_flow(struct app_pipeline_fc_flow 
*flow) {
"SP = %" PRIu32 ", "
"DP = %" PRIu32 " "
"Proto = %" PRIu32 " "
-   "=> Port = %" PRIu32 " "

[dpdk-dev] [PATCH v5 resend 07/12] virtio: resolve for control queue

[Yuanhan Liu]

On Thu, Oct 08, 2015 at 10:51:02PM +0200, Steffen Bauch wrote:
> 
> 
> On 10/08/2015 05:32 PM, Nikita Kalyazin wrote:
> >Hi Yuanhan,
> >
> >
> >As I understand, the dead loop happened here (virtio_send_command):
> >while (vq->vq_used_cons_idx == vq->vq_ring.used->idx) {
> >   rte_rmb();
> >   usleep(100);
> >}
> >
> >Could you explain why wrong config reading caused that and how correct 
> >reading helps to avoid?

Wrong config reading results to wrong config->max_virtqueue_pairs, which
ends up with wrong ctrl vq index being set:

PMD: virtio_send_command(): vq->vq_queue_index = 37120

Note that you need enable CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT to see above
debug log.

That is to say we are waiting for the backend to consume a non-exist
queue, and that's how the dead loop comes.


> >
> Hi,
> 
> I just recognized that this dead loop is the same one that I have
> experienced (see
> http://dpdk.org/ml/archives/dev/2015-October/024737.html for
> reference). Just applying the changes in this patch (only 07/12)
> will not fix the dead loop at least in my setup.

Try to enable CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT, and dump more log?

--yliu

[dpdk-dev] [PATCH 8/8] librte_table: modify release notes and deprecation notice

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, October 12, 2015 3:24 PM
> To: Zhang, Roy Fan
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 8/8] librte_table: modify release notes and
> deprecation notice
> 
> If a v2 is needed, please squash the release notes changes with the API
> changes (patches 1 and 2).

Hi Thomas,

Could you clarify this? In general shouldn't we keep all 
lib/drivers/examples/doc changes in separate patches in the patchset?

John

[dpdk-dev] [PATCH 8/8] librte_table: modify release notes and deprecation notice

[Thomas Monjalon]

Hi and welcome,
(it seems to be your first patch on DPDK)

2015-09-25 23:33, roy.fan.zhang at intel.com:
> --- a/doc/guides/rel_notes/release_2_2.rst
> +++ b/doc/guides/rel_notes/release_2_2.rst
> @@ -95,6 +95,9 @@ ABI Changes
>  
>  * The LPM structure is changed. The deprecated field mem_location is removed.
>  
> +* Key mask parameter is added to the hash table parameter structure for
> +  8-byte key and 16-byte key extendible bucket and LRU tables. The
> +  deprecated field mem_location is removed.

It seems the last sentence is a wrong copy/paste.

If a v2 is needed, please squash the release notes changes with the API changes
(patches 1 and 2).

Thanks

[dpdk-dev] [PATCH v2 02/20] librte_ether: add fields from rte_pci_driver to rte_eth_dev_data

[Iremonger, Bernard]

Hi John,



> Hi Bernard,
> 
> Patch 02/20 doesn't compile without patch 03/20 also being applied:
> 
> 
> $ git log --pretty=oneline --abbrev-commit -2
> 0958ce7 librte_ether: add fields from rte_pci_driver to rte_eth_dev_data
> 30e65e6 librte_eal: add RTE_KDRV_NONE for vdevs
> 
> $ make T=x86_64-native-linuxapp-gcc -j install
> ...
> lib/librte_ether/rte_ethdev.c:3341:1: error: no previous prototype for
> 'rte_eth_copy_dev_info' [-Werror=missing-prototypes]
> cc1: all warnings being treated as errors
> 
> 
> John
> 
I have reworked patch 02/20 and 03/20  to fix this issue.
I will send a v3 patch set with the revised patches.

Regards,

Bernard.

[dpdk-dev] [PATCH v2 0/4]librte_table: add name parameter to lpm table

[Thomas Monjalon]

2015-09-17 16:13, Dumitrescu, Cristian:
> From: Singh, Jasvinder
> > This patchset links to ABI change announced for librte_table. For
> > lpm table, name parameter has been included in LPM table parameters
> > structure. It will eventually allow applications to create more
> > than one instances of lpm table, if required.
> > 
> > Changes in v2:
> > - rte_table_lpm_ipv6.c: removed name varibale from
> > rte_zmalloc_socket() and inserted that in rte_lpm6_create().
> 
> Acked-by: Cristian Dumitrescu 

Applied, thanks

[dpdk-dev] [PATCH v3] ip_pipeline: add flow id parameter to flow classification

[Singh, Jasvinder]

> -Original Message-
> From: Dumitrescu, Cristian
> Sent: Monday, October 12, 2015 4:47 PM
> To: Singh, Jasvinder; dev at dpdk.org
> Subject: RE: [PATCH v3] ip_pipeline: add flow id parameter to flow
> classification
> 
> 
> 
> > -Original Message-
> > From: Singh, Jasvinder
> > Sent: Monday, October 12, 2015 4:42 PM
> > To: dev at dpdk.org
> > Cc: Dumitrescu, Cristian
> > Subject: [PATCH v3] ip_pipeline: add flow id parameter to flow
> > classification
> >
> > *v3
> > fixed bug: changed LRU hash table operation to extendible bucket hash
> > table operation
> >
> > Signed-off-by: Jasvinder Singh 
> > ---
> 
> 
> Acked-by: Cristian Dumitrescu 
> 
> Jasvinder, next time we send new patch version with just a small
> modification (like this one), you can also include my Ack line from the
> previous version (just under the signoff line), as Thomas kindly suggested.

I will remember next time. Thanks.

[dpdk-dev] lib: added support for armv7 architecture

[Jan Viktorin]

I'am working on a new patch set patched by your ideas:

* user can select whether to implement timer by clock_gettime or PMU
* we use memcpy when NEON is unavailable
* we detect arm architecture (32/64) by AT_PLATFORM
* small modification of a memory barrier

However, I didn't test it yet, nor compile it. As it is quite huge, I will post
it to the mailing list after some testing is done. I've made it public at github
if somebody is interested... Comments are always welcome.


The following changes since commit 95b282191819edbe60956a43f385219251c158be:

  mk: Introduce ARMv7 architecture (2015-10-12 10:22:13 +0200)

are available in the git repository at:

  https://github.com/RehiveTech/dpdk.git arm-support-v2

for you to fetch changes up to b3b42bb120cb7811bbcc64598fb87e457b1c9ff1:

  arm: Disable usage of SSE optimized code in librte_acl (2015-10-12 15:42:31 
+0200)


Jan Viktorin (6):
  eal/arm: implement rdtsc by PMU or clock_gettime
  eal/arm: use vector memcpy only when NEON is enabled
  eal/arm: detect arm architecture in cpu flags
  eal/arm: rwlock support for ARM
  gcc/arm: avoid alignment errors to break build
  maintainers: claim responsibility for ARMv7

Vlastimil Kosar (9):
  eal/arm: atomic operations for ARM
  eal/arm: byte order operations for ARM
  eal/arm: cpu cycle operations for ARM
  eal/arm: prefetch operations for ARM
  eal/arm: spinlock operations for ARM (without HTM)
  eal/arm: vector memcpy for ARM
  eal/arm: cpu flag checks for ARM
  lpm/arm: implement rte_lpm_lookupx4 using rte_lpm_lookup_bulk on for-x86
  arm: Disable usage of SSE optimized code in librte_acl

 MAINTAINERS|   4 +
 app/test/test_cpuflags.c   |   5 +
 config/defconfig_arm-armv7-a-linuxapp-gcc  |   4 -
 lib/librte_acl/acl.h   |   2 +
 lib/librte_acl/rte_acl.c   |   8 +-
 lib/librte_acl/rte_acl_osdep.h |   2 +
 lib/librte_eal/common/include/arch/arm/rte_atomic.h| 256 
+
 lib/librte_eal/common/include/arch/arm/rte_byteorder.h | 148 
+
 lib/librte_eal/common/include/arch/arm/rte_cpuflags.h  | 180 
+++
 lib/librte_eal/common/include/arch/arm/rte_cycles.h| 121 

 lib/librte_eal/common/include/arch/arm/rte_memcpy.h| 325 
+++
 lib/librte_eal/common/include/arch/arm/rte_prefetch.h  |  61 
 lib/librte_eal/common/include/arch/arm/rte_rwlock.h|  40 
 lib/librte_eal/common/include/arch/arm/rte_spinlock.h  | 114 
++
 lib/librte_lpm/rte_lpm.h   |  71 ++
 mk/rte.cpuflags.mk |   6 ++
 mk/toolchain/gcc/rte.vars.mk   |   6 ++
 17 files changed, 1348 insertions(+), 5 deletions(-)
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_atomic.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_byteorder.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_cpuflags.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_cycles.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_memcpy.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_prefetch.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_rwlock.h
 create mode 100644 lib/librte_eal/common/include/arch/arm/rte_spinlock.h

Regards
Jan

On Mon, 12 Oct 2015 14:27:42 +0100
"Hunt, David"  wrote:

> Jan, I would suggest that we should plan to include your patch into the 
> DPDK 2.2 release. If there are any portions of our patch that you feel 
> may be beneficial to that, please feel free to merge into your patch. I 
> then suggest you release a v2 patch based on the best parts of both, 
> which we all can then review. Regards, Dave. P.S. Apologies for the 
> footer below, I'm working on getting it removed.
> 
> --
> 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.
> 

-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH v3] ip_pipeline: add flow id parameter to flow classification

[Dumitrescu, Cristian]

> -Original Message-
> From: Singh, Jasvinder
> Sent: Monday, October 12, 2015 4:42 PM
> To: dev at dpdk.org
> Cc: Dumitrescu, Cristian
> Subject: [PATCH v3] ip_pipeline: add flow id parameter to flow classification
> 
> *v3
> fixed bug: changed LRU hash table operation to
> extendible bucket hash table operation
> 
> Signed-off-by: Jasvinder Singh 
> ---


Acked-by: Cristian Dumitrescu 

Jasvinder, next time we send new patch version with just a small modification 
(like this one), you can also include my Ack line from the previous version 
(just under the signoff line), as Thomas kindly suggested.

[dpdk-dev] [PATCH 0/5] fixup ip pipeline examples

[Dumitrescu, Cristian]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Wednesday, October 7, 2015 5:43 PM
> To: Dumitrescu, Cristian; Stephen Hemminger
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/5] fixup ip pipeline examples
> 
> Hi,
> 
> 2015-09-09 18:35, Dumitrescu, Cristian:
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > > Lots of little trivial bugs/typos here.
> > > Let's not start users off with a bad example.
> >
> > Thanks very much for doing this work, Steve!
> >
> > I agree with most of the bug fixes here except a few, which I indicated in
> my reply to each individual patch.
> >
> > Do you want to resend or do you want us to integrate the fixes in our next
> patches? Whatever works best for you is fine with us.
> 
> Please, what are the news about this series?
> In case it's already merged in another series, please advertise it.
> Thanks

Stephen, are you planning to send a new revision of this series? Thanks, 
Cristian

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

[Wang Xiao W]

Signed-off-by: Wang Xiao W 
---
 doc/guides/rel_notes/release_2_2.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index 5687676..ab01ebb 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -4,6 +4,10 @@ DPDK Release 2.2
 New Features
 

+* **fm10k: Added TSO support.**
+
+  Added TSO support for both PF and VF.
+

 Resolved Issues
 ---
-- 
1.9.3

[dpdk-dev] [PATCH v2 1/2] fm10k: enable TSO support

[Wang Xiao W]

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

Signed-off-by: Wang Xiao W 
---
 drivers/net/fm10k/base/fm10k_osdep.h |  5 +
 drivers/net/fm10k/fm10k_ethdev.c |  3 ++-
 drivers/net/fm10k/fm10k_rxtx.c   | 21 ++---
 3 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/net/fm10k/base/fm10k_osdep.h 
b/drivers/net/fm10k/base/fm10k_osdep.h
index 64f09dc..d8f3da4 100644
--- a/drivers/net/fm10k/base/fm10k_osdep.h
+++ b/drivers/net/fm10k/base/fm10k_osdep.h
@@ -146,4 +146,9 @@ typedef intbool;
 #define fm10k_read_reg FM10K_READ_REG
 #endif

+#define FM10K_TSO_MINMSS \
+   (FM10K_DMA_CTRL_MINMSS_64 >> FM10K_DMA_CTRL_MINMSS_SHIFT)
+#define FM10K_TSO_MIN_HEADERLEN54
+#define FM10K_TSO_MAX_HEADERLEN192
+
 #endif /* _FM10K_OSDEP_H_ */
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index a69c990..b104fc2 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -937,7 +937,8 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
DEV_TX_OFFLOAD_VLAN_INSERT |
DEV_TX_OFFLOAD_IPV4_CKSUM  |
DEV_TX_OFFLOAD_UDP_CKSUM   |
-   DEV_TX_OFFLOAD_TCP_CKSUM;
+   DEV_TX_OFFLOAD_TCP_CKSUM   |
+   DEV_TX_OFFLOAD_TCP_TSO;

dev_info->hash_key_size = FM10K_RSSRK_SIZE * sizeof(uint32_t);
dev_info->reta_size = FM10K_MAX_RSS_INDICES;
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index d3f7b89..1bac28d 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -395,7 +395,7 @@ static inline void tx_free_descriptors(struct 
fm10k_tx_queue *q)
 static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, struct rte_mbuf *mb)
 {
uint16_t last_id;
-   uint8_t flags;
+   uint8_t flags, hdrlen;

/* always set the LAST flag on the last descriptor used to
 * transmit the packet */
@@ -420,7 +420,7 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, 
struct rte_mbuf *mb)
/* set checksum flags on first descriptor of packet. SCTP checksum
 * offload is not supported, but we do not explicitly check for this
 * case in favor of greatly simplified processing. */
-   if (mb->ol_flags & (PKT_TX_IP_CKSUM | PKT_TX_L4_MASK))
+   if (mb->ol_flags & (PKT_TX_IP_CKSUM | PKT_TX_L4_MASK | PKT_TX_TCP_SEG))
q->hw_ring[q->next_free].flags |= FM10K_TXD_FLAG_CSUM;

/* set vlan if requested */
@@ -432,6 +432,21 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, 
struct rte_mbuf *mb)
rte_cpu_to_le_64(MBUF_DMA_ADDR(mb));
q->hw_ring[q->next_free].buflen =
rte_cpu_to_le_16(rte_pktmbuf_data_len(mb));
+
+   if (mb->ol_flags & PKT_TX_TCP_SEG) {
+   hdrlen = mb->outer_l2_len + mb->outer_l3_len + mb->l2_len +
+   mb->l3_len + mb->l4_len;
+   if (q->hw_ring[q->next_free].flags & FM10K_TXD_FLAG_FTAG)
+   hdrlen += sizeof(struct fm10k_ftag);
+
+   if (likely((hdrlen >= FM10K_TSO_MIN_HEADERLEN) &&
+   (hdrlen <= FM10K_TSO_MAX_HEADERLEN) &&
+   (mb->tso_segsz >= FM10K_TSO_MINMSS))) {
+   q->hw_ring[q->next_free].mss = mb->tso_segsz;
+   q->hw_ring[q->next_free].hdrlen = hdrlen;
+   }
+   }
+
if (++q->next_free == q->nb_desc)
q->next_free = 0;

@@ -447,7 +462,7 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue *q, 
struct rte_mbuf *mb)
q->next_free = 0;
}

-   q->hw_ring[last_id].flags = flags;
+   q->hw_ring[last_id].flags |= flags;
 }

 uint16_t
-- 
1.9.3

[dpdk-dev] [PATCH v2 0/2] fm10k: enable TSO support

[Wang Xiao W]

v2:
* Updated release note for the new feature.

* Added "likely" in TSO parameters checking.

v1:
* Initial version for fm10k TSO feature.

Wang Xiao W (2):
  fm10k: enable TSO support
  doc: update release note for fm10k TSO support

 doc/guides/rel_notes/release_2_2.rst |  4 
 drivers/net/fm10k/base/fm10k_osdep.h |  5 +
 drivers/net/fm10k/fm10k_ethdev.c |  3 ++-
 drivers/net/fm10k/fm10k_rxtx.c   | 21 ++---
 4 files changed, 29 insertions(+), 4 deletions(-)

-- 
1.9.3

[dpdk-dev] [PATCH 2/2] igb: fix VF statistic wraparound handling macro

[Harry van Haaren]

Fix a misinterpreatation of VF statistic macro in e1000/igb.

Signed-off-by: Harry van Haaren 
---
 drivers/net/e1000/igb_ethdev.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 848ef6e..e3f7402 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -246,7 +246,11 @@ static void eth_igb_configure_msix_intr(struct rte_eth_dev 
*dev);
 #define UPDATE_VF_STAT(reg, last, cur)\
 { \
u32 latest = E1000_READ_REG(hw, reg); \
-   cur += latest - last; \
+   if(likely(latest > last)) {   \
+   cur += latest - last; \
+   } else {  \
+   cur += (UINT_MAX - last) + latest;\
+   } \
last = latest;\
 }

-- 
1.9.1

[dpdk-dev] [PATCH 1/2] ixgbe: fix VF statistic wraparound handling macro

[Harry van Haaren]

Fix a misinterpretation of VF stats in ixgbe

Signed-off-by: Harry van Haaren 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index ec2918c..d226e8d 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -329,10 +329,14 @@ static int ixgbe_timesync_read_tx_timestamp(struct 
rte_eth_dev *dev,
 /*
  * Define VF Stats MACRO for Non "cleared on read" register
  */
-#define UPDATE_VF_STAT(reg, last, cur) \
+#define UPDATE_VF_STAT(reg, last, cur)  \
 {   \
uint32_t latest = IXGBE_READ_REG(hw, reg);  \
-   cur += latest - last;   \
+   if(likely(latest > last)) { \
+   cur += latest - last;   \
+   } else {\
+   cur += (UINT_MAX - last) + latest;  \
+   }   \
last = latest;  \
 }

-- 
1.9.1

[dpdk-dev] [PATCH 0/2] fix vf statistic wraparound handling in macro

[Harry van Haaren]

The following two patches fix a misinterpretation of the cyclic
counters of igb and ixgbe VF. When the 32bit value wraps around,
the code now handles the wrapped new value appropriatly.

Harry van Haaren (2):
  ixgbe: fix VF statistic wraparound handling macro
  igb: fix VF statistic wraparound handling macro

 drivers/net/e1000/igb_ethdev.c   | 6 +-
 drivers/net/ixgbe/ixgbe_ethdev.c | 8 ++--
 2 files changed, 11 insertions(+), 3 deletions(-)

-- 
1.9.1

[dpdk-dev] lib: added support for armv7 architecture

[Hunt, David]

On 11/10/2015 22:17, Jan Viktorin wrote:

> Hello David, all,
>
> I am reviewing your patch for things to be included in the final ARMv7
> support... It is quite long, you know. We should probably break the
> potential discussion in shorter e-mails, a thread per topic. See my
> comments below.
>
> Regards
> Jan

Jan, I would suggest that we should plan to include your patch into the 
DPDK 2.2 release. If there are any portions of our patch that you feel 
may be beneficial to that, please feel free to merge into your patch. I 
then suggest you release a v2 patch based on the best parts of both, 
which we all can then review. Regards, Dave. P.S. Apologies for the 
footer below, I'm working on getting it removed.

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

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

[dpdk-dev] [PATCH v2 0/2] Fix build with kernel 4.2

[Ferruh Yigit]

On Mon, Oct 12, 2015 at 01:52:56PM +0100, Pablo de Lara wrote:
> Kernel 4.2 has introduced two new parameters in
> function ndo_bridge_netlink and therefore,
> DPDK does not build with it.
> 
> This patchset adds the necessary checks and
> rename a previous defined macro, in order
> to have a more meaningful name.
> 
> Changes in v2:
> - Split patch in two patches
> 
> Pablo de Lara (2):
>   kni: rename HAVE_NDO_BRIDGE_GETLINK_FILTER_MASK macro
>   kni: fix igb build with kernel 4.2
> 
>  lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c | 13 +
>  lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h  |  7 ++-
>  2 files changed, 15 insertions(+), 5 deletions(-)
> 
> -- 
> 2.1.0
> 

Series Acked-by: Ferruh Yigit 

[dpdk-dev] [PATCH] doc: fix pdf build warning

[John McNamara]

Fix a pdf doc build warning where a link wasn't recognised:

doc/guides/contributing/documentation.rst::
WARNING: unusable reference target found: inkscape.org

Signed-off-by: John McNamara 
---
 doc/guides/contributing/documentation.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/guides/contributing/documentation.rst 
b/doc/guides/contributing/documentation.rst
index 7c1eb41..7f5f061 100644
--- a/doc/guides/contributing/documentation.rst
+++ b/doc/guides/contributing/documentation.rst
@@ -477,7 +477,7 @@ Images
 * The DPDK documentation contains some legacy images in PNG format.
   These will be converted to SVG in time.

-* `Inkscape `_ is the recommended graphics editor for creating 
the images.
+* `Inkscape `_ is the recommended graphics editor for 
creating the images.
   Use some of the older images in ``doc/guides/prog_guide/img/`` as a 
template, for example ``mbuf1.svg``
   or ``ring-enqueue.svg``.

-- 
1.8.1.4

[dpdk-dev] [PATCH v2 2/2] kni: fix igb build with kernel 4.2

[Pablo de Lara]

Kernel 4.2 has introduced two new parameters in ndo_bridge_getlink,
which breaks DPDK compilation.

Linux: 7d4f8d87 ("switchdev: ad VLAN support for ports
bridge-getlink")

This patch adds the necessary checks to fix it.

Signed-off-by: Pablo de Lara 
---
 lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c | 5 +
 lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h  | 5 +
 2 files changed, 10 insertions(+)

diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c 
b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
index 0494780..b330b20 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
@@ -2276,7 +2276,12 @@ static int igb_ndo_bridge_getlink(struct sk_buff *skb, 
u32 pid, u32 seq,

 #ifdef HAVE_NDO_FDB_ADD_VID
 #ifdef HAVE_NDO_BRIDGE_GETLINK_NLFLAGS
+#ifdef HAVE_NDO_BRIDGE_GETLINK_FILTER_MASK_VLAN_FILL
+   return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode, 0, 0,
+   nlflags, filter_mask, NULL);
+#else
return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode, 0, 0, nlflags);
+#endif /* HAVE_NDO_BRIDGE_GETLINK_FILTER_MASK_VLAN_FILL */
 #else
return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode, 0, 0);
 #endif /* HAVE_NDO_BRIDGE_GETLINK_NLFLAGS */
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h 
b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
index e4fad18..5f45b8b 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
@@ -3901,4 +3901,9 @@ skb_set_hash(struct sk_buff *skb, __u32 hash, 
__always_unused int type)
 /* ndo_bridge_getlink adds new nlflags parameter */
 #define HAVE_NDO_BRIDGE_GETLINK_NLFLAGS
 #endif /* >= 4.1.0 */
+
+#if ( LINUX_VERSION_CODE >= KERNEL_VERSION(4,2,0) )
+/* ndo_bridge_getlink adds new filter_mask and vlan_fill parameters */
+#define HAVE_NDO_BRIDGE_GETLINK_FILTER_MASK_VLAN_FILL
+#endif /* >= 4.2.0 */
 #endif /* _KCOMPAT_H_ */
-- 
2.1.0

[dpdk-dev] [PATCH v2 0/2] Fix build with kernel 4.2

[Pablo de Lara]

Kernel 4.2 has introduced two new parameters in
function ndo_bridge_netlink and therefore,
DPDK does not build with it.

This patchset adds the necessary checks and
rename a previous defined macro, in order
to have a more meaningful name.

Changes in v2:
- Split patch in two patches

Pablo de Lara (2):
  kni: rename HAVE_NDO_BRIDGE_GETLINK_FILTER_MASK macro
  kni: fix igb build with kernel 4.2

 lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c | 13 +
 lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h  |  7 ++-
 2 files changed, 15 insertions(+), 5 deletions(-)

-- 
2.1.0

[dpdk-dev] dpdk 2.1.0: 40gig ports link is down

[Shaham Fridenberg]

Hey all,

I upgraded from dpdk 1.8.0 to 2.1.0 and now my 40gig ports (rte_i40e_pmd) link 
is down.

Any idea what might be the issue?

Thanks,
Shaham

[dpdk-dev] [PATCH 2/2] virtio: change io privilege level as early as possible

[Stephen Hemminger]

I think David's patch should be in 2.2 (and 2.1.X if that starts out).
It solves the problem for both link state and secondary processes.

It may need to be updated for the current drivers/net/virtio layout.

[dpdk-dev] DPDK hash function related question

[Yeddula, Avinash]

Hi Cristian,
I have configured the hash function and it compile fine with "warnings". Since 
librte_hash vs librte_table is 32bit vs 64bit.

librte_hash library :
/** Type of function that can be used for calculating the hash value. */
typedef uint32_t (*rte_hash_function)(const void *key, uint32_t key_len, 
uint32_t init_val);

librte_table library:
typedef uint64_t (*rte_table_hash_op_hash) (void *key,  uint32_t key_size, 
uint64_t seed);

I could use one of these hash functions. This is one option, but our first 
priority is  to use crc hash or cukoo hash.
https://github.com/scylladb/dpdk/blob/master/examples/ip_pipeline/pipeline/hash_func.h

We do not want to have those warning in our code. What do you suggest ?

Thanks
-Avinash

-Original Message-
From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com] 
Sent: Tuesday, September 22, 2015 3:05 AM
To: Yeddula, Avinash; dev at dpdk.org; Bly, Mike
Subject: RE: DPDK hash function related question

Hi Avinash,

Yes, the hash function is configurable.

Are you using a DPDK release older than 2.1? In DPDK we moved away from 
test_hash to CRC-based hashes. Please take a look at DPDK release 2.1 
examples/ip_pipeline application: in pipeline_flow_classification_be.c, we use 
CRC-based hash functions defined in file hash_func.h from the same folder.

Regards,
Cristian

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yeddula, Avinash
> Sent: Tuesday, September 22, 2015 1:34 AM
> To: dev at dpdk.org; Bly, Mike
> Subject: [dpdk-dev] DPDK hash function related question
> 
> Hello All,
> 
> I'm DPDK extensible bucket hash in the rte_table library of packet 
> framework. My question is related to the actual hash function that 
> computes the hash signature.
> 
> All the available examples have initialized it to test_hash.   I do not see 
> any
> hash function available in rte_table library , that computes the 
> actual signature
> 
> 
> 
> struct rte_table_hash_ext_params   hash_table_params = {
> 
> .key_size = TABLE_ENTRY_KEY_SIZE,
> 
> .n_keys = TABLE_MAX_SIZE,
> 
> .n_buckets = TABLE_MAX_BUCKET_COUNT,
> 
> .n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
> 
> .f_hash = test_hash,
> 
> .seed = 0,
> 
> .signature_offset = 0;
> 
> .key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
> 
> };
> 
> 
> 
> So, I wanted to use hash functions from DPDK rte_hash library. This is 
> what I'm doing and looking at the code this looks ok to me.
> 
> I'm at least a week or 2 away from testing this part of the code. I 
> wanted to confirm that, there is no fundamental flaw in using the DPDK 
> rte_hash library and rte_table library like this. Could someone confirm this 
> please ?
> 
> 
> 
> #define DEFAULT_HASH_FUNC rte_hash_crc
> 
> 
> 
> struct rte_table_hash_ext_params   hash_table_params = {
> 
> .key_size = TABLE_ENTRY_KEY_SIZE,
> 
> .n_keys = TABLE_MAX_SIZE,
> 
> .n_buckets = TABLE_MAX_BUCKET_COUNT,
> 
> .n_buckets_ext = TABLE_MAX_EXT_BUCKET_COUNT,
> 
> .f_hash = DEFAULT_HASH_FUNC ,
> 
> .seed = 0,
> 
> .signature_offset = 0;
> 
> .key_offset = __builtin_offsetof(struct metadata_t, tbl_key),
> 
> };
> 
> 
> 
> Thanks
> 
> -Avinash
> 

[dpdk-dev] kni: fix igb build with kernel 4.2

[De Lara Guarch, Pablo]

> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Monday, October 12, 2015 1:50 PM
> To: De Lara Guarch, Pablo; dev at dpdk.org
> Subject: [dpdk-dev] kni: fix igb build with kernel 4.2
> 
> From: "De Lara Guarch, Pablo" 
> 
> Kernel 4.2 has introduced two new parameters in ndo_bridge_getlink,
> which breaks DPDK compilation.
> 
> Linux: 7d4f8d87 ("switchdev: ad VLAN support for ports bridge-getlink")
> 
> This patch adds the necessary checks to fix it.
> 
> Signed-off-by: Pablo de Lara 

NACK this and previous patch. I was trying to send a v2 of this.
Sorry for the spam!

[dpdk-dev] Notes from project governance meeting at DPDK Userspace

[Thomas Monjalon]

Thanks Dave for the good summary.
Some comments below.

2015-10-11 01:36, Dave Neary:
> Keith raised the issue of general throughput of patches, and the number
> of unreviewed/wait state patches: need to actively scale the process.
> 
> Stephen: How about identifying reviewers, and Thomas designates lead
> reviewer for each patch? Allows scaling of review, while allowing Thomas
> to have last word. Alternative proposals are to have joint "maintainers"
> all of whom can commit patches, subject to certain constraints (don't
> commit your own code), or subsystem maintainers, establishing a
> hierarchy of trust so that Thomas can just scan and accept reviews 90%
> of the time.
> 
> Thomas: Need many reviewers, but there should be one committer per tree.

Some maintainers are already identified in this file:
http://dpdk.org/browse/dpdk/tree/MAINTAINERS
It is expected that the maintainers review every patches touching their
area (with exceptions for minor changes). They should also participate
in discussions to get consensus.
Reviews from non-maintainers are also very welcome.
Important features and fixes which are not properly reviewed should not
be integrated.
Someone in the room said it is the role of the patch author to get a
review. I agree.
Until now, patches from maintainers were accepted even if not reviewed.
Should it be changed?

In order to scale, some maintainers could become committers of a sub-tree.
The granularity of the sub-trees can evolve with growth of the project.
It seems a good idea to start with trees for drivers/net, drivers/crypto
and packet framework. It is not clear yet how EAL and core libraries can
benefit from any sub-tree.

> Chris: Do we have enough ppl with skills to be reviewers? If not, how do
> we get to that point?

Contributors must be motivated enough to get some time and, in some cases,
to get the green light from their management.
Some private discussions revealed that the lack of involvement is often due
to some management issues.

> Venky: Performance requires a specific skill set, not everyone has the
> skills, but slow patch review has an opportunity cost, and we can
> minimise cost of "bad" reviews with good CI performance tests that catch
> regressions

Yes having a good distributed CI will help. But it cannot replace reviews
for the quality and design considerations.

> How do we maintain review velocity when maintainer is unavailable (eg.
> on vacation)? How does it happen in Linux?
> 
> - Linus delegates - names "locum" maintainer while he is away. Stephen
> volunteered to do it for a week or two when necessary.

Thanks Stephen.

> Thomas: Subsystem maintainers carry review weight when maintainer is out.
> Stephen: Subsystem maintainers are reviewers, need high level of trust
> to be a top level maintainer.

Having a -next tree is another way of basing its work on an up-to-date tree
without waiting reviews.

> Thomas - Subtrees can live in DPDK git tree, makes it easier to manage
> merges afterwards. 2 volunteer subtree maintainers - Declan for crypto,
> Kevin for (not noted). Is it an issue if only Intel people are subtree
> maintainers? Venky: Yes, should have others.

About company sharing: it would be very nice to have more patches reviewed
by someone working for a different company than the author's one.
Considering making at least one review, when waiting for integration of its
patch, would be a good start.

>   - Some discussion around whether we should limit to one project per
> stack? Venky: Prefers not to
>   - Chris: How do decisions on new projects get made?

My understanding is that some new projects/layers can be added under the
dpdk.org umbrella. So different implementations of a DPDK layer will be
hosted in different dpdk.org git trees. But some implementations cannot
move there, e.g. ovs-dpdk.
What about https://01.org/spdk?
http://www.seastar-project.org?
https://github.com/rumpkernel/drv-netif-dpdk?
https://01.org/intel-data-plane-performance-demonstrators?

> We finished the discussion with a brief conversation on whether we
> should maintain certain branches for a long time.

1.8.0, 2.0.0, 2.1.0, the last digit can be used for stable branches.

> Bruce: Adds a lot of overhead
> Venky: Can do point releases on some branches
> Stephen: Prepared to "volunteer" someone from Brocade, because they need
> to maintain an older release anyway.

You just need to send me a SSH key and the version to maintain in order to
have a dedicated git tree.
Then the fixes should be preferably backported from the main tree.

Thanks everybody for the useful discussions.

[dpdk-dev] Accurate timestamps in received packets

[Montorsi, Francesco]

Hi John, 
Thanks for your reply.

> -Original Message-
> From: Mcnamara, John [mailto:john.mcnamara at intel.com]
> AFAIK, timestamping of every packet isn't supported by ixgbe/i40e nics and I
> don't know about non-Intel nics. It was supported for some(?) igb nics and
> hence the patch you linked to. Also, there isn't any DPDK API to
> enable/disable it even if it is supported by the nic.

What a pity, that's a bad news for me. 
Another question in case you know: AFAIUI ixgbe/i40e devices receive packets in 
burst/sequences. What's the timeout for flushing the receive queue?
In other words, if I send a single packet to the PHY of the NIC, after how much 
time will the Intel network controller will stop waiting for further packets 
(to put in the same "burst") and send that single packet to the CPU?

Thanks,
Francesco

[dpdk-dev] Network Stack discussion notes from 2015 DPDK Userspace

[Avi Kivity]

On 10/10/2015 02:19 AM, Wiles, Keith wrote:
> Here are some notes from the DPDK Network Stack discussion, I can remember 
> please help me fill in anything I missed.
>
> Items I remember we talked about:
>
>*   The only reason for a DPDK TCP/IP stack is for performance and 
> possibly lower latency
>   *   Meaning the developer is willing to re-write or write his 
> application to get the best performance.
>*   A TCP/IPv4/v6 stack is the minimum stack we need to support 
> applications linked with DPDK.
>   *   SCTP is also another protocol that maybe required
>   *   TCP is the primary protocol, usage model for most use cases
>   *   Stack must be able to terminate TCP traffic to an application 
> linked to DPDK
>*   For DPDK the customer is looking for fast applications and is willing 
> to write the application just for DPDK network stack
>   *   Converting an existing application could  be done, but the design 
> is for performance and may require a lot of changes to an application
>   *   Using an application API that is not Socket is fine for high 
> performance and maybe the only way we get best performance.
>   *   Need to supply a Socket layer interface as a option if customer is 
> willing to take a performance hit instead of rewriting the application
>*   Native application acceleration is desired, but not required when 
> using DPDK network stack
>*   We have two projects related to network stack in DPDK
>   *   The first one is porting some TCP/IP stack to DPDK plus it needs to 
> give a reasonable performance increase over native Linux applications
>  *   The stack code needs to be BSD/MIT like licensed (Open Sourced)
>  *   The stack should be up to date with the latest RFCs or at least 
> close
>  *   A stack could be written for DPDK (not using a existing code 
> base) and its environment for best performance
>  *   Need to be able to configure the DPDK stack(s) from the Linux 
> command line tools if possible
>  *   Need a DPDK specific application layer API for application to 
> interface with the network stack
>  *   Could have a socket layer API on top of the specific API for 
> applications needing to use sockets (not expected to be the best performance)
>   *   The second item is figuring out a new IPC for East/West traffic 
> within the same system.
>  *   The design needs to improve performance between applications and 
> be transparent to the application when the remote end is not on the same 
> system.
>  *   The new IPC path should be agnostic to local or remote end points
>  *   Needs to be very fast compared to current Linux IPC designs. 
> (Will OVS work here?)

Basically, seastar [1] matches this exactly.  Its TCP stack, unlike most 
stacks, is sharded -- there is a separate stack running on each core 
(but with a single IP address), no locking, zero-copy for both transmit 
and receive.  It has a fast IPC between cores (all data sharing in 
seastar is via IPC queues; locks or atomic RMW operations are not 
used).  There is also an RPC subsystem that can be used for inter-node 
communications.  We've seen 7X performance improvements over the Linux 
TCP stack when coding a simple HTTP server.

Of course, it's not all roses. Seastar is written in C++, and the higher 
layers are asynchronous, so there's a high barrier to entry for dpdk 
developers.  Maybe it can't be merged outright, but perhaps it can 
provide some inspiration.

(seastar supports subsets of TCP, UDP, ICMP, and DHCP over IPv4; no IPv6 
support)

[1] https://github.com/scylladb/seastar

> Did I miss any details or comments, please reply and help me correct the 
> comment or understanding.
>
> Thanks for everyone attending and packing into a small space.
>
> ?
> Regards,
> ++Keith Wiles
> Intel Corporation

[dpdk-dev] Unable to compile DPDK 2.1

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Gal Sagie
> Sent: Monday, October 12, 2015 9:20 AM
> To: 
> Subject: [dpdk-dev] Unable to compile DPDK 2.1
> 
> Hello all,
> 
> I was trying to help someone compile DPDK2.1 on Ubuntu 14.04, we were
> following the instructions on http://www.dpdk.org/doc/quick-start
> 
> We installed libpcap using "sudo apt-get install libpcap-dev"
> 
> When starting the 'make' the following error occured:
> 
> /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/i686-linux-gnu/4.8/../../../libpcap.so
>  when searching for -lpcap /usr/bin/ld:
> skipping incompatible //usr/lib/libpcap.so when searching for -lpcap
> /usr/bin/ld: cannot find -lpcap
> 
> Anyone can please help with this?

Hi,

That looks like a 32/64 bit incompatibility between the lib and app.

What is your full make line or what exports did you do prior to running make? 
Also what OS are you on (see commands below).

I tried with a clean 64 bit Ubuntu 14.04 install in a VM and was able to build 
dpdk with pcap support:


# uname -a
Linux vbox-ubuntu 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux
root at vbox-ubuntu:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04.1 LTS
Release:14.04
Codename:   trusty


# apt-get update
# apt-get install git
# apt-cache search pcap
# apt-get install libpcap-dev


# locate libpcap.so
/usr/lib/x86_64-linux-gnu/libpcap.so.0.8
/usr/lib/x86_64-linux-gnu/libpcap.so.1.5.3


$ git clone http://dpdk.org/git/dpdk

$ cd dpdk/

$ vi config/common_linuxapp

$ git diff
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 0de43d5..cccbda4 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -267,7 +267,7 @@ CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16
 #
 # Compile software PMD backed by PCAP files
 #
-CONFIG_RTE_LIBRTE_PMD_PCAP=n
+CONFIG_RTE_LIBRTE_PMD_PCAP=y

$ make T=x86_64-native-linuxapp-gcc -j install
...
Build complete [x86_64-native-linuxapp-gcc]

[dpdk-dev] Unable to compile DPDK 2.1

[Gal Sagie]

Hello all,

I was trying to help someone compile DPDK2.1 on Ubuntu 14.04, we were
following
the instructions on http://www.dpdk.org/doc/quick-start

We installed libpcap using "sudo apt-get install libpcap-dev"

When starting the 'make' the following error occured:

/usr/bin/ld: skipping incompatible
/usr/lib/gcc/i686-linux-gnu/4.8/../../../libpcap.so
 when searching for -lpcap /usr/bin/ld:
skipping incompatible //usr/lib/libpcap.so when searching for -lpcap
/usr/bin/ld: cannot find -lpcap

Anyone can please help with this?


Thanks
Gal.

[dpdk-dev] [PATCH 2/2] igb: fix VF statistic wraparound handling macro

[Roger B. Melton]

ack

On 10/12/15 9:33 AM, Harry van Haaren wrote:
> Fix a misinterpreatation of VF statistic macro in e1000/igb.
>
> Signed-off-by: Harry van Haaren 
> ---
>   drivers/net/e1000/igb_ethdev.c | 6 +-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
> index 848ef6e..e3f7402 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -246,7 +246,11 @@ static void eth_igb_configure_msix_intr(struct 
> rte_eth_dev *dev);
>   #define UPDATE_VF_STAT(reg, last, cur)\
>   { \
>   u32 latest = E1000_READ_REG(hw, reg); \
> - cur += latest - last; \
> + if(likely(latest > last)) {   \
> + cur += latest - last; \
> + } else {  \
> + cur += (UINT_MAX - last) + latest;\
> + } \
>   last = latest;\
>   }
>   

-- 
  
|Roger B. Melton|  |  Cisco Systems  |
|CPP Software  :|::|: 7100 Kit Creek Rd  |
|+1.919.476.2332 phone:|||:  :|||:RTP, NC 27709-4987 |
|+1.919.392.1094 fax   .:|||:..:|||:. rmelton at cisco.com  |
||
| This email may contain confidential and privileged material for the|
| sole use of the intended recipient. Any review, use, distribution  |
| or disclosure by others is strictly prohibited. If you are not the |
| intended recipient (or authorized to receive for the recipient),   |
| please contact the sender by reply email and delete all copies of  |
| this message.  |
||
| For corporate legal information go to: |
| http://www.cisco.com/web/about/doing_business/legal/cri/index.html |
|__ http://www.cisco.com |

[dpdk-dev] [PATCH v2 07/20] pcap: remove pci device driver

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bernard Iremonger
> Sent: Monday, October 5, 2015 11:30 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 07/20] pcap: remove pci device driver
> 
> remove rte_pcap_pmd and pci_dev.
> initialise dev_flags, driver, drv_name, kdrv and numa_node fields in
> eth_dev data
> 
> Signed-off-by: Bernard Iremonger 

Tested-by: John McNamara 
Acked-by:  John McNamara 

[dpdk-dev] [PATCH v2 02/20] librte_ether: add fields from rte_pci_driver to rte_eth_dev_data

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bernard Iremonger
> Sent: Monday, October 5, 2015 11:30 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 02/20] librte_ether: add fields from
> rte_pci_driver to rte_eth_dev_data
> 
> add dev_flags to rte_eth_dev_data, add macros for dev_flags.
> add kdrv to rte_eth_dev_data.
> add numa_node to rte_eth_dev_data.
> add drv_name to rte_eth_dev_data.
> use dev_type to distinguish between vdev's and pdev's.
> remove pci_dev branches.


Hi Bernard,

Patch 02/20 doesn't compile without patch 03/20 also being applied:


$ git log --pretty=oneline --abbrev-commit -2 
0958ce7 librte_ether: add fields from rte_pci_driver to rte_eth_dev_data
30e65e6 librte_eal: add RTE_KDRV_NONE for vdevs

$ make T=x86_64-native-linuxapp-gcc -j install
...
lib/librte_ether/rte_ethdev.c:3341:1: error: no previous prototype for
'rte_eth_copy_dev_info' [-Werror=missing-prototypes]
cc1: all warnings being treated as errors


John

[dpdk-dev] [PATCH 1/2] ixgbe: fix VF statistic wraparound handling macro

[Roger B. Melton]

ack

On 10/12/15 9:33 AM, Harry van Haaren wrote:
> Fix a misinterpretation of VF stats in ixgbe
>
> Signed-off-by: Harry van Haaren 
> ---
>   drivers/net/ixgbe/ixgbe_ethdev.c | 8 ++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index ec2918c..d226e8d 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -329,10 +329,14 @@ static int ixgbe_timesync_read_tx_timestamp(struct 
> rte_eth_dev *dev,
>   /*
>* Define VF Stats MACRO for Non "cleared on read" register
>*/
> -#define UPDATE_VF_STAT(reg, last, cur)   \
> +#define UPDATE_VF_STAT(reg, last, cur)  \
>   {   \
>   uint32_t latest = IXGBE_READ_REG(hw, reg);  \
> - cur += latest - last;   \
> + if(likely(latest > last)) { \
> + cur += latest - last;   \
> + } else {\
> + cur += (UINT_MAX - last) + latest;  \
> + }   \
>   last = latest;  \
>   }
>   

-- 
  
|Roger B. Melton|  |  Cisco Systems  |
|CPP Software  :|::|: 7100 Kit Creek Rd  |
|+1.919.476.2332 phone:|||:  :|||:RTP, NC 27709-4987 |
|+1.919.392.1094 fax   .:|||:..:|||:. rmelton at cisco.com  |
||
| This email may contain confidential and privileged material for the|
| sole use of the intended recipient. Any review, use, distribution  |
| or disclosure by others is strictly prohibited. If you are not the |
| intended recipient (or authorized to receive for the recipient),   |
| please contact the sender by reply email and delete all copies of  |
| this message.  |
||
| For corporate legal information go to: |
| http://www.cisco.com/web/about/doing_business/legal/cri/index.html |
|__ http://www.cisco.com |

[dpdk-dev] [PATCH v3 8/8] mk: Add rule for installing runtime files

[Jan Blunck]

On Fri, Oct 2, 2015 at 12:15 PM, Panu Matilainen  wrote:
> On 10/01/2015 03:11 AM, Mario Carrillo wrote:
>>
>> Add hierarchy-file support to the DPDK libraries, modules,
>> binary files, nic bind files and documentation,
>> when invoking "make install-fhs" (filesystem hierarchy standard)
>> runtime files will be by default installed in:
>> $(DESTDIR)/$(BIN_DIR) where BIN_DIR=/usr/bin (binary files)
>> $(DESTDIR)/$(SBIN_DIR) where SBIN_DIR=/usr/sbin/dpdk_nic_bind (nic bind
>> files)
>> $(DESTDIR)/$(DOC_DIR) where DOC_DIR=/usr/share/doc/dpdk (documentation)
>> $(DESTDIR)/$(LIB_DIR)  (libraries)
>> if the architecture is 64 bits then LIB_DIR=/usr/lib64
>> else LIB_DIR=/usr/lib
>> $(DESTDIR)/$(KERNEL_DIR) (modules)
>> if RTE_EXEC_ENV=linuxapp then
>> KERNEL_DIR=/lib/modules/$(uname -r)/build
>> else KERNEL_DIR=/boot/modules
>> All directory variables mentioned above can be overridden.
>> This hierarchy is based on:
>> http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
>>
>
> Hmm, I think there's a slight misunderstanding here.
>
> What I meant earlier by install-sdk and install-fhs is to preserve the
> current behavior of "make install" as "make install-sdk" and have "make
> install-fhs" behave like normal OSS app on "make install", which installs
> everything (both devel and runtime parts)

>From my point of view it would make sense let 'make install' do the
right thing from
a user perspective (application, library, distribution). The standard
workflow of 'make install'
is well known and supported by many build environments.

One way that could work is to detect the fact that the SDK files are
already installed (e.g.
via $RTE_SDK != $(pwd) ) and in that case skipping the install of them.

Thanks,
Jan

> This patch series eliminates the current behavior of "make install"
> entirely. I personally would not miss it at all, but there likely are people
> relying on it since its quite visibly documented and all. So I think the
> idea was to introduce a separate FHS-installation target and then deal with
> the notion of default behaviors etc separately.
>
> I guess it was already this way in v2 of the series, apologies for missing
> it there.
>
> - Panu -

[dpdk-dev] [PATCH v2 5/5] doc: modify release notes and deprecation notice for table and pipeline

[Thomas Monjalon]

2015-10-12 07:53, Azarewicz, PiotrX T:
> Hi Thomas,
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > Hi Maciej,
> > 
> > 2015-09-11 12:31, Maciej Gajdzica:
> > > --- a/lib/librte_pipeline/rte_pipeline_version.map
> > > +++ b/lib/librte_pipeline/rte_pipeline_version.map
> > > @@ -29,3 +29,11 @@ DPDK_2.1 {
> > >   rte_pipeline_table_stats_read;
> > >
> > >  } DPDK_2.0;
> > > +
> > > +DPDK_2.2 {
> > > + global:
> > > +
> > > + rte_pipeline_table_entry_add_bulk;
> > > + rte_pipeline_table_entry_delete_bulk;
> > > +
> > > +} DPDK_2.1;
> > 
> > The previous block was DPDK_2.0 for this library.
> > So I think you should inherit from it, not DPDK_2.1 which doesn't exist in 
> > this
> > context.
> 
> The previous block was DPDK_2.1 :
> 
> DPDK_2.1 {
>   global:
> 
>   rte_pipeline_port_in_stats_read;
>   rte_pipeline_port_out_stats_read;
>   rte_pipeline_table_stats_read;
> 
> } DPDK_2.0;
> 
> So I think this patch is okay.
> Correct me if I am wrong with my understanding, please.

You are perfectly right.
Sorry for the confusion.

[dpdk-dev] dpdk 2.1.0: 40gig ports link is down

[Stephen Hemminger]

On Mon, 12 Oct 2015 17:04:01 +
Shaham Fridenberg  wrote:

> Hey Stephen,
> 
> Thanks for your help.
> 
> I tried updating i40e driver to the latest version (from 1.0.11-k to 
> 1.3.39.1) but it didn't help.
> 
> By 'Compile i40e with DEBUG flag' you mean adding "CONFIG_RTE_LOG_LEVEL=8" to 
> defconfig_x86_64-wsm-linuxapp-gcc (assuming I'm compiling for westmere)?
> 
> Also, is there any log file generated in that case?
> 
> Thanks,
> Shaham

I was thinking of firmware update tool, which you need to run on Linux (w/o 
DPDK)
 
https://downloadcenter.intel.com/download/24769/NVM-Update-Utility-for-Intel-Ethernet-Converged-Network-Adapter-XL710-X710-Series

In current DPDK, the config stuff is in common_linuxapp

[dpdk-dev] [PATCH v5 resend 07/12] virtio: resolve for control queue

[Xie, Huawei]

On 10/12/2015 10:33 AM, Xie, Huawei wrote:
> On 10/12/2015 9:39 AM, Yuanhan Liu wrote:
>> On Thu, Oct 08, 2015 at 10:51:02PM +0200, Steffen Bauch wrote:
>>> On 10/08/2015 05:32 PM, Nikita Kalyazin wrote:
 Hi Yuanhan,


 As I understand, the dead loop happened here (virtio_send_command):
 while (vq->vq_used_cons_idx == vq->vq_ring.used->idx) {
> Nikita:
>
> Didn't review the whole patch, but happen to  find a serious problem in
> the code snippet here, as volatile isn't used, compiler will assume the
> memory will not be changed outside and do only one comparison.
>
> Try add volatile prefix, and it might fix your problem.
Read other mails in this thread, if the specific queue is due to wrong
queue index.
Fix the volatile in the code, otherwise if first time no match, the code
will go to dead loop directly and no chance to compare again in
optimized code.
   rte_rmb();
   usleep(100);
 }

 Could you explain why wrong config reading caused that and how correct 
 reading helps to avoid?
>> Wrong config reading results to wrong config->max_virtqueue_pairs, which
>> ends up with wrong ctrl vq index being set:
>>
>> PMD: virtio_send_command(): vq->vq_queue_index = 37120
>>
>> Note that you need enable CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT to see above
>> debug log.
>>
>> That is to say we are waiting for the backend to consume a non-exist
>> queue, and that's how the dead loop comes.
>>
>>
>>> Hi,
>>>
>>> I just recognized that this dead loop is the same one that I have
>>> experienced (see
>>> http://dpdk.org/ml/archives/dev/2015-October/024737.html for
>>> reference). Just applying the changes in this patch (only 07/12)
>>> will not fix the dead loop at least in my setup.
>> Try to enable CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT, and dump more log?
>>
>>  --yliu
>>
>

[dpdk-dev] [PATCHv4 4/9] null: virtual dynamic rss configuration

[Jastrzebski, MichalX K]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa
> Sent: Tuesday, September 29, 2015 4:25 AM
> To: Kulasek, TomaszX; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCHv4 4/9] null: virtual dynamic rss configuration
> 
> On 2015/07/16 2:26, Tomasz Kulasek wrote:
> > This implementation allows to set and read RSS configuration for null
> > device, and is used to validate right values propagation over the slaves,
> > in test units for dynamic RSS configuration for bonding.
> >
> > Signed-off-by: Tomasz Kulasek 
> > ---
> >  drivers/net/null/rte_eth_null.c |  116
> +++
> >  1 file changed, 116 insertions(+)
> >
> > diff --git a/drivers/net/null/rte_eth_null.c 
> > b/drivers/net/null/rte_eth_null.c
> > index 39ffcde..f393422 100644
> > --- a/drivers/net/null/rte_eth_null.c
> > +++ b/drivers/net/null/rte_eth_null.c
> > +static int
> > +eth_rss_hash_update(struct rte_eth_dev *dev, struct rte_eth_rss_conf
> *rss_conf)
> > +{
> > +   struct pmd_internals *internal = dev->data->dev_private;
> > +
> > +   rte_spinlock_lock(>rss_lock);
> > +
> > +   if ((rss_conf->rss_hf & internal->flow_type_rss_offloads) != 0)
> > +   dev->data->dev_conf.rx_adv_conf.rss_conf.rss_hf =
> > +   rss_conf->rss_hf & internal-
> >flow_type_rss_offloads;
> > +
> > +   if (rss_conf->rss_key)
> > +   memcpy(internal->rss_key, rss_conf->rss_key, 40);
> > +
> > +   rte_spinlock_unlock(>rss_lock);
> > +
> > +   return 0;
> > +}
> > +
> > +static int
> > +eth_rss_hash_conf_get(struct rte_eth_dev *dev,
> > +   struct rte_eth_rss_conf *rss_conf)
> > +{
> > +   struct pmd_internals *internal = dev->data->dev_private;
> > +
> > +   rte_spinlock_lock(>rss_lock);
> > +
> > +   rss_conf->rss_hf = dev->data-
> >dev_conf.rx_adv_conf.rss_conf.rss_hf;
> > +   if (rss_conf->rss_key)
> > +   memcpy(rss_conf->rss_key, internal->rss_key, 40);
> > +
> > +   rte_spinlock_unlock(>rss_lock);
> > +
> > +   return 0;
> > +}
> > +
> >  static const struct eth_dev_ops ops = {
> > .dev_start = eth_dev_start,
> > .dev_stop = eth_dev_stop,
> > @@ -436,6 +547,11 @@ eth_dev_null_create(const char *name,
> > internals->packet_copy = packet_copy;
> > internals->numa_node = numa_node;
> >
> > +   internals->flow_type_rss_offloads =  ETH_RSS_PROTO_MASK;
> > +   internals->reta_size = RTE_DIM(internals->reta_conf) *
> RTE_RETA_GROUP_SIZE;
> > +
> > +   memcpy(internals->rss_key, default_rss_key, 40);
> > +
> > eth_drv->pci_drv.name = drivername;
> >
> > pci_dev->numa_node = numa_node;
> 
> Hi Thomasz,
> 
> I am just curious. Is it possible to use rte_memcpy instead of memcpy?
> if we can, rte_memcpy may be faster.
> 
> Tetsuya

Hi Tetsuya,
Could You please review v5 that Tomasz sent and if You agree with this 
implementation could You also ACK this patch-set?

[dpdk-dev] [PATCH 1/2] ixgbe: fix VF statistic wraparound handling macro

[Alexander Duyck]

On 10/12/2015 06:33 AM, Harry van Haaren wrote:
> Fix a misinterpretation of VF stats in ixgbe
>
> Signed-off-by: Harry van Haaren 
> ---
>   drivers/net/ixgbe/ixgbe_ethdev.c | 8 ++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c 
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index ec2918c..d226e8d 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -329,10 +329,14 @@ static int ixgbe_timesync_read_tx_timestamp(struct 
> rte_eth_dev *dev,
>   /*
>* Define VF Stats MACRO for Non "cleared on read" register
>*/
> -#define UPDATE_VF_STAT(reg, last, cur)   \
> +#define UPDATE_VF_STAT(reg, last, cur)  \
>   {   \
>   uint32_t latest = IXGBE_READ_REG(hw, reg);  \
> - cur += latest - last;   \
> + if(likely(latest > last)) { \
> + cur += latest - last;   \
> + } else {\
> + cur += (UINT_MAX - last) + latest;  \
> + }   \
>   last = latest;  \
>   }
>   

 From what I can tell your math is adding an off by one error.  You 
should probably be using UINT_MAX as a mask for the result, not as a 
part of the calculation itself.

So the correct way to compute this would be "cur += (latest - last) & 
UINT_MAX".  Also the mask approach should be faster as it avoids any 
conditional jumps.

- Alex

[dpdk-dev] dpdk 2.1.0: 40gig ports link is down

[Stephen Hemminger]

On Mon, 12 Oct 2015 13:29:42 +
Shaham Fridenberg  wrote:

> Hey all,
> 
> I upgraded from dpdk 1.8.0 to 2.1.0 and now my 40gig ports (rte_i40e_pmd) 
> link is down.
> 
> Any idea what might be the issue?
> 
> Thanks,
> Shaham

Compile i40e with DEBUG flag enabled in config and make sure LOGLEVEL
is set to 8 to show debug output.

It maybe something related to firmware versions.
Make sure you have updated firmware (see Intel tool).

[dpdk-dev] Accurate timestamps in received packets

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Montorsi, Francesco
> Sent: Monday, October 12, 2015 9:26 AM
> To: Lu, Wenzhuo; dev at dpdk.org
> Subject: Re: [dpdk-dev] Accurate timestamps in received packets
> 
> Hi Wenzhuo,
> 
> > -Original Message-
> > From: Lu, Wenzhuo [mailto:wenzhuo.lu at intel.com]
> >
> > Why not
> > searching ieee1588 in the dpdk git repository?  Surely you'll find
> > something.
>
> I tried using IEEE 1588 without success. In particular I enabled it at
> build-time of DPDK and then after calling rte_eth_rx_burst() I tried
> calling rte_eth_timesync_read_tx_timestamp() to get a timestamp from the
> port_id used to receive a burst of packets, but the function always
> returns with an error.
> Moreover, even if the function succeeded I need a timestamp for every
> incoming packet, not a single timestamp for the whole burst of received
> packets... do you know how I could achieve that?

Hi,

IEEE1588 isn't suitable for this. It is a timesync protocol rather than a 
timestamping function.

AFAIK, timestamping of every packet isn't supported by ixgbe/i40e nics and I 
don't know about non-Intel nics. It was supported for some(?) igb nics and 
hence the patch you linked to. Also, there isn't any DPDK API to enable/disable 
it even if it is supported by the nic.

John

[dpdk-dev] [PATCH v2 5/5] doc: modify release notes and deprecation notice for table and pipeline

[Azarewicz, PiotrX T]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, October 12, 2015 10:23 AM
> To: Azarewicz, PiotrX T
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 5/5] doc: modify release notes and
> deprecation notice for table and pipeline
> 
> 2015-10-12 07:53, Azarewicz, PiotrX T:
> > Hi Thomas,
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > > Hi Maciej,
> > >
> > > 2015-09-11 12:31, Maciej Gajdzica:
> > > > --- a/lib/librte_pipeline/rte_pipeline_version.map
> > > > +++ b/lib/librte_pipeline/rte_pipeline_version.map
> > > > @@ -29,3 +29,11 @@ DPDK_2.1 {
> > > > rte_pipeline_table_stats_read;
> > > >
> > > >  } DPDK_2.0;
> > > > +
> > > > +DPDK_2.2 {
> > > > +   global:
> > > > +
> > > > +   rte_pipeline_table_entry_add_bulk;
> > > > +   rte_pipeline_table_entry_delete_bulk;
> > > > +
> > > > +} DPDK_2.1;
> > >
> > > The previous block was DPDK_2.0 for this library.
> > > So I think you should inherit from it, not DPDK_2.1 which doesn't
> > > exist in this context.
> >
> > The previous block was DPDK_2.1 :
> >
> > DPDK_2.1 {
> > global:
> >
> > rte_pipeline_port_in_stats_read;
> > rte_pipeline_port_out_stats_read;
> > rte_pipeline_table_stats_read;
> >
> > } DPDK_2.0;
> >
> > So I think this patch is okay.
> > Correct me if I am wrong with my understanding, please.
> 
> You are perfectly right.
> Sorry for the confusion.

No problem, thank for the answer.
Piotr

[dpdk-dev] Accurate timestamps in received packets

[Montorsi, Francesco]

Hi Wenzhuo,

> -Original Message-
> From: Lu, Wenzhuo [mailto:wenzhuo.lu at intel.com]
> Hi Francesco,
> Why not searching ieee1588 in the dpdk git repository?  Surely you'll find
> something.
I tried using IEEE 1588 without success. In particular I enabled it at 
build-time of DPDK and then after calling rte_eth_rx_burst() I tried calling 
rte_eth_timesync_read_tx_timestamp() to get a timestamp from the port_id used 
to receive a burst of packets, but the function always returns with an error. 
Moreover, even if the function succeeded I need a timestamp for every incoming 
packet, not a single timestamp for the whole burst of received packets... do 
you know how I could achieve that?

Thanks,
Francesco

[dpdk-dev] [PATCH v2 2/5] pipeline: added bulk add/delete functions for table

[Azarewicz, PiotrX T]

Hi Thomas,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, October 8, 2015 1:42 PM
> To: Gajdzica, MaciejX T
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 2/5] pipeline: added bulk add/delete
> functions for table
> 
> 2015-09-11 12:31, Maciej Gajdzica:
> > +/**
> > + * Pipeline table entry delete bulk
> > + *
> > + * @param p
> > + *   Handle to pipeline instance
> > + * @param table_id
> > + *   Table ID (returned by previous invocation of pipeline table create)
> > + * @param keys
> > + *   Array containing table entry keys
> > + * @param key_found
> > + *   On successful invocation, key_found for every item in the array is set
> to
> > + *   TRUE (value different than 0) if key was found in the table before the
> > + *   delete operation and to FALSE (value 0) if not
> > + * @param entries
> > + *   If entries pointer is NULL, this pointer is ignored for every entry 
> > found.
> > + *   Else, after successful invocation, if specific key is found in the 
> > table
> > + *   and entry points to a valid buffer, the table entry contents (as it 
> > was
> > + *   before the delete was performed) is copied to this buffer.
> > + * @return
> > + *   0 on success, error code otherwise
> > + */
> > +int rte_pipeline_table_entry_delete_bulk(struct rte_pipeline *p,
> > +   uint32_t table_id,
> > +   void **keys,
> > +   uint32_t n_keys,
> > +   int *key_found,
> > +   struct rte_pipeline_table_entry **entries);
> 
> The parameter n_keys is not documented.
> Doxygen is reporting the error.


Thanks for the finding.

Piotr

[dpdk-dev] [PATCH v2 5/5] doc: modify release notes and deprecation notice for table and pipeline

[Azarewicz, PiotrX T]

Hi Thomas,

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, October 8, 2015 1:42 PM
> To: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 5/5] doc: modify release notes and
> deprecation notice for table and pipeline
> 
> Hi Maciej,
> 
> 2015-09-11 12:31, Maciej Gajdzica:
> > The LIBABIVER number is incremented for table and pipeline libraries.
> > The release notes is updated and the deprecation announce is removed.
> [...]
> > --- a/lib/librte_pipeline/rte_pipeline_version.map
> > +++ b/lib/librte_pipeline/rte_pipeline_version.map
> > @@ -29,3 +29,11 @@ DPDK_2.1 {
> > rte_pipeline_table_stats_read;
> >
> >  } DPDK_2.0;
> > +
> > +DPDK_2.2 {
> > +   global:
> > +
> > +   rte_pipeline_table_entry_add_bulk;
> > +   rte_pipeline_table_entry_delete_bulk;
> > +
> > +} DPDK_2.1;
> 
> The previous block was DPDK_2.0 for this library.
> So I think you should inherit from it, not DPDK_2.1 which doesn't exist in 
> this
> context.

The previous block was DPDK_2.1 :

DPDK_2.1 {
global:

rte_pipeline_port_in_stats_read;
rte_pipeline_port_out_stats_read;
rte_pipeline_table_stats_read;

} DPDK_2.0;

So I think this patch is okay.
Correct me if I am wrong with my understanding, please.

Thanks,
Piotr

[dpdk-dev] lib: added support for armv7 architecture

[Jan Viktorin]

Hello David, all,

I am reviewing your patch for things to be included in the final ARMv7
support... It is quite long, you know. We should probably break the
potential discussion in shorter e-mails, a thread per topic. See my
comments below.

Regards
Jan

On Fri,  2 Oct 2015 22:50:02 +0100
David Hunt  wrote:

> From: Amruta Zende 
> 
> Signed-off-by: Amruta Zende 
> Signed-off-by: David Hunt 
> 
> ---
> MAINTAINERS|5 +
>  config/defconfig_arm-native-linuxapp-gcc   |   56 
>  .../common/include/arch/arm/rte_atomic.h   |  269 
> 
>  .../common/include/arch/arm/rte_byteorder.h|  146 +++
>  .../common/include/arch/arm/rte_cpuflags.h |  138 ++
>  .../common/include/arch/arm/rte_cycles.h   |   77 ++
>  .../common/include/arch/arm/rte_memcpy.h   |  101 
>  .../common/include/arch/arm/rte_prefetch.h |   64 +
>  .../common/include/arch/arm/rte_rwlock.h   |   70 +
>  .../common/include/arch/arm/rte_spinlock.h |  116 +

I do not know yet, how different is the ARMv8 support, how it
integrates with the ARMv7 part... Will we have a single directory "arm"?

>  lib/librte_eal/common/include/arch/arm/rte_vect.h  |   37 +++
>  lib/librte_eal/linuxapp/Makefile   |3 +
>  lib/librte_eal/linuxapp/arm_pmu/Makefile   |   52 
>  lib/librte_eal/linuxapp/arm_pmu/rte_enable_pmu.c   |   83 ++
>  mk/arch/arm/rte.vars.mk|   58 +
>  mk/machine/armv7-a/rte.vars.mk |   63 +
>  mk/toolchain/gcc/rte.vars.mk   |8 +-
>  17 files changed, 1343 insertions(+), 3 deletions(-)
>  create mode 100644 config/defconfig_arm-native-linuxapp-gcc
>  create mode 100644 lib/librte_eal/common/include/arch/arm/rte_atomic.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm/rte_byteorder.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm/rte_cpuflags.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm/rte_cycles.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm/rte_memcpy.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm/rte_prefetch.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm/rte_rwlock.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm/rte_spinlock.h
>  create mode 100644 lib/librte_eal/common/include/arch/arm/rte_vect.h
>  create mode 100755 lib/librte_eal/linuxapp/arm_pmu/Makefile
>  create mode 100644 lib/librte_eal/linuxapp/arm_pmu/rte_enable_pmu.c
>  create mode 100644 mk/arch/arm/rte.vars.mk
>  create mode 100644 mk/machine/armv7-a/rte.vars.mk
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 080a8e8..9d99d53 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -124,6 +124,11 @@ IBM POWER
>  M: Chao Zhu 
>  F: lib/librte_eal/common/include/arch/ppc_64/
>  
> +Arm V7
> +M: Amrute Zende 
> +M: David Hunt 
> +F: lib/librte_eal/common/include/arch/arm/

We were discussing the ARM maintainer with Thomas Manjalon. As Dave
seems, he is not going to do the maintanance in a long-term, I can take
care of the ARM maintanance as well. However, I will not have a proper
ARMv8 machine available for some time.

> +
>  Intel x86
>  M: Bruce Richardson 
>  M: Konstantin Ananyev 
> diff --git a/config/defconfig_arm-native-linuxapp-gcc 
> b/config/defconfig_arm-native-linuxapp-gcc

This is interesting. Should we have a configuration for "arm" or better
for "armv7" or "armv7-a" or even more specifically for
"cortex-a9/15/..."?

> new file mode 100644
> index 000..159aa36
> --- /dev/null
> +++ b/config/defconfig_arm-native-linuxapp-gcc
> @@ -0,0 +1,56 @@
> +#   BSD LICENSE
> +#
> +#   Copyright(c) 2015 Intel Corporation. All rights reserved.
> +#
> [...]
> +#
> +
> +#include "common_linuxapp"
> +
> +CONFIG_RTE_MACHINE="armv7-a"
> +
> +CONFIG_RTE_ARCH="arm"
> +CONFIG_RTE_ARCH_ARM32=y
> +CONFIG_RTE_ARCH_32=y
> +
> +CONFIG_RTE_TOOLCHAIN="gcc"
> +CONFIG_RTE_TOOLCHAIN_GCC=y
> +
> +CONFIG_RTE_FORCE_INTRINSICS=y
> +CONFIG_RTE_LIBRTE_VHOST=n
> +CONFIG_RTE_LIBRTE_KNI=n
> +CONFIG_RTE_KNI_KMOD=n

I could see a note somewhere that KNI is for 64-bit systems only. Am I
right? Would it be possible to have KNI for ARM?

> +CONFIG_RTE_LIBRTE_LPM=n
> +CONFIG_RTE_LIBRTE_ACL=n
> +CONFIG_RTE_LIBRTE_SCHED=n
> +CONFIG_RTE_LIBRTE_PORT=n
> +CONFIG_RTE_LIBRTE_PIPELINE=n
> +CONFIG_RTE_LIBRTE_TABLE=n

The libraries compiles (expect of LPM and ACL due to SSE issues). So
some of them will be enabled as default.

> +CONFIG_RTE_IXGBE_INC_VECTOR=n
> +CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
> +CONFIG_RTE_LIBRTE_CXGBE_PMD=n
> +
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic.h 
> b/lib/librte_eal/common/include/arch/arm/rte_atomic.h
> new file mode 100644
> index 000..2a7339c
> --- /dev/null
> +++ b/lib/librte_eal/common/include/arch/arm/rte_atomic.h
> @@ -0,0 +1,269 @@
> +/*-
> + *   BSD LICENSE
> + *
> + *