* [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Björn Töpel @ 2016-11-09 8:23 UTC (permalink / raw)
To: dev
Cc: qian.q.xu, lei.a.yao, jingjing.wu, thomas.monjalon,
Björn Töpel
Commit 1bbcc5d21129 ("i40evf: report error for unsupported CRC
stripping config") broke l3fwd, since it was forcing that CRC was
kept. Now, if i40evf is running, CRC stripping will be enabled.
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
examples/l3fwd/main.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 7223e773107e..b60278794135 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -906,6 +906,14 @@ main(int argc, char **argv)
n_tx_queue = MAX_TX_QUEUE_PER_PORT;
printf("Creating queues: nb_rxq=%d nb_txq=%u... ",
nb_rx_queue, (unsigned)n_tx_queue );
+ rte_eth_dev_info_get(portid, &dev_info);
+ if (dev_info.driver_name &&
+ strcmp(dev_info.driver_name, "net_i40e_vf") == 0) {
+ /* i40evf require that CRC stripping is enabled. */
+ port_conf.rxmode.hw_strip_crc = 1;
+ } else {
+ port_conf.rxmode.hw_strip_crc = 0;
+ }
ret = rte_eth_dev_configure(portid, nb_rx_queue,
(uint16_t)n_tx_queue, &port_conf);
if (ret < 0)
@@ -946,7 +954,6 @@ main(int argc, char **argv)
printf("txq=%u,%d,%d ", lcore_id, queueid, socketid);
fflush(stdout);
- rte_eth_dev_info_get(portid, &dev_info);
txconf = &dev_info.default_txconf;
if (port_conf.rxmode.jumbo_frame)
txconf->txq_flags = 0;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] net/ixgbe: fix link never come up problem with x552
From: Lu, Wenzhuo @ 2016-11-09 8:14 UTC (permalink / raw)
To: Zhao1, Wei, dev@dpdk.org; +Cc: Zhao1, Wei
In-Reply-To: <1478674828-41011-1-git-send-email-wei.zhao1@intel.com>
Hi,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wei Zhao
> Sent: Wednesday, November 9, 2016 3:00 PM
> To: dev@dpdk.org
> Cc: Zhao1, Wei
> Subject: [dpdk-dev] [PATCH] net/ixgbe: fix link never come up problem with x552
>
> From: zhao wei <wei.zhao1@intel.com>
>
> The links never coming up with DPDK16.11 when bring up x552 NIC, device id is
> 15ac.This is caused by delete some code which casing removes X550em SFP iXFI
> setup for the drivers in function ixgbe_setup_mac_link_sfp_x550em().Fix
> methord is recover the deleted code.
>
> Fixes: 1726b9cd9c40 ("net/ixgbe/base: remove X550em SFP iXFI setup")
>
> Signed-off-by: zhao wei <wei.zhao1@intel.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Thanks for the patch. It's a critical issue. We need to fix it. I'll report it to our kernel driver developers.
^ permalink raw reply
* [PATCH] net/ixgbe: fix link never come up problem with x552
From: Wei Zhao @ 2016-11-09 7:00 UTC (permalink / raw)
To: dev; +Cc: zhao wei
From: zhao wei <wei.zhao1@intel.com>
The links never coming up with DPDK16.11 when bring up x552 NIC,
device id is 15ac.This is caused by delete some code which casing
removes X550em SFP iXFI setup for the drivers in function
ixgbe_setup_mac_link_sfp_x550em().Fix methord is recover
the deleted code.
Fixes: 1726b9cd9c40 ("net/ixgbe/base: remove X550em SFP iXFI setup")
Signed-off-by: zhao wei <wei.zhao1@intel.com>
---
drivers/net/ixgbe/base/ixgbe_x550.c | 57 ++++++++++++++++++++++++++++++-------
1 file changed, 46 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c b/drivers/net/ixgbe/base/ixgbe_x550.c
index 87d4302..acb8140 100644
--- a/drivers/net/ixgbe/base/ixgbe_x550.c
+++ b/drivers/net/ixgbe/base/ixgbe_x550.c
@@ -2762,18 +2762,53 @@ s32 ixgbe_setup_mac_link_sfp_x550em(struct ixgbe_hw *hw,
if (ret_val != IXGBE_SUCCESS)
return ret_val;
- /* Configure internal PHY for KR/KX. */
- ixgbe_setup_kr_speed_x550em(hw, speed);
-
- /* Configure CS4227 LINE side to proper mode. */
- reg_slice = IXGBE_CS4227_LINE_SPARE24_LSB +
- (hw->bus.lan_id << 12);
- if (setup_linear)
- reg_val = (IXGBE_CS4227_EDC_MODE_CX1 << 1) | 0x1;
- else
+ if (!(hw->phy.nw_mng_if_sel & IXGBE_NW_MNG_IF_SEL_INT_PHY_MODE)) {
+ /* Configure CS4227 LINE side to 10G SR. */
+ reg_slice = IXGBE_CS4227_LINE_SPARE22_MSB +
+ (hw->bus.lan_id << 12);
+ reg_val = IXGBE_CS4227_SPEED_10G;
+ ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
+ reg_val);
+
+ reg_slice = IXGBE_CS4227_LINE_SPARE24_LSB +
+ (hw->bus.lan_id << 12);
reg_val = (IXGBE_CS4227_EDC_MODE_SR << 1) | 0x1;
- ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
- reg_val);
+ ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
+ reg_val);
+
+ /* Configure CS4227 for HOST connection rate then type. */
+ reg_slice = IXGBE_CS4227_HOST_SPARE22_MSB +
+ (hw->bus.lan_id << 12);
+ reg_val = (speed & IXGBE_LINK_SPEED_10GB_FULL) ?
+ IXGBE_CS4227_SPEED_10G : IXGBE_CS4227_SPEED_1G;
+ ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
+ reg_val);
+
+ reg_slice = IXGBE_CS4227_HOST_SPARE24_LSB +
+ (hw->bus.lan_id << 12);
+ if (setup_linear)
+ reg_val = (IXGBE_CS4227_EDC_MODE_CX1 << 1) | 0x1;
+ else
+ reg_val = (IXGBE_CS4227_EDC_MODE_SR << 1) | 0x1;
+ ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
+ reg_val);
+
+ /* Setup XFI internal link. */
+ ret_val = ixgbe_setup_ixfi_x550em(hw, &speed);
+ } else {
+ /* Configure internal PHY for KR/KX. */
+ ixgbe_setup_kr_speed_x550em(hw, speed);
+
+ /* Configure CS4227 LINE side to proper mode. */
+ reg_slice = IXGBE_CS4227_LINE_SPARE24_LSB +
+ (hw->bus.lan_id << 12);
+ if (setup_linear)
+ reg_val = (IXGBE_CS4227_EDC_MODE_CX1 << 1) | 0x1;
+ else
+ reg_val = (IXGBE_CS4227_EDC_MODE_SR << 1) | 0x1;
+ ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
+ reg_val);
+ }
return ret_val;
}
--
2.5.5
^ permalink raw reply related
* [PATCH] net/ixgbe: fix link never come up problem with x552
From: Wei Zhao @ 2016-11-09 6:59 UTC (permalink / raw)
To: dev; +Cc: zhao wei
From: zhao wei <wei.zhao1@intel.com>
The links never coming up with DPDK16.11 when bring up x552 NIC,
device id is 15ac.This is caused by delete some code which casing
removes X550em SFP iXFI setup for the drivers in function
ixgbe_setup_mac_link_sfp_x550em().Fix methord is recover
the deleted code.
Fixes: 1726b9cd9c40 ("net/ixgbe/base: remove X550em SFP iXFI setup")
Signed-off-by: zhao wei <wei.zhao1@intel.com>
---
drivers/net/ixgbe/base/ixgbe_x550.c | 57 ++++++++++++++++++++++++++++++-------
1 file changed, 46 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c b/drivers/net/ixgbe/base/ixgbe_x550.c
index 87d4302..acb8140 100644
--- a/drivers/net/ixgbe/base/ixgbe_x550.c
+++ b/drivers/net/ixgbe/base/ixgbe_x550.c
@@ -2762,18 +2762,53 @@ s32 ixgbe_setup_mac_link_sfp_x550em(struct ixgbe_hw *hw,
if (ret_val != IXGBE_SUCCESS)
return ret_val;
- /* Configure internal PHY for KR/KX. */
- ixgbe_setup_kr_speed_x550em(hw, speed);
-
- /* Configure CS4227 LINE side to proper mode. */
- reg_slice = IXGBE_CS4227_LINE_SPARE24_LSB +
- (hw->bus.lan_id << 12);
- if (setup_linear)
- reg_val = (IXGBE_CS4227_EDC_MODE_CX1 << 1) | 0x1;
- else
+ if (!(hw->phy.nw_mng_if_sel & IXGBE_NW_MNG_IF_SEL_INT_PHY_MODE)) {
+ /* Configure CS4227 LINE side to 10G SR. */
+ reg_slice = IXGBE_CS4227_LINE_SPARE22_MSB +
+ (hw->bus.lan_id << 12);
+ reg_val = IXGBE_CS4227_SPEED_10G;
+ ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
+ reg_val);
+
+ reg_slice = IXGBE_CS4227_LINE_SPARE24_LSB +
+ (hw->bus.lan_id << 12);
reg_val = (IXGBE_CS4227_EDC_MODE_SR << 1) | 0x1;
- ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
- reg_val);
+ ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
+ reg_val);
+
+ /* Configure CS4227 for HOST connection rate then type. */
+ reg_slice = IXGBE_CS4227_HOST_SPARE22_MSB +
+ (hw->bus.lan_id << 12);
+ reg_val = (speed & IXGBE_LINK_SPEED_10GB_FULL) ?
+ IXGBE_CS4227_SPEED_10G : IXGBE_CS4227_SPEED_1G;
+ ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
+ reg_val);
+
+ reg_slice = IXGBE_CS4227_HOST_SPARE24_LSB +
+ (hw->bus.lan_id << 12);
+ if (setup_linear)
+ reg_val = (IXGBE_CS4227_EDC_MODE_CX1 << 1) | 0x1;
+ else
+ reg_val = (IXGBE_CS4227_EDC_MODE_SR << 1) | 0x1;
+ ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
+ reg_val);
+
+ /* Setup XFI internal link. */
+ ret_val = ixgbe_setup_ixfi_x550em(hw, &speed);
+ } else {
+ /* Configure internal PHY for KR/KX. */
+ ixgbe_setup_kr_speed_x550em(hw, speed);
+
+ /* Configure CS4227 LINE side to proper mode. */
+ reg_slice = IXGBE_CS4227_LINE_SPARE24_LSB +
+ (hw->bus.lan_id << 12);
+ if (setup_linear)
+ reg_val = (IXGBE_CS4227_EDC_MODE_CX1 << 1) | 0x1;
+ else
+ reg_val = (IXGBE_CS4227_EDC_MODE_SR << 1) | 0x1;
+ ret_val = hw->link.ops.write_link(hw, hw->link.addr, reg_slice,
+ reg_val);
+ }
return ret_val;
}
--
2.5.5
^ permalink raw reply related
* Re: [PATCH v2] net/virtio: cache Rx/Tx offload ability check
From: Yuanhan Liu @ 2016-11-09 5:24 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev
In-Reply-To: <06d3ff0d-d145-597b-09af-c86c93d5cbfd@6wind.com>
On Tue, Nov 08, 2016 at 09:43:14AM +0100, Olivier Matz wrote:
> Hi Yuanhan,
>
> On 11/04/2016 03:29 PM, Yuanhan Liu wrote:
> > It's not a good idea to do the check of whether Rx/Tx offload is
> > enabled at the data path. Instead, we could do the check at init
> > stage and store the result, so that we could avoid the check again
> > and again at the critical datapath.
> >
> > Cc: Olivier Matz <olivier.matz@6wind.com>
> > Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> > ---
> > v2: - rebase on top of the bug fix patches
> > - define rx/tx_offload as uint8_t instead of int
> >
> > drivers/net/virtio/virtio_ethdev.c | 19 +++++++++++++++++++
> > drivers/net/virtio/virtio_pci.h | 2 ++
> > drivers/net/virtio/virtio_rxtx.c | 31 +++++--------------------------
> > 3 files changed, 26 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
> > index 1505f67..2adae58 100644
> > --- a/drivers/net/virtio/virtio_ethdev.c
> > +++ b/drivers/net/virtio/virtio_ethdev.c
> > @@ -1188,6 +1188,22 @@ rx_func_get(struct rte_eth_dev *eth_dev)
> > eth_dev->rx_pkt_burst = &virtio_recv_pkts;
> > }
> >
> > +static inline int
> > +rx_offload_enabled(struct virtio_hw *hw)
> > +{
> > + return vtpci_with_feature(hw, VIRTIO_NET_F_GUEST_CSUM) ||
> > + vtpci_with_feature(hw, VIRTIO_NET_F_GUEST_TSO4) ||
> > + vtpci_with_feature(hw, VIRTIO_NET_F_GUEST_TSO6);
> > +}
> > +
> > +static inline int
> > +tx_offload_enabled(struct virtio_hw *hw)
> > +{
> > + return vtpci_with_feature(hw, VIRTIO_NET_F_CSUM) ||
> > + vtpci_with_feature(hw, VIRTIO_NET_F_HOST_TSO4) ||
> > + vtpci_with_feature(hw, VIRTIO_NET_F_HOST_TSO6);
> > +}
>
> Do we need these functions to be inlined?
Nope, it was done simply by copy & paste. I could remove them in future
version.
> It looks better to do like this, but out of curiosity, do you see a
> performance improvement?
I didn't bother to have a try: I'd assume it brings no (at least
no obvious) improvements.
--yliu
^ permalink raw reply
* Re: [dpdk-moving] Draft Project Charter
From: O'Driscoll, Tim @ 2016-11-08 18:23 UTC (permalink / raw)
To: Matt Spencer, Vincent JARDIN, moving@dpdk.org; +Cc: dev@dpdk.org
In-Reply-To: <AM5PR0801MB20516E1B9DF6B283C5897B2395A60@AM5PR0801MB2051.eurprd08.prod.outlook.com>
Agreed. I think we should use next week's meeting to walk through the document, discuss the comments, and agree on the changes.
As I said before, the two-level structure that's in there at the moment is a placeholder, but it does allow for one level of contribution to the shared lab and a lower level contribution for marketing purposes.
Tim
From: Matt Spencer [mailto:Matt.Spencer@arm.com]
Sent: Tuesday, November 8, 2016 6:18 PM
To: O'Driscoll, Tim <tim.odriscoll@intel.com>; Vincent JARDIN <vincent.jardin@6wind.com>; moving@dpdk.org
Cc: dev@dpdk.org
Subject: Re: [dpdk-moving] [dpdk-dev] Draft Project Charter
I think we need a discussion about the levels of membership - possibly at next weeks meeting?
My feeling is that we need more than one level
- One to enable contribution of hardware to the lab, as the lab will add cost to the overall project budget
- A second to enable contribution to the marketing aspects of the project and to allow association for marketing purposes
Calling these Gold and Silver is fine with me, but as I say, lets discuss this at next weeks meeting.
Matt
________________________________
From: moving <moving-bounces@dpdk.org<mailto:moving-bounces@dpdk.org>> on behalf of O'Driscoll, Tim <tim.odriscoll@intel.com<mailto:tim.odriscoll@intel.com>>
Sent: 08 November 2016 03:57:36
To: Vincent JARDIN; moving@dpdk.org<mailto:moving@dpdk.org>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>
Subject: Re: [dpdk-moving] [dpdk-dev] Draft Project Charter
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, November 8, 2016 11:41 AM
> To: moving@dpdk.org<mailto:moving@dpdk.org>
> Cc: dev@dpdk.org<mailto:dev@dpdk.org>
> Subject: Re: [dpdk-dev] [dpdk-moving] Draft Project Charter
>
> Tim,
>
> Thanks for your draft, but it is not a good proposal. It is not written
> in the spirit that we have discussed in Dublin:
> - you create the status of "Gold" members that we do not want from
> Linux Foundation,
As I said in the email, I put in two levels of membership as a placeholder. The first thing we need to decide is if we want to have a budget and membership, or if we want the OVS model with 0 budget and no membership. We can discuss that at today's meeting.
If we do want a membership model then we'll need to decide if everybody contributes at the same rate or if we support multiple levels. So, for now, the text on having two levels is just an example to show what a membership model might look like.
> - you start with "DPDK's first $1,000,000", it is far from the $O
> that we agreed based on OVS model.
That's just standard text that I see in all the LF charters. It's even in the OVS charter (http://openvswitch.org/charter/charter.pdf) even though they have 0 budget. I assumed it's standard text for the LF. I'm sure Mike Dolan can clarify.
>
> Please, explain why you did change it?
>
> Thank you,
> Vincent
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* Re: [dpdk-moving] Draft Project Charter
From: Matt Spencer @ 2016-11-08 18:18 UTC (permalink / raw)
To: O'Driscoll, Tim, Vincent JARDIN, moving@dpdk.org; +Cc: dev@dpdk.org
In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA6760E5AC@IRSMSX108.ger.corp.intel.com>
I think we need a discussion about the levels of membership - possibly at next weeks meeting?
My feeling is that we need more than one level
- One to enable contribution of hardware to the lab, as the lab will add cost to the overall project budget
- A second to enable contribution to the marketing aspects of the project and to allow association for marketing purposes
Calling these Gold and Silver is fine with me, but as I say, lets discuss this at next weeks meeting.
Matt
________________________________
From: moving <moving-bounces@dpdk.org> on behalf of O'Driscoll, Tim <tim.odriscoll@intel.com>
Sent: 08 November 2016 03:57:36
To: Vincent JARDIN; moving@dpdk.org
Cc: dev@dpdk.org
Subject: Re: [dpdk-moving] [dpdk-dev] Draft Project Charter
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, November 8, 2016 11:41 AM
> To: moving@dpdk.org
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-moving] Draft Project Charter
>
> Tim,
>
> Thanks for your draft, but it is not a good proposal. It is not written
> in the spirit that we have discussed in Dublin:
> - you create the status of "Gold" members that we do not want from
> Linux Foundation,
As I said in the email, I put in two levels of membership as a placeholder. The first thing we need to decide is if we want to have a budget and membership, or if we want the OVS model with 0 budget and no membership. We can discuss that at today's meeting.
If we do want a membership model then we'll need to decide if everybody contributes at the same rate or if we support multiple levels. So, for now, the text on having two levels is just an example to show what a membership model might look like.
> - you start with "DPDK's first $1,000,000", it is far from the $O
> that we agreed based on OVS model.
That's just standard text that I see in all the LF charters. It's even in the OVS charter (http://openvswitch.org/charter/charter.pdf) even though they have 0 budget. I assumed it's standard text for the LF. I'm sure Mike Dolan can clarify.
>
> Please, explain why you did change it?
>
> Thank you,
> Vincent
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* Re: [PATCH v3 02/12] net/virtio: setup and start cq in configure callback
From: Olivier Matz @ 2016-11-08 14:58 UTC (permalink / raw)
To: Yao, Lei A, dev@dpdk.org, yuanhan.liu@linux.intel.com
Cc: Ananyev, Konstantin, Chandran, Sugesh, Richardson, Bruce,
Tan, Jianfeng, Zhang, Helin, adrien.mazarguil@6wind.com,
stephen@networkplumber.org, dprovan@bivio.net, Wang, Xiao W,
maxime.coquelin@redhat.com
In-Reply-To: <2DBBFF226F7CF64BAFCA79B681719D9537F234A7@shsmsx102.ccr.corp.intel.com>
Hi Lei,
On 11/02/2016 02:38 AM, Yao, Lei A wrote:
> Hi, Olivier
>
> During the validation work with v16.11-rc2, I find that this patch will cause VM crash if enable virtio bonding in VM. Could you have a check at your side? The following is steps at my side. Thanks a lot
>
> 1. bind PF port to igb_uio.
> modprobe uio
> insmod ./x86_64-native-linuxapp-gcc/kmod/igb_uio.ko
> ./tools/dpdk-devbind.py --bind=igb_uio 84:00.1
>
> 2. start vhost switch.
> ./examples/vhost/build/vhost-switch -c 0x1c0000 -n 4 --socket-mem 4096,4096 - -p 0x1 --mergeable 0 --vm2vm 0 --socket-file ./vhost-net
>
> 3. bootup one vm with four virtio net device
> qemu-system-x86_64 \
> -name vm0 -enable-kvm -chardev socket,path=/tmp/vm0_qga0.sock,server,nowait,id=vm0_qga0 \
> -device virtio-serial -device virtserialport,chardev=vm0_qga0,name=org.qemu.guest_agent.0 \
> -daemonize -monitor unix:/tmp/vm0_monitor.sock,server,nowait \
> -net nic,vlan=0,macaddr=00:00:00:c7:56:64,addr=1f \
> net user,vlan=0,hostfwd=tcp:10.239.129.127:6107:22 \
> -chardev socket,id=char0,path=./vhost-net \
> -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce \
> -device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01 \
> -chardev socket,id=char1,path=./vhost-net \
> -netdev type=vhost-user,id=netdev1,chardev=char1,vhostforce \
> -device virtio-net-pci,netdev=netdev1,mac=52:54:00:00:00:02 \
> -chardev socket,id=char2,path=./vhost-net \
> -netdev type=vhost-user,id=netdev2,chardev=char2,vhostforce \
> -device virtio-net-pci,netdev=netdev2,mac=52:54:00:00:00:03 \
> -chardev socket,id=char3,path=./vhost-net \
> -netdev type=vhost-user,id=netdev3,chardev=char3,vhostforce \
> -device virtio-net-pci,netdev=netdev3,mac=52:54:00:00:00:04 \
> -cpu host -smp 8 -m 4096 \
> -object memory-backend-file,id=mem,size=4096M,mem-path=/mnt/huge,share=on \
> -numa node,memdev=mem -mem-prealloc -drive file=/home/osimg/ubuntu16.img -vnc :10
>
> 4. on vm:
> bind virtio net device to igb_uio
> modprobe uio
> insmod ./x86_64-native-linuxapp-gcc/kmod/igb_uio.ko
> tools/dpdk-devbind.py --bind=igb_uio 00:04.0 00:05.0 00:06.0 00:07.0
> 5. startup test_pmd app
> ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x1f -n 4 - -i --txqflags=0xf00 --disable-hw-vlan-filter
> 6. create one bonding device (port 4)
> create bonded device 0 0 (the first 0: mode, the second: the socket number)
> show bonding config 4
> 7. bind port 0, 1, 2 to port 4
> add bonding slave 0 4
> add bonding slave 1 4
> add bonding slave 2 4
> port start 4
> Result: just after port start 4(port 4 is bonded port), the vm shutdown immediately.
Sorry for the late answer. I reproduced the issue on rc2, and I confirm
that Yuanhan's patchset fixes it in rc3.
Regards,
Olivier
^ permalink raw reply
* Re: [PATCH v2 1/1] mempool: Add sanity check when secondary link in less mempools than primary
From: Olivier Matz @ 2016-11-08 13:59 UTC (permalink / raw)
To: jean.tourrilhes, dev, Thomas Monjalon, David Marchand,
Sergio Gonzalez Monroy
In-Reply-To: <20161028183705.GA6907@labs.hpe.com>
Hello Jean,
On 10/28/2016 08:37 PM, Jean Tourrilhes wrote:
> If the mempool ops the caller wants to use is not registered, the
> library will segfault in an obscure way when trying to use that
> mempool. It's better to catch it early and warn the user.
>
> If the primary and secondary process were build using different build
> systems, the list of constructors included by the linker in each
> binary might be different. Mempools are registered via constructors, so
> the linker magic will directly impact which tailqs are registered with
> the primary and the secondary.
> DPDK currently assumes that the secondary has a superset of the
> mempools registered at the primary, and they are in the same order
> (same index in primary and secondary). In some build scenario, the
> secondary might not initialise any mempools at all.
>
> This would also catch cases where there is a bug in the mempool
> registration, or some memory corruptions, but this has not been
> observed.
I still don't get how you can have different constructors in your
primary and secondary. As I said in my previous answer, my
understanding of how secondary process works in dpdk is that the
binaries have to be synchronized.
Your are just talking about linker magic but you don't explain how
to reproduce your issue easily. Please, can you provide a simple
example (let's say one .c and one Makefile) plus a simple screenshot
that highlights the issue?
We'll then check if this issue should be fixed in mempool or if
we should provide helpers in the build system to avoid this situation.
>
> Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com>
> ---
> lib/librte_mempool/rte_mempool.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
> index 2e28e2e..82260cc 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -1275,6 +1275,25 @@ rte_mempool_lookup(const char *name)
> return NULL;
> }
>
> + /* Sanity check : secondary may have initialised less mempools
> + * than primary due to linker and constructor magic. Or maybe
> + * there is a mempool corruption or bug. In any case, we can't
> + * go on, we will segfault in an obscure way.
> + * This does not detect the case where the constructor order
> + * is different between primary and secondary and where the
> + * index points to the wrong ops. This would require more
> + * extensive changes, and is much less likely.
> + * Jean II */
> + if(mp->ops_index >= (int32_t) rte_mempool_ops_table.num_ops) {
> + unsigned i;
> + /* Dump list of mempool ops for further investigation. */
> + for (i = 0; i < rte_mempool_ops_table.num_ops; i++) {
> + RTE_LOG(ERR, EAL, "Registered mempool[%d] is %s\n", i, rte_mempool_ops_table.ops[i].name);
> + }
> + /* Do not dump mempool list itself, it will segfault. */
> + rte_panic("Cannot find ops for mempool, ops_index %d, num_ops %d - maybe due to build process or linker configuration\n", mp->ops_index, rte_mempool_ops_table.num_ops);
> + }
> +
Also, please use checkpatch to ensure it matches the style.
See
http://dpdk.org/doc/guides/contributing/patches.html#checking-the-patches
I don't feel signing your comments is absolutely required. In addition
it does not give a lot of information about who wrote it, given the
large number of Jean II: https://fr.wikipedia.org/wiki/Jean_II
Regards,
Olivier
^ permalink raw reply
* Re: [PATCH] ethdev: fix statistics description
From: Tahhan, Maryam @ 2016-11-08 13:33 UTC (permalink / raw)
To: Dai, Wei, Thomas Monjalon, Mcnamara, John, Ananyev, Konstantin,
Wu, Jingjing, Zhang, Helin, Dai, Wei, Curran, Greg
Cc: dev@dpdk.org
In-Reply-To: <49759EB36A64CF4892C1AFEC9231E8D63A2EB13C@PGSMSX106.gar.corp.intel.com>
>
> Hi, John & Greg
>
> Would you please give any opinion for this patch ?
>
> I have looked through all PMDs and found not all statistics items can be
> supported by some NIC.
> For example, rx_nombuf, q_ipackets, q_opackets, q_ibytes and q_obytes
> are not supported by i40e.
Queue stats should be supported by i40e as we have access to struct i40e_queue_stats this is a gap. Same for e1000.
For me (from a stats perspective), we should be able to report everything that ethtool can report for the different kernel network drivers (as we have the same base driver code in DPDK). In other words, the DPDK stats API should provide the same set of stats as a standard networking interface would to an external monitoring tool in case we want to perform some sort of analytics on it afterwards.
At a very minimum the top level stats should include: ipackets, opackets, ibytes, obytes, imissed, ierrors, oerrors. The queue stats in theory could be migrated to the xstats, it would require a lot of clean up in existing drivers which is why we didn't remove them when we did the original cleanup of the struct for the xstats API.
> But when the function rte_eth_stats_get(uint8_t port_id, struct
> rte_eth_stats *stats) is called for i40e PMD, Above un-supported statistics
> item in output stats are zero, this is not real value.
Agreed - should not output 0 for these. But should ensure where stats are possible to obtain, we support them in DPDK.
> So far, there is no way to know whether an item in struct rte_eth_stats is
> supported or not only from this structure definition.
> Maybe some structure member can be added to indicate each of statistics
> item valid or not.
> But this means ABI change.
Migrating the queue/nonstandard stats to the xstats API would fix this, the only issue is with the existing drivers that are unsupported fields with 0.
>
> In following list, I list statistics support details of all PMDs.
> Hope it can be displayed in your screen.
>
Thanks for this, it's very helpful. I'm currently collating a list of the missing stats for e1000, ixgbe and i40e from DPDK. So this is very helpful.
> Thanks
> /Wei
>
> NIC ipackets opackets ibytes obytes imissed ierrors oerrors
> rx_nombuf q_ipackets q_opacktes q_ibytes q_obytes q_errors
> af_packet y y y y n n y n y y y y
> y
> bnx2x y y y y y y y y n n n n
> n
> bnxt y y y y y y y n y y y y
> y
> bonding y y y y y y y y y y y y
> y
> cxgbe y y y y y y y n y y y y
> y
> e1000(igb) y y y y y y y n n n n n
> n
> e1000(igbvf) y y y y n n n n n n n
> n n
> ena y y y y y y y y n n n n
> n
> enic y y y y y y y y n n n n
> n
> fm10k y y y y n n n n y y y y
> n
> i40e y y y y y y y n n n n n
> n
> i40evf y y y y n y y n n n n n
> n
> ixgbe y y y y y y y n y y y y
> y
> ixgbevf y y y y n n n n n n n n
> n
> mlx4 y y y y n y y y y y y y
> y
> mlx5 y y y y n y y y y y y y
> y
> mpipe y y y y n y y y y y y y
> y
> nfp y y y y y y y y y y y y
> n
> null y y n n n n y n y y n n
> y
> pcap y y y y n n y n y y y y
> y
> qede y y y y y y y y n n n n
> n
> ring y y n n n n y n y y n n
> y
> szedata2 y y y y n n y n y y y y
> y
> thunderx y y y y y y y n y y y y
> n
> vhost y y y y n n y n y y y y
> n
> virtio y y y y n y y y y y y y
> n
> vmxnet3 y y y y n y y y y y y y
> y
> xenvirt y y n n n n n n n n n n
> n
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Tuesday, October 4, 2016 5:35 PM
> > To: Dai, Wei <wei.dai@intel.com>; Mcnamara, John
> > <john.mcnamara@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] ethdev: fix statistics description
> >
> > 2016-08-26 18:08, Wei Dai:
> > > /**
> > > * A structure used to retrieve statistics for an Ethernet port.
> > > + * Not all statistics fields in struct rte_eth_stats are supported
> > > + * by any type of network interface card (NIC). If any statistics
> > > + * field is not supported, its value is 0 .
> > > */
> > > struct rte_eth_stats {
> >
> > I'm missing the point of this patch.
> > Why do you think it is a fix?
> >
> > John, any opinion?
>
^ permalink raw reply
* Re: [PATCH v4] latencystats: added new library for latency stats
From: Pattan, Reshma @ 2016-11-08 12:34 UTC (permalink / raw)
To: dev@dpdk.org
Cc: 'Olivier Matz', De Lara Guarch, Pablo, Tahhan, Maryam,
Mcnamara, John
In-Reply-To: <1478524474-7154-1-git-send-email-reshma.pattan@intel.com>
CCing maintainers of Mbuf , testpmd and dpdk-procinfo.
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Monday, November 7, 2016 1:15 PM
> To: dev@dpdk.org
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [PATCH v4] latencystats: added new library for latency stats
>
> Library is designed to calculate latency stats and report them to the
> application when queried. Library measures minimum, average, maximum
> latencies and jitter in nano seconds.
> Current implementation supports global latency stats, i.e. per application
> stats.
>
> Added new field to mbuf struct to mark the packet arrival time on Rx and
> use the timestamp to measure the latency on Tx.
>
> Modified testpmd code to initialize/uninitialize latency stats calulation.
> Modified dpdk-procinfo process to display the newly added metrics info.
>
> This pacth is dependent on http://dpdk.org/dev/patchwork/patch/16927/ .
>
> APIs:
>
> Added APIs to initialize and un initialize latency stats calculation.
> Added API to retrieve latency stats names and values.
>
> Functionality:
>
> *Library will register ethdev Rx/Tx callbacks for each active port, queue
> combinations.
> *Library will register latency stats names with new metrics library.
> http://dpdk.org/dev/patchwork/patch/16927/
> *Rx packets will be marked with time stamp on each sampling interval.
> *On Tx side, packets with time stamp will be considered for calculating the
> minimum, maximum, average latencies and jitter.
> *Average latency is calculated using exponential weighted moving average
> method.
> *Minimum and maximum latencies will be low and high latency values
> observed so far.
> *Jitter calculation is done based on inter packet delay variation.
> *Measured stats are reported to the metrics library in a separate pthread.
> *Measured stats can be retrieved via get API of the libray (or) by calling
> generic get API of the new metrics library.
>
> documents yet to be updated.
>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> ---
> MAINTAINERS | 4 +
> app/proc_info/main.c | 70 ++++
> app/test-pmd/testpmd.c | 10 +
> config/common_base | 5 +
> lib/Makefile | 1 +
> lib/librte_latencystats/Makefile | 57 ++++
> lib/librte_latencystats/rte_latencystats.c | 380
> +++++++++++++++++++++
> lib/librte_latencystats/rte_latencystats.h | 141 ++++++++
> .../rte_latencystats_version.map | 10 +
> lib/librte_mbuf/rte_mbuf.h | 3 +
> mk/rte.app.mk | 2 +
> 11 files changed, 683 insertions(+)
> create mode 100644 lib/librte_latencystats/Makefile create mode 100644
> lib/librte_latencystats/rte_latencystats.c
> create mode 100644 lib/librte_latencystats/rte_latencystats.h
> create mode 100644 lib/librte_latencystats/rte_latencystats_version.map
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba12d1b..2567448 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -702,3 +702,7 @@ F: examples/tep_termination/
> F: examples/vmdq/
> F: examples/vmdq_dcb/
> F: doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst
> +
> +Latency Stats
> +M: Reshma Pattan <reshma.pattan@intel.com>
> +F: lib/librte_latencystats/
> diff --git a/app/proc_info/main.c b/app/proc_info/main.c index
> 2c56d10..37d5ae4 100644
> --- a/app/proc_info/main.c
> +++ b/app/proc_info/main.c
> @@ -57,6 +57,7 @@
> #include <rte_atomic.h>
> #include <rte_branch_prediction.h>
> #include <rte_string_fns.h>
> +#include <rte_metrics.h>
>
> /* Maximum long option length for option parsing. */ #define
> MAX_LONG_OPT_SZ 64 @@ -68,6 +69,8 @@ static uint32_t
> enabled_port_mask; static uint32_t enable_stats; /**< Enable xstats. */
> static uint32_t enable_xstats;
> +/**< Enable metrics. */
> +static uint32_t enable_metrics;
> /**< Enable stats reset. */
> static uint32_t reset_stats;
> /**< Enable xstats reset. */
> @@ -85,6 +88,8 @@ proc_info_usage(const char *prgname)
> " --stats: to display port statistics, enabled by default\n"
> " --xstats: to display extended port statistics, disabled by "
> "default\n"
> + " --metrics: to display derived metrics of the ports, disabled
> by "
> + "default\n"
> " --stats-reset: to reset port statistics\n"
> " --xstats-reset: to reset port extended statistics\n",
> prgname);
> @@ -127,6 +132,7 @@ proc_info_parse_args(int argc, char **argv)
> {"stats", 0, NULL, 0},
> {"stats-reset", 0, NULL, 0},
> {"xstats", 0, NULL, 0},
> + {"metrics", 0, NULL, 0},
> {"xstats-reset", 0, NULL, 0},
> {NULL, 0, 0, 0}
> };
> @@ -159,6 +165,10 @@ proc_info_parse_args(int argc, char **argv)
> else if (!strncmp(long_option[option_index].name,
> "xstats",
> MAX_LONG_OPT_SZ))
> enable_xstats = 1;
> + else if (!strncmp(long_option[option_index].name,
> + "metrics",
> + MAX_LONG_OPT_SZ))
> + enable_metrics = 1;
> /* Reset stats */
> if (!strncmp(long_option[option_index].name, "stats-
> reset",
> MAX_LONG_OPT_SZ))
> @@ -301,6 +311,60 @@ nic_xstats_clear(uint8_t port_id)
> printf("\n NIC extended statistics for port %d cleared\n", port_id); }
>
> +static void
> +metrics_display(int port_id)
> +{
> + struct rte_stat_value *stats;
> + struct rte_metric_name *names;
> + int len, ret;
> + static const char *nic_stats_border = "########################";
> +
> + memset(&stats, 0, sizeof(struct rte_stat_value));
> + len = rte_metrics_get_names(NULL, 0);
> + if (len < 0) {
> + printf("Cannot get metrics count\n");
> + return;
> + }
> +
> + stats = malloc(sizeof(struct rte_stat_value) * len);
> + if (stats == NULL) {
> + printf("Cannot allocate memory for metrics\n");
> + return;
> + }
> +
> + names = malloc(sizeof(struct rte_metric_name) * len);
> + if (names == NULL) {
> + printf("Cannot allocate memory for metrcis names\n");
> + free(stats);
> + return;
> + }
> +
> + if (len != rte_metrics_get_names(names, len)) {
> + printf("Cannot get metrics names\n");
> + free(stats);
> + free(names);
> + return;
> + }
> +
> + printf("###### metrics for port %-2d #########\n", port_id);
> + printf("%s############################\n", nic_stats_border);
> + ret = rte_metrics_get_values(port_id, stats, len);
> + if (ret < 0 || ret > len) {
> + printf("Cannot get metrics values\n");
> + free(stats);
> + free(names);
> + return;
> + }
> +
> + int i;
> + for (i = 0; i < len; i++)
> + printf("%s: %"PRIu64"\n", names[i].name, stats[i].value);
> +
> + printf("%s############################\n", nic_stats_border);
> + free(stats);
> + free(names);
> +}
> +
> int
> main(int argc, char **argv)
> {
> @@ -360,8 +424,14 @@ main(int argc, char **argv)
> nic_stats_clear(i);
> else if (reset_xstats)
> nic_xstats_clear(i);
> + else if (enable_metrics)
> + metrics_display(i);
> }
> }
>
> + /* print port independent stats */
> + if (enable_metrics)
> + metrics_display(RTE_METRICS_NONPORT);
> +
> return 0;
> }
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> 6185be6..0efab4e 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -78,6 +78,10 @@
> #ifdef RTE_LIBRTE_PDUMP
> #include <rte_pdump.h>
> #endif
> +#include <rte_metrics.h>
> +#ifdef RTE_LIBRTE_LATENCY_STATS
> +#include <rte_latencystats.h>
> +#endif
>
> #include "testpmd.h"
>
> @@ -2070,6 +2074,9 @@ signal_handler(int signum)
> /* uninitialize packet capture framework */
> rte_pdump_uninit();
> #endif
> +#ifdef RTE_LIBRTE_LATENCY_STATS
> + rte_latencystats_uninit();
> +#endif
> force_quit();
> /* exit with the expected status */
> signal(signum, SIG_DFL);
> @@ -2127,6 +2134,9 @@ main(int argc, char** argv)
> /* set all ports to promiscuous mode by default */
> FOREACH_PORT(port_id, ports)
> rte_eth_promiscuous_enable(port_id);
> +#ifdef RTE_LIBRTE_LATENCY_STATS
> + rte_latencystats_init(1, NULL);
> +#endif
>
> #ifdef RTE_LIBRTE_CMDLINE
> if (interactive == 1) {
> diff --git a/config/common_base b/config/common_base index
> 21d18f8..d9002b8 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -589,3 +589,8 @@ CONFIG_RTE_APP_TEST_RESOURCE_TAR=n
> CONFIG_RTE_TEST_PMD=y
> CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n
> CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
> +
> +#
> +# Compile the latency statistics library #
> +CONFIG_RTE_LIBRTE_LATENCY_STATS=y
> diff --git a/lib/Makefile b/lib/Makefile index 990f23a..2111349 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -58,6 +58,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_TABLE) += librte_table
> DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += librte_pipeline
> DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += librte_reorder
> DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += librte_pdump
> +DIRS-$(CONFIG_RTE_LIBRTE_LATENCY_STATS) += librte_latencystats
>
> ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
> DIRS-$(CONFIG_RTE_LIBRTE_KNI) += librte_kni diff --git
> a/lib/librte_latencystats/Makefile b/lib/librte_latencystats/Makefile
> new file mode 100644
> index 0000000..f744da6
> --- /dev/null
> +++ b/lib/librte_latencystats/Makefile
> @@ -0,0 +1,57 @@
> +# BSD LICENSE
> +#
> +# Copyright(c) 2016 Intel Corporation. All rights reserved.
> +# All rights reserved.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions
> +# are met:
> +#
> +# * Redistributions of source code must retain the above copyright
> +# notice, this list of conditions and the following disclaimer.
> +# * Redistributions in binary form must reproduce the above copyright
> +# notice, this list of conditions and the following disclaimer in
> +# the documentation and/or other materials provided with the
> +# distribution.
> +# * Neither the name of Intel Corporation nor the names of its
> +# contributors may be used to endorse or promote products derived
> +# from this software without specific prior written permission.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> OF USE,
> +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> ON ANY
> +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> +
> +include $(RTE_SDK)/mk/rte.vars.mk
> +
> +# library name
> +LIB = librte_latencystats.a
> +
> +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 LDLIBS += -lm LDLIBS +=
> +-lpthread
> +
> +EXPORT_MAP := rte_latencystats_version.map
> +
> +LIBABIVER := 1
> +
> +# all source are stored in SRCS-y
> +SRCS-$(CONFIG_RTE_LIBRTE_LATENCY_STATS) := rte_latencystats.c
> +
> +# install this header file
> +SYMLINK-$(CONFIG_RTE_LIBRTE_LATENCY_STATS)-include :=
> +rte_latencystats.h
> +
> +# this lib depends upon:
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_LATENCY_STATS) += lib/librte_mbuf
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_LATENCY_STATS) += lib/librte_eal
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_LATENCY_STATS) += lib/librte_ether
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_LATENCY_STATS) += lib/librte_metrics
> +
> +include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/lib/librte_latencystats/rte_latencystats.c
> b/lib/librte_latencystats/rte_latencystats.c
> new file mode 100644
> index 0000000..0bcb09f
> --- /dev/null
> +++ b/lib/librte_latencystats/rte_latencystats.c
> @@ -0,0 +1,380 @@
> +/*-
> + * BSD LICENSE
> + *
> + * Copyright(c) 2016 Intel Corporation. All rights reserved.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + * * Neither the name of Intel Corporation nor the names of its
> + * contributors may be used to endorse or promote products derived
> + * from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> + */
> +
> +#include <unistd.h>
> +#include <sys/types.h>
> +#include <stdbool.h>
> +#include <math.h>
> +#include <pthread.h>
> +
> +#include <rte_mbuf.h>
> +#include <rte_log.h>
> +#include <rte_cycles.h>
> +#include <rte_ethdev.h>
> +#include <rte_metrics.h>
> +#include <rte_memzone.h>
> +#include <rte_lcore.h>
> +#include <rte_timer.h>
> +
> +#include "rte_latencystats.h"
> +
> +/** Nano seconds per second */
> +#define NS_PER_SEC 1E9
> +
> +/** Clock cycles per nano second */
> +#define CYCLES_PER_NS (rte_get_timer_hz() / NS_PER_SEC)
> +
> +/* Macros for printing using RTE_LOG */ #define
> +RTE_LOGTYPE_LATENCY_STATS RTE_LOGTYPE_USER1
> +
> +static pthread_t latency_stats_thread;
> +static const char *MZ_RTE_LATENCY_STATS = "rte_latencystats"; static
> +int latency_stats_index; static uint64_t sampIntvl; static uint64_t
> +timer_tsc; static uint64_t prev_tsc;
> +
> +struct rte_latency_stats {
> + float min_latency; /**< Minimum latency in nano seconds */
> + float avg_latency; /**< Average latency in nano seconds */
> + float max_latency; /**< Maximum latency in nano seconds */
> + float jitter; /** Latency variation between to packets */
> + uint64_t total_sampl_pkts;
> +} *glob_stats;
> +
> +static struct rxtx_cbs {
> + struct rte_eth_rxtx_callback *cb;
> +} rx_cbs[RTE_MAX_ETHPORTS][RTE_MAX_QUEUES_PER_PORT],
> + tx_cbs[RTE_MAX_ETHPORTS][RTE_MAX_QUEUES_PER_PORT];
> +
> +struct latency_stats_nameoff {
> + char name[RTE_ETH_XSTATS_NAME_SIZE];
> + unsigned int offset;
> +};
> +
> +static const struct latency_stats_nameoff lat_stats_strings[] = {
> + {"min_latency_ns", offsetof(struct rte_latency_stats, min_latency)},
> + {"avg_latency_ns", offsetof(struct rte_latency_stats, avg_latency)},
> + {"max_latency_ns", offsetof(struct rte_latency_stats, max_latency)},
> + {"jitter_ns", offsetof(struct rte_latency_stats, jitter)}, };
> +
> +#define NUM_LATENCY_STATS (sizeof(lat_stats_strings) / \
> + sizeof(lat_stats_strings[0]))
> +
> +static __attribute__((noreturn)) void *
> +report_latency_stats(__rte_unused void *arg) {
> + for (;;) {
> + unsigned int i;
> + float *stats_ptr = NULL;
> + uint64_t values[NUM_LATENCY_STATS] = {0};
> + int ret;
> +
> + for (i = 0; i < NUM_LATENCY_STATS; i++) {
> + stats_ptr = RTE_PTR_ADD(glob_stats,
> + lat_stats_strings[i].offset);
> + values[i] = (uint64_t)floor((*stats_ptr)/
> + CYCLES_PER_NS);
> + }
> +
> + ret = rte_metrics_update_metrics(RTE_METRICS_NONPORT,
> + latency_stats_index,
> + values,
> NUM_LATENCY_STATS);
> + if (ret < 0)
> + RTE_LOG(INFO, LATENCY_STATS,
> + "Failed to push the stats\n");
> + }
> +}
> +
> +static void
> +rte_latencystats_fill_values(struct rte_stat_value *values) {
> + unsigned int i;
> + float *stats_ptr = NULL;
> +
> + for (i = 0; i < NUM_LATENCY_STATS; i++) {
> + stats_ptr = RTE_PTR_ADD(glob_stats,
> + lat_stats_strings[i].offset);
> + values[i].key = i;
> + values[i].value = (uint64_t)floor((*stats_ptr)/
> + CYCLES_PER_NS);
> + }
> +}
> +
> +static uint16_t
> +add_time_stamps(uint8_t pid __rte_unused,
> + uint16_t qid __rte_unused,
> + struct rte_mbuf **pkts,
> + uint16_t nb_pkts,
> + uint16_t max_pkts __rte_unused,
> + void *user_cb __rte_unused)
> +{
> + unsigned int i;
> + uint64_t diff_tsc, now;
> +
> + /* for every sample interval,
> + * time stamp is marked on one received packet
> + */
> + now = rte_rdtsc();
> + for (i = 0; i < nb_pkts; i++) {
> + diff_tsc = now - prev_tsc;
> + timer_tsc += diff_tsc;
> + if (timer_tsc >= sampIntvl) {
> + pkts[i]->timestamp = now;
> + timer_tsc = 0;
> + }
> + prev_tsc = now;
> + now = rte_rdtsc();
> + }
> +
> + return nb_pkts;
> +}
> +
> +static uint16_t
> +calc_latency(uint8_t pid __rte_unused,
> + uint16_t qid __rte_unused,
> + struct rte_mbuf **pkts,
> + uint16_t nb_pkts,
> + void *_ __rte_unused)
> +{
> + unsigned int i, cnt = 0;
> + uint64_t now;
> + float latency[nb_pkts];
> + static float prev_latency;
> + const float alpha = 0.2;
> +
> + now = rte_rdtsc();
> + for (i = 0; i < nb_pkts; i++) {
> + if (pkts[i]->timestamp)
> + latency[cnt++] = now - pkts[i]->timestamp;
> + }
> +
> + for (i = 0; i < cnt; i++) {
> + /**
> + *The jitter is calculated as statistical mean of interpacket
> + *delay variation. The "jitter estimate" is computed by taking
> + *the absolute values of the ipdv sequence and applying an
> + *exponential filter with parameter 1/16 to generate the
> + *estimate. i.e J=J+(|D(i-1,i)|-J)/16. Where J is jitter,
> + *D(i-1,i) is difference in latency of two consecutive packets
> + *i-1 and i.
> + *Reference: Calculated as per RFC 5481, sec 4.1,
> + *RFC 3393 sec 4.5, RFC 1889 sec.
> + */
> + glob_stats->jitter += (abs(prev_latency - latency[i])
> + - glob_stats->jitter)/16;
> + if (glob_stats->min_latency == 0)
> + glob_stats->min_latency = latency[i];
> + else if (latency[i] < glob_stats->min_latency)
> + glob_stats->min_latency = latency[i];
> + else if (latency[i] > glob_stats->max_latency)
> + glob_stats->max_latency = latency[i];
> + /**
> + *The average latency is measured using exponential moving
> + *average, i.e. using EWMA
> + *https://en.wikipedia.org/wiki/Moving_average
> + */
> + glob_stats->avg_latency +=
> + alpha * (latency[i] - glob_stats->avg_latency);
> + glob_stats->total_sampl_pkts++;
> + prev_latency = latency[i];
> + }
> +
> + return nb_pkts;
> +}
> +
> +int
> +rte_latencystats_init(uint64_t samp_intvl,
> + rte_latency_stats_flow_type_fn user_cb) {
> + unsigned int i;
> + uint8_t pid;
> + uint16_t qid;
> + struct rxtx_cbs *cbs = NULL;
> + const uint8_t nb_ports = rte_eth_dev_count();
> + const char *ptr_strings[NUM_LATENCY_STATS] = {0};
> + const struct rte_memzone *mz = NULL;
> + const unsigned int flags = 0;
> +
> + /** Allocate stats in shared memory fo muliti process support */
> + mz = rte_memzone_reserve(MZ_RTE_LATENCY_STATS,
> sizeof(*glob_stats),
> + rte_socket_id(), flags);
> + if (mz == NULL) {
> + RTE_LOG(ERR, LATENCY_STATS, "Cannot reserve memory:
> %s:%d\n",
> + __func__, __LINE__);
> + return -ENOMEM;
> + }
> +
> + glob_stats = mz->addr;
> + samp_intvl *= CYCLES_PER_NS;
> +
> + /** Register latency stats with stats library */
> + for (i = 0; i < NUM_LATENCY_STATS; i++)
> + ptr_strings[i] = lat_stats_strings[i].name;
> +
> + latency_stats_index = rte_metrics_reg_metrics(ptr_strings,
> +
> NUM_LATENCY_STATS);
> + if (latency_stats_index < 0) {
> + RTE_LOG(DEBUG, LATENCY_STATS,
> + "Failed to register latency stats names\n");
> + return -1;
> + }
> +
> + /** Register Rx/Tx callbacks */
> + for (pid = 0; pid < nb_ports; pid++) {
> + struct rte_eth_dev_info dev_info;
> + rte_eth_dev_info_get(pid, &dev_info);
> + for (qid = 0; qid < dev_info.nb_rx_queues; qid++) {
> + cbs = &rx_cbs[pid][qid];
> + cbs->cb = rte_eth_add_first_rx_callback(pid, qid,
> + add_time_stamps, user_cb);
> + if (!cbs->cb)
> + RTE_LOG(INFO, LATENCY_STATS, "Failed to "
> + "register Rx callback for pid=%d, "
> + "qid=%d\n", pid, qid);
> + }
> + for (qid = 0; qid < dev_info.nb_tx_queues; qid++) {
> + cbs = &tx_cbs[pid][qid];
> + cbs->cb = rte_eth_add_tx_callback(pid, qid,
> + calc_latency, user_cb);
> + if (!cbs->cb)
> + RTE_LOG(INFO, LATENCY_STATS, "Failed to "
> + "register Tx callback for pid=%d, "
> + "qid=%d\n", pid, qid);
> + }
> + }
> +
> + int ret = 0;
> + char thread_name[RTE_MAX_THREAD_NAME_LEN];
> +
> + /** Create the host thread to update latency stats to stats library */
> + ret = pthread_create(&latency_stats_thread, NULL,
> report_latency_stats,
> + NULL);
> + if (ret != 0) {
> + RTE_LOG(ERR, LATENCY_STATS,
> + "Failed to create the latency stats thread:%s,
> %s:%d\n",
> + strerror(errno), __func__, __LINE__);
> + return -1;
> + }
> + /** Set thread_name for aid in debugging */
> + snprintf(thread_name, RTE_MAX_THREAD_NAME_LEN, "latency-
> stats-thread");
> + ret = rte_thread_setname(latency_stats_thread, thread_name);
> + if (ret != 0)
> + RTE_LOG(DEBUG, LATENCY_STATS,
> + "Failed to set thread name for latency stats
> handling\n");
> +
> + return 0;
> +}
> +
> +int
> +rte_latencystats_uninit(void)
> +{
> + uint8_t pid;
> + uint16_t qid;
> + int ret = 0;
> + struct rxtx_cbs *cbs = NULL;
> + const uint8_t nb_ports = rte_eth_dev_count();
> +
> + /** De register Rx/Tx callbacks */
> + for (pid = 0; pid < nb_ports; pid++) {
> + struct rte_eth_dev_info dev_info;
> + rte_eth_dev_info_get(pid, &dev_info);
> + for (qid = 0; qid < dev_info.nb_rx_queues; qid++) {
> + cbs = &rx_cbs[pid][qid];
> + ret = rte_eth_remove_rx_callback(pid, qid, cbs->cb);
> + if (ret)
> + RTE_LOG(INFO, LATENCY_STATS, "failed to "
> + "remove Rx callback for pid=%d, "
> + "qid=%d\n", pid, qid);
> + }
> + for (qid = 0; qid < dev_info.nb_tx_queues; qid++) {
> + cbs = &tx_cbs[pid][qid];
> + ret = rte_eth_remove_tx_callback(pid, qid, cbs->cb);
> + if (ret)
> + RTE_LOG(INFO, LATENCY_STATS, "failed to "
> + "remove Tx callback for pid=%d, "
> + "qid=%d\n", pid, qid);
> + }
> + }
> +
> + /** Cancel the thread */
> + ret = pthread_cancel(latency_stats_thread);
> + if (ret != 0) {
> + RTE_LOG(ERR, LATENCY_STATS,
> + "Failed to cancel latency stats update thread:"
> + "%s,%s:%d\n",
> + strerror(errno), __func__, __LINE__);
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +int
> +rte_latencystats_get_names(struct rte_metric_name *names, uint16_t
> +size) {
> + unsigned int i;
> +
> + if (names == NULL || size < NUM_LATENCY_STATS)
> + return NUM_LATENCY_STATS;
> +
> + for (i = 0; i < NUM_LATENCY_STATS; i++)
> + snprintf(names[i].name, sizeof(names[i].name),
> + "%s", lat_stats_strings[i].name);
> +
> + return NUM_LATENCY_STATS;
> +}
> +
> +int
> +rte_latencystats_get(struct rte_stat_value *values, uint16_t size) {
> + if (size < NUM_LATENCY_STATS || values == NULL)
> + return NUM_LATENCY_STATS;
> +
> + if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
> + const struct rte_memzone *mz;
> + mz = rte_memzone_lookup(MZ_RTE_LATENCY_STATS);
> + if (mz == NULL) {
> + RTE_LOG(ERR, LATENCY_STATS,
> + "Latency stats memzone not found\n");
> + return -ENOMEM;
> + }
> + glob_stats = mz->addr;
> + }
> +
> + /* Retrieve latency stats */
> + rte_latencystats_fill_values(values);
> +
> + return NUM_LATENCY_STATS;
> +}
> diff --git a/lib/librte_latencystats/rte_latencystats.h
> b/lib/librte_latencystats/rte_latencystats.h
> new file mode 100644
> index 0000000..7b1e72a
> --- /dev/null
> +++ b/lib/librte_latencystats/rte_latencystats.h
> @@ -0,0 +1,141 @@
> +/*-
> + * BSD LICENSE
> + *
> + * Copyright(c) 2016 Intel Corporation. All rights reserved.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + * * Neither the name of Intel Corporation nor the names of its
> + * contributors may be used to endorse or promote products derived
> + * from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
> FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
> NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
> THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> + */
> +
> +#ifndef _RTE_LATENCYSTATS_H_
> +#define _RTE_LATENCYSTATS_H_
> +
> +/**
> + * @file
> + * RTE latency stats
> + *
> + * library to provide application and flow based latency stats.
> + */
> +
> +#include <rte_metrics.h>
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> + * Function type used for identifting flow types of a Rx packet.
> + *
> + * The callback function is called on Rx for each packet.
> + * This function is used for flow based latency calculations.
> + *
> + * @param pkt
> + * Packet that has to be identified with its flow types.
> + * @param user_param
> + * The arbitrary user parameter passed in by the application when
> + * the callback was originally configured.
> + * @return
> + * The flow_mask, representing the multiple flow types of a packet.
> + */
> +typedef uint16_t (*rte_latency_stats_flow_type_fn)(struct rte_mbuf *pkt,
> + void *user_param);
> +
> +/**
> + * @internal
> + * Registers Rx/Tx callbacks for each active port, queue.
> + *
> + * @param sampIntvl
> + * Sampling time period in nano seconds, at which packet
> + * should be marked with time stamp.
> + * @param user_cb
> + * User callback to be called to get flow types of a packet.
> + * Used for flow based latency calculation.
> + * If the value is NULL, global stats will be calculated,
> + * else flow based stats will be calculated.
> + * @return
> + * -1 : On error
> + * -ENOMEM: On error
> + * 0 : On success
> + */
> +int rte_latencystats_init(uint64_t samp_intvl,
> + rte_latency_stats_flow_type_fn user_cb);
> +
> +/**
> + * @internal
> + * Removes registered Rx/Tx callbacks for each active port, queue.
> + * @return
> + * -1: On error
> + * 0: On suces
> + */
> +int rte_latencystats_uninit(void);
> +
> +/**
> + * Retrieve names of latency statistics
> + *
> + * @param names
> + * Block of memory to insert names into. Must be at least size in capacity.
> + * If set to NULL, function returns required capacity.
> + * @param size
> + * Capacity of latency stats names (number of names).
> + * @return
> + * - positive value lower or equal to size: success. The return value
> + * is the number of entries filled in the stats table.
> + * - positive value higher than size: error, the given statistics table
> + * is too small. The return value corresponds to the size that should
> + * be given to succeed. The entries in the table are not valid and
> + * shall not be used by the caller.
> + */
> +int rte_latencystats_get_names(struct rte_metric_name *names,
> + uint16_t size);
> +
> +/**
> + * Retrieve latency statistics.
> + *
> + * @param values
> + * A pointer to a table of structure of type *rte_stat_value*
> + * to be filled with latency statistics ids and values.
> + * This parameter can be set to NULL if size is 0.
> + * @param size
> + * The size of the stats table, which should be large enough to store
> + * all the latency stats.
> + * @return
> + * - positive value lower or equal to size: success. The return value
> + * is the number of entries filled in the stats table.
> + * - positive value higher than size: error, the given statistics table
> + * is too small. The return value corresponds to the size that should
> + * be given to succeed. The entries in the table are not valid and
> + * shall not be used by the caller.
> + * -ENOMEM: On failure.
> + */
> +int rte_latencystats_get(struct rte_stat_value *values,
> + uint16_t size);
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* _RTE_LATENCYSTATS_H_ */
> diff --git a/lib/librte_latencystats/rte_latencystats_version.map
> b/lib/librte_latencystats/rte_latencystats_version.map
> new file mode 100644
> index 0000000..82dc5a7
> --- /dev/null
> +++ b/lib/librte_latencystats/rte_latencystats_version.map
> @@ -0,0 +1,10 @@
> +DPDK_16.11 {
> + global:
> +
> + rte_latencystats_get;
> + rte_latencystats_get_names;
> + rte_latencystats_init;
> + rte_latencystats_uninit;
> +
> + local: *;
> +};
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h index
> 109e666..cc3bf65 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -493,6 +493,9 @@ struct rte_mbuf {
>
> /** Timesync flags for use with IEEE1588. */
> uint16_t timesync;
> +
> + /** Timestamp for measuring latency. */
> + uint64_t timestamp;
> } __rte_cache_aligned;
>
> /**
> diff --git a/mk/rte.app.mk b/mk/rte.app.mk index f75f0e2..4e5289a 100644
> --- a/mk/rte.app.mk
> +++ b/mk/rte.app.mk
> @@ -98,6 +98,8 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_RING) += -
> lrte_ring
> _LDLIBS-$(CONFIG_RTE_LIBRTE_EAL) += -lrte_eal
> _LDLIBS-$(CONFIG_RTE_LIBRTE_CMDLINE) += -lrte_cmdline
> _LDLIBS-$(CONFIG_RTE_LIBRTE_CFGFILE) += -lrte_cfgfile
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_LATENCY_STATS) += -lrte_latencystats
> +
>
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += -lrte_pmd_bond
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += -lrte_pmd_xenvirt -
> lxenstore
> --
> 2.7.4
^ permalink raw reply
* Re: Running 2 process on the same machine
From: Keren Hochman @ 2016-11-08 12:02 UTC (permalink / raw)
To: Wiles, Keith; +Cc: dev@dpdk.org
In-Reply-To: <CAJq3SQ6kVOfTn2noOa-wVp8E1hMA9WvhY+rA8Aoi00M_qEo+pA@mail.gmail.com>
Also, I can't understand how to define socket-mem. I did not see anything
related to hugepages in /etc/sysctl.conf. Can i mount hugepages to 2
different dirs instead and use --huge-dir ?
Thank you.
On Tue, Nov 8, 2016 at 11:44 AM, Keren Hochman <keren.hochman@lightcyber.com
> wrote:
> Thank you for your response, I still can not run the 2 process together.
> if I add --no-pci to one process it can replace white and black lists
> right?
>
> Thanks, keren
>
> On Tue, Nov 8, 2016 at 12:36 AM, Wiles, Keith <keith.wiles@intel.com>
> wrote:
>
>>
>> > On Nov 7, 2016, at 7:28 AM, Keren Hochman <keren.hochman@lightcyber.com>
>> wrote:
>> >
>> > Hi,
>> > I need to run 2 process that uses dpdk on the same machine. One uses
>> dpdk
>> > drivers, and the other just read from a pcap file. If I disable
>> hugepages
>> > in the second process rte_mempool_create fails. What is the correct way
>> to
>> > handle this?
>>
>> If you look at the two scripts in Pktgen pktgen-master.sh and
>> pktgen-slave.sh these two scripts setup two instances of pktgen on the same
>> machine. Plus you can read the README.md file.
>>
>> http://dpdk.org/browse/apps/pktgen-dpdk/refs/
>>
>> You have to make sure you have enough memory (huge pages) allocated for
>> both instances to run.
>>
>> Then use —file-prefix XX to give each instance a different prefix for the
>> huge page files in /dev/hugepages if that is the location of the files on
>> your system. I would remove any files in that directory to free up the
>> memory.
>>
>> Use the —socket-mem to allocate the correct amount of memory for each
>> instances this way DPDK does not consume all the pages for a given instance.
>>
>> Make sure you blacklist the ports you do not want on the first instance
>> using -b option and then blacklist the ports from the first instance while
>> allowing the other ports to be used on the second one.
>>
>> That should do it for most cases.
>>
>> >
>> > Thanks, Keren
>>
>> Regards,
>> Keith
>>
>>
>
^ permalink raw reply
* Re: [dpdk-moving] Draft Project Charter
From: O'Driscoll, Tim @ 2016-11-08 11:57 UTC (permalink / raw)
To: Vincent JARDIN, moving@dpdk.org; +Cc: dev@dpdk.org
In-Reply-To: <213281a6-6b14-f067-dca0-4b442557b05e@6wind.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Vincent JARDIN
> Sent: Tuesday, November 8, 2016 11:41 AM
> To: moving@dpdk.org
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-moving] Draft Project Charter
>
> Tim,
>
> Thanks for your draft, but it is not a good proposal. It is not written
> in the spirit that we have discussed in Dublin:
> - you create the status of "Gold" members that we do not want from
> Linux Foundation,
As I said in the email, I put in two levels of membership as a placeholder. The first thing we need to decide is if we want to have a budget and membership, or if we want the OVS model with 0 budget and no membership. We can discuss that at today's meeting.
If we do want a membership model then we'll need to decide if everybody contributes at the same rate or if we support multiple levels. So, for now, the text on having two levels is just an example to show what a membership model might look like.
> - you start with "DPDK's first $1,000,000", it is far from the $O
> that we agreed based on OVS model.
That's just standard text that I see in all the LF charters. It's even in the OVS charter (http://openvswitch.org/charter/charter.pdf) even though they have 0 budget. I assumed it's standard text for the LF. I'm sure Mike Dolan can clarify.
>
> Please, explain why you did change it?
>
> Thank you,
> Vincent
^ permalink raw reply
* Re: [dpdk-moving] Draft Project Charter
From: Vincent JARDIN @ 2016-11-08 11:40 UTC (permalink / raw)
To: moving; +Cc: dev@dpdk.org
In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA6760E51D@IRSMSX108.ger.corp.intel.com>
Tim,
Thanks for your draft, but it is not a good proposal. It is not written
in the spirit that we have discussed in Dublin:
- you create the status of "Gold" members that we do not want from
Linux Foundation,
- you start with "DPDK’s first $1,000,000", it is far from the $O
that we agreed based on OVS model.
Please, explain why you did change it?
Thank you,
Vincent
^ permalink raw reply
* Re: [PATCH v1] maintainers: update documentation maintainers
From: Butler, Siobhan A @ 2016-11-08 10:54 UTC (permalink / raw)
To: Mcnamara, John, dev@dpdk.org
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264B887@IRSMSX103.ger.corp.intel.com>
> -----Original Message-----
> From: Mcnamara, John
> Sent: Tuesday, November 8, 2016 9:32 AM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>
> Subject: [PATCH v1] maintainers: update documentation maintainers
>
> Signed-off-by: John McNamara <john.mcnamara@intel.com>
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS index ba12d1b..11de99c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -43,7 +43,6 @@ M: maintainers@dpdk.org
>
> Documentation (with overlaps)
> -------------
> -M: Siobhan Butler <siobhan.a.butler@intel.com>
> M: John McNamara <john.mcnamara@intel.com>
> F: README
> F: doc/
> --
> 2.7.4
Aked-by: Siobhan Butler <siobhan.a.butler@intel.com>
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Wang, Zhihong @ 2016-11-08 10:51 UTC (permalink / raw)
To: Wang, Zhihong, Maxime Coquelin, Yuanhan Liu
Cc: stephen@networkplumber.org, Pierre Pfister (ppfister),
Xie, Huawei, dev@dpdk.org, vkaplans@redhat.com, mst@redhat.com
In-Reply-To: <8F6C2BD409508844A0EFC19955BE09414E7DC793@SHSMSX103.ccr.corp.intel.com>
> > > The setup where it goes wrong:
> > > 1. Xeon E5-2699, HT on, turbo off, 1GB hugepage for both host and guest
> > On the Haswell machine (on which I don't have BIOS access), HT is on,
> > but I unplug siblings at runtime.
> > I also have 1G pages on both sides, and I isolate the cores used by both
> > testpmd and vCPUS.
> >
> > > 2. Fortville 40G
> > > 3. Fedora 4.7.5-200.fc24.x86_64
> > > 4. gcc version 6.2.1
> > > 5. 16.11 RC2 for both host and guest
> > > 6. PVP, testpmd macswap for both host and guest
> > >
> > > BTW, I do see indirect_desc gives slightly better performance for
> loopback
> > > in tests on other platforms, but don't know how PVP performs yet.
> > Interesting, other platforms are also Haswell/Broadwell?
>
> Yes, but with different OS.
>
> If you don't have the setup I can do more detailed profiling for the
> root cause next week, since my platform is the only one right now that
> reporting the drop.
>
>
Hi Maxime,
I just did some profiling and see much higher L2 miss in vhost
dequeue with indirect_desc in my platform, indicates increase
of memory access contention.
I can keep digging further but might not be able to fix it in time
due to limited bandwidth.
Hope this helps.
Thanks
Zhihong
^ permalink raw reply
* [PATCH] doc: move testpmd guide with other tools
From: Thomas Monjalon @ 2016-11-08 10:02 UTC (permalink / raw)
To: John McNamara; +Cc: dev, Christian Ehrhardt
The guide testpmd_app_ug/ is moved inside the new tools/ guide
as a section.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
MAINTAINERS | 2 +-
doc/guides/conf.py | 2 +-
doc/guides/contributing/documentation.rst | 1 -
doc/guides/index.rst | 1 -
doc/guides/tools/index.rst | 2 +-
doc/guides/{testpmd_app_ug => tools/testpmd}/build_app.rst | 0
doc/guides/{testpmd_app_ug => tools/testpmd}/index.rst | 4 ++--
doc/guides/{testpmd_app_ug => tools/testpmd}/intro.rst | 0
doc/guides/{testpmd_app_ug => tools/testpmd}/run_app.rst | 0
doc/guides/{testpmd_app_ug => tools/testpmd}/testpmd_funcs.rst | 0
10 files changed, 5 insertions(+), 7 deletions(-)
rename doc/guides/{testpmd_app_ug => tools/testpmd}/build_app.rst (100%)
rename doc/guides/{testpmd_app_ug => tools/testpmd}/index.rst (96%)
rename doc/guides/{testpmd_app_ug => tools/testpmd}/intro.rst (100%)
rename doc/guides/{testpmd_app_ug => tools/testpmd}/run_app.rst (100%)
rename doc/guides/{testpmd_app_ug => tools/testpmd}/testpmd_funcs.rst (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index ba12d1b..19cd05b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -614,7 +614,7 @@ F: app/test/virtual_pmd.h
Driver testing tool
M: Pablo de Lara <pablo.de.lara.guarch@intel.com>
F: app/test-pmd/
-F: doc/guides/testpmd_app_ug/
+F: doc/guides/tools/testpmd/
Dump tool
M: Maryam Tahhan <maryam.tahhan@intel.com>
diff --git a/doc/guides/conf.py b/doc/guides/conf.py
index 149bcdb..8619d04 100644
--- a/doc/guides/conf.py
+++ b/doc/guides/conf.py
@@ -106,7 +106,7 @@ class CustomLatexFormatter(LatexFormatter):
PygmentsBridge.latex_formatter = CustomLatexFormatter
# Configuration for man pages
-man_pages = [("testpmd_app_ug/run_app", "testpmd",
+man_pages = [("tools/testpmd/run_app", "testpmd",
"tests for dpdk pmds", "", 1),
("tools/pdump", "dpdk-pdump",
"enable packet capture on dpdk ports", "", 1),
diff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst
index 2cfb1a2..03dc59f 100644
--- a/doc/guides/contributing/documentation.rst
+++ b/doc/guides/contributing/documentation.rst
@@ -31,7 +31,6 @@ The main directories that contain files related to documentation are shown below
|-- prog_guide
|-- sample_app_ug
|-- guidelines
- |-- testpmd_app_ug
|-- rel_notes
|-- nics
|-- xen
diff --git a/doc/guides/index.rst b/doc/guides/index.rst
index 57570f6..25f576a 100644
--- a/doc/guides/index.rst
+++ b/doc/guides/index.rst
@@ -42,7 +42,6 @@ DPDK documentation
cryptodevs/index
sample_app_ug/index
tools/index
- testpmd_app_ug/index
faq/index
howto/index
rel_notes/index
diff --git a/doc/guides/tools/index.rst b/doc/guides/tools/index.rst
index cbe98b2..f9aa37d 100644
--- a/doc/guides/tools/index.rst
+++ b/doc/guides/tools/index.rst
@@ -39,4 +39,4 @@ Tool User Guides
pdump
pmdinfo
devbind
-
+ testpmd/index
diff --git a/doc/guides/testpmd_app_ug/build_app.rst b/doc/guides/tools/testpmd/build_app.rst
similarity index 100%
rename from doc/guides/testpmd_app_ug/build_app.rst
rename to doc/guides/tools/testpmd/build_app.rst
diff --git a/doc/guides/testpmd_app_ug/index.rst b/doc/guides/tools/testpmd/index.rst
similarity index 96%
rename from doc/guides/testpmd_app_ug/index.rst
rename to doc/guides/tools/testpmd/index.rst
index 1c39a17..10d2ec0 100644
--- a/doc/guides/testpmd_app_ug/index.rst
+++ b/doc/guides/tools/testpmd/index.rst
@@ -28,8 +28,8 @@
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-Testpmd Application User Guide
-==============================
+testpmd Application
+===================
.. toctree::
:maxdepth: 3
diff --git a/doc/guides/testpmd_app_ug/intro.rst b/doc/guides/tools/testpmd/intro.rst
similarity index 100%
rename from doc/guides/testpmd_app_ug/intro.rst
rename to doc/guides/tools/testpmd/intro.rst
diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/tools/testpmd/run_app.rst
similarity index 100%
rename from doc/guides/testpmd_app_ug/run_app.rst
rename to doc/guides/tools/testpmd/run_app.rst
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/tools/testpmd/testpmd_funcs.rst
similarity index 100%
rename from doc/guides/testpmd_app_ug/testpmd_funcs.rst
rename to doc/guides/tools/testpmd/testpmd_funcs.rst
--
2.7.0
^ permalink raw reply related
* Re: [PATCH] virtio: tx with can_push when VERSION_1 is set
From: Maxime Coquelin @ 2016-11-08 9:44 UTC (permalink / raw)
To: Pierre Pfister (ppfister), dev@dpdk.org
In-Reply-To: <82834CFE-767C-41B0-9327-E64B8210E076@cisco.com>
Hi Pierre,
On 11/08/2016 10:31 AM, Pierre Pfister (ppfister) wrote:
> Current virtio driver advertises VERSION_1 support,
> but does not handle device's VERSION_1 support when
> sending packets (it looks for ANY_LAYOUT feature,
> which is absent).
>
> This patch enables 'can_push' in tx path when VERSION_1
> is advertised by the device.
>
> This significantly improves small packets forwarding rate
> towards devices advertising VERSION_1 feature.
I think it depends whether offloading is enabled or not.
If no offloading enabled, I measured significant drop.
Indeed, when no offloading is enabled, the Tx path in Virtio
does not access the virtio header before your patch, as the header is
memset to zero at device init time.
With your patch, it gets memset to zero at every transmit in the hot
path.
With offloading enabled, it does makes sense though, as the header will
be accessed.
This patch is for v17.02 anyway, and we may provide a way to enable and
disable features at Virtio PMD init time by this release.
Thanks,
Maxime
>
> Signed-off-by: Pierre Pfister <ppfister@cisco.com>
> ---
> drivers/net/virtio/virtio_rxtx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
> index 724517e..2fe0338 100644
> --- a/drivers/net/virtio/virtio_rxtx.c
> +++ b/drivers/net/virtio/virtio_rxtx.c
> @@ -925,7 +925,8 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
> }
>
> /* optimize ring usage */
> - if (vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) &&
> + if ((vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) ||
> + vtpci_with_feature(hw, VIRTIO_F_VERSION_1)) &&
> rte_mbuf_refcnt_read(txm) == 1 &&
> RTE_MBUF_DIRECT(txm) &&
> txm->nb_segs == 1 &&
> --
> 2.7.4 (Apple Git-66)
>
^ permalink raw reply
* Re: Running 2 process on the same machine
From: Keren Hochman @ 2016-11-08 9:44 UTC (permalink / raw)
To: Wiles, Keith; +Cc: dev@dpdk.org
In-Reply-To: <60A9A962-53C9-4050-8D84-74AD13CCE09B@intel.com>
Thank you for your response, I still can not run the 2 process together.
if I add --no-pci to one process it can replace white and black lists
right?
Thanks, keren
On Tue, Nov 8, 2016 at 12:36 AM, Wiles, Keith <keith.wiles@intel.com> wrote:
>
> > On Nov 7, 2016, at 7:28 AM, Keren Hochman <keren.hochman@lightcyber.com>
> wrote:
> >
> > Hi,
> > I need to run 2 process that uses dpdk on the same machine. One uses dpdk
> > drivers, and the other just read from a pcap file. If I disable
> hugepages
> > in the second process rte_mempool_create fails. What is the correct way
> to
> > handle this?
>
> If you look at the two scripts in Pktgen pktgen-master.sh and
> pktgen-slave.sh these two scripts setup two instances of pktgen on the same
> machine. Plus you can read the README.md file.
>
> http://dpdk.org/browse/apps/pktgen-dpdk/refs/
>
> You have to make sure you have enough memory (huge pages) allocated for
> both instances to run.
>
> Then use —file-prefix XX to give each instance a different prefix for the
> huge page files in /dev/hugepages if that is the location of the files on
> your system. I would remove any files in that directory to free up the
> memory.
>
> Use the —socket-mem to allocate the correct amount of memory for each
> instances this way DPDK does not consume all the pages for a given instance.
>
> Make sure you blacklist the ports you do not want on the first instance
> using -b option and then blacklist the ports from the first instance while
> allowing the other ports to be used on the second one.
>
> That should do it for most cases.
>
> >
> > Thanks, Keren
>
> Regards,
> Keith
>
>
^ permalink raw reply
* [PATCH v1] maintainers: update documentation maintainers
From: John McNamara @ 2016-11-08 9:31 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index ba12d1b..11de99c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -43,7 +43,6 @@ M: maintainers@dpdk.org
Documentation (with overlaps)
-------------
-M: Siobhan Butler <siobhan.a.butler@intel.com>
M: John McNamara <john.mcnamara@intel.com>
F: README
F: doc/
--
2.7.4
^ permalink raw reply related
* [PATCH] virtio: tx with can_push when VERSION_1 is set
From: Pierre Pfister (ppfister) @ 2016-11-08 9:31 UTC (permalink / raw)
To: dev@dpdk.org
Current virtio driver advertises VERSION_1 support,
but does not handle device's VERSION_1 support when
sending packets (it looks for ANY_LAYOUT feature,
which is absent).
This patch enables 'can_push' in tx path when VERSION_1
is advertised by the device.
This significantly improves small packets forwarding rate
towards devices advertising VERSION_1 feature.
Signed-off-by: Pierre Pfister <ppfister@cisco.com>
---
drivers/net/virtio/virtio_rxtx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index 724517e..2fe0338 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -925,7 +925,8 @@ virtio_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
}
/* optimize ring usage */
- if (vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) &&
+ if ((vtpci_with_feature(hw, VIRTIO_F_ANY_LAYOUT) ||
+ vtpci_with_feature(hw, VIRTIO_F_VERSION_1)) &&
rte_mbuf_refcnt_read(txm) == 1 &&
RTE_MBUF_DIRECT(txm) &&
txm->nb_segs == 1 &&
--
2.7.4 (Apple Git-66)
^ permalink raw reply related
* Re: [PATCH v2] net/virtio: cache Rx/Tx offload ability check
From: Olivier Matz @ 2016-11-08 8:43 UTC (permalink / raw)
To: Yuanhan Liu, dev
In-Reply-To: <1478269793-11082-1-git-send-email-yuanhan.liu@linux.intel.com>
Hi Yuanhan,
On 11/04/2016 03:29 PM, Yuanhan Liu wrote:
> It's not a good idea to do the check of whether Rx/Tx offload is
> enabled at the data path. Instead, we could do the check at init
> stage and store the result, so that we could avoid the check again
> and again at the critical datapath.
>
> Cc: Olivier Matz <olivier.matz@6wind.com>
> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> ---
> v2: - rebase on top of the bug fix patches
> - define rx/tx_offload as uint8_t instead of int
>
> drivers/net/virtio/virtio_ethdev.c | 19 +++++++++++++++++++
> drivers/net/virtio/virtio_pci.h | 2 ++
> drivers/net/virtio/virtio_rxtx.c | 31 +++++--------------------------
> 3 files changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
> index 1505f67..2adae58 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1188,6 +1188,22 @@ rx_func_get(struct rte_eth_dev *eth_dev)
> eth_dev->rx_pkt_burst = &virtio_recv_pkts;
> }
>
> +static inline int
> +rx_offload_enabled(struct virtio_hw *hw)
> +{
> + return vtpci_with_feature(hw, VIRTIO_NET_F_GUEST_CSUM) ||
> + vtpci_with_feature(hw, VIRTIO_NET_F_GUEST_TSO4) ||
> + vtpci_with_feature(hw, VIRTIO_NET_F_GUEST_TSO6);
> +}
> +
> +static inline int
> +tx_offload_enabled(struct virtio_hw *hw)
> +{
> + return vtpci_with_feature(hw, VIRTIO_NET_F_CSUM) ||
> + vtpci_with_feature(hw, VIRTIO_NET_F_HOST_TSO4) ||
> + vtpci_with_feature(hw, VIRTIO_NET_F_HOST_TSO6);
> +}
Do we need these functions to be inlined?
It looks better to do like this, but out of curiosity, do you see a
performance improvement?
Regards,
Olivier
^ permalink raw reply
* [PATCH 2/2] net/thunderx: add cn83xx support
From: Jerin Jacob @ 2016-11-08 6:31 UTC (permalink / raw)
To: dev; +Cc: thomas.monjalon, bruce.richardson, Jerin Jacob
In-Reply-To: <1478586686-14109-1-git-send-email-jerin.jacob@caviumnetworks.com>
83xx NIC subsystem differs in new PCI subsystem_device_id and
NICVF_CAP_DISABLE_APAD capability.
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
doc/guides/nics/thunderx.rst | 1 +
drivers/net/thunderx/base/nicvf_hw.c | 4 ++++
drivers/net/thunderx/base/nicvf_hw.h | 1 +
drivers/net/thunderx/nicvf_ethdev.c | 7 +++++++
4 files changed, 13 insertions(+)
diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
index 9763bb6..187c9a4 100644
--- a/doc/guides/nics/thunderx.rst
+++ b/doc/guides/nics/thunderx.rst
@@ -62,6 +62,7 @@ Supported ThunderX SoCs
-----------------------
- CN88xx
- CN81xx
+- CN83xx
Prerequisites
-------------
diff --git a/drivers/net/thunderx/base/nicvf_hw.c b/drivers/net/thunderx/base/nicvf_hw.c
index a69cd02..04b3b69 100644
--- a/drivers/net/thunderx/base/nicvf_hw.c
+++ b/drivers/net/thunderx/base/nicvf_hw.c
@@ -146,6 +146,10 @@ nicvf_base_init(struct nicvf *nic)
if (nicvf_hw_version(nic) == PCI_SUB_DEVICE_ID_CN81XX_NICVF)
nic->hwcap |= NICVF_CAP_TUNNEL_PARSING | NICVF_CAP_CQE_RX2;
+ if (nicvf_hw_version(nic) == PCI_SUB_DEVICE_ID_CN83XX_NICVF)
+ nic->hwcap |= NICVF_CAP_TUNNEL_PARSING | NICVF_CAP_CQE_RX2 |
+ NICVF_CAP_DISABLE_APAD;
+
return NICVF_OK;
}
diff --git a/drivers/net/thunderx/base/nicvf_hw.h b/drivers/net/thunderx/base/nicvf_hw.h
index cf68be9..14fb2fe 100644
--- a/drivers/net/thunderx/base/nicvf_hw.h
+++ b/drivers/net/thunderx/base/nicvf_hw.h
@@ -43,6 +43,7 @@
#define PCI_SUB_DEVICE_ID_CN88XX_PASS1_NICVF 0xA11E
#define PCI_SUB_DEVICE_ID_CN88XX_PASS2_NICVF 0xA134
#define PCI_SUB_DEVICE_ID_CN81XX_NICVF 0xA234
+#define PCI_SUB_DEVICE_ID_CN83XX_NICVF 0xA334
#define NICVF_ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
index 501c8c2..466e49c 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -2097,6 +2097,13 @@ static const struct rte_pci_id pci_id_nicvf_map[] = {
.subsystem_device_id = PCI_SUB_DEVICE_ID_CN81XX_NICVF,
},
{
+ .class_id = RTE_CLASS_ANY_ID,
+ .vendor_id = PCI_VENDOR_ID_CAVIUM,
+ .device_id = PCI_DEVICE_ID_THUNDERX_NICVF,
+ .subsystem_vendor_id = PCI_VENDOR_ID_CAVIUM,
+ .subsystem_device_id = PCI_SUB_DEVICE_ID_CN83XX_NICVF,
+ },
+ {
.vendor_id = 0,
},
};
--
2.5.5
^ permalink raw reply related
* [PATCH 1/2] net/thunderx: disable l3 alignment pad feature
From: Jerin Jacob @ 2016-11-08 6:31 UTC (permalink / raw)
To: dev; +Cc: thomas.monjalon, bruce.richardson, Jerin Jacob
In-Reply-To: <1478586686-14109-1-git-send-email-jerin.jacob@caviumnetworks.com>
Based on the packet type(IPv4 or IPv6), the nicvf HW aligns
L3 data to the 64bit memory address.
The alignment creates a hole in mbuf(between the
end of headroom and packet data start).
The new revision of the HW provides an option to disable
the L3 alignment feature and make mbuf layout looks
more like other NICs. For better application compatibility,
disabling l3 alignment feature on the hardware revisions it supports.
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
---
drivers/net/thunderx/base/nicvf_hw.c | 18 ++++++++++++++++++
drivers/net/thunderx/base/nicvf_hw.h | 4 ++++
drivers/net/thunderx/base/nicvf_hw_defs.h | 2 ++
drivers/net/thunderx/nicvf_ethdev.c | 10 ++++++++++
4 files changed, 34 insertions(+)
diff --git a/drivers/net/thunderx/base/nicvf_hw.c b/drivers/net/thunderx/base/nicvf_hw.c
index 1f08ef2..a69cd02 100644
--- a/drivers/net/thunderx/base/nicvf_hw.c
+++ b/drivers/net/thunderx/base/nicvf_hw.c
@@ -725,6 +725,24 @@ nicvf_vlan_hw_strip(struct nicvf *nic, bool enable)
}
void
+nicvf_apad_config(struct nicvf *nic, bool enable)
+{
+ uint64_t val;
+
+ /* APAD always enabled in this device */
+ if (!(nic->hwcap & NICVF_CAP_DISABLE_APAD))
+ return;
+
+ val = nicvf_reg_read(nic, NIC_VNIC_RQ_GEN_CFG);
+ if (enable)
+ val &= ~(1ULL << NICVF_QS_RQ_DIS_APAD_SHIFT);
+ else
+ val |= (1ULL << NICVF_QS_RQ_DIS_APAD_SHIFT);
+
+ nicvf_reg_write(nic, NIC_VNIC_RQ_GEN_CFG, val);
+}
+
+void
nicvf_rss_set_key(struct nicvf *nic, uint8_t *key)
{
int idx;
diff --git a/drivers/net/thunderx/base/nicvf_hw.h b/drivers/net/thunderx/base/nicvf_hw.h
index 2b8738b..cf68be9 100644
--- a/drivers/net/thunderx/base/nicvf_hw.h
+++ b/drivers/net/thunderx/base/nicvf_hw.h
@@ -54,6 +54,8 @@
#define NICVF_CAP_TUNNEL_PARSING (1ULL << 0)
/* Additional word in Rx descriptor to hold optional tunneling extension info */
#define NICVF_CAP_CQE_RX2 (1ULL << 1)
+/* The device capable of setting NIC_CQE_RX_S[APAD] == 0 */
+#define NICVF_CAP_DISABLE_APAD (1ULL << 2)
enum nicvf_tns_mode {
NIC_TNS_BYPASS_MODE,
@@ -217,6 +219,8 @@ uint32_t nicvf_qsize_sq_roundup(uint32_t val);
void nicvf_vlan_hw_strip(struct nicvf *nic, bool enable);
+void nicvf_apad_config(struct nicvf *nic, bool enable);
+
int nicvf_rss_config(struct nicvf *nic, uint32_t qcnt, uint64_t cfg);
int nicvf_rss_term(struct nicvf *nic);
diff --git a/drivers/net/thunderx/base/nicvf_hw_defs.h b/drivers/net/thunderx/base/nicvf_hw_defs.h
index e144d44..00dd2fe 100644
--- a/drivers/net/thunderx/base/nicvf_hw_defs.h
+++ b/drivers/net/thunderx/base/nicvf_hw_defs.h
@@ -105,6 +105,8 @@
#define NICVF_INTR_MBOX_SHIFT 22
#define NICVF_INTR_QS_ERR_SHIFT 23
+#define NICVF_QS_RQ_DIS_APAD_SHIFT 22
+
#define NICVF_INTR_CQ_MASK (0xFF << NICVF_INTR_CQ_SHIFT)
#define NICVF_INTR_SQ_MASK (0xFF << NICVF_INTR_SQ_SHIFT)
#define NICVF_INTR_RBDR_MASK (0x03 << NICVF_INTR_RBDR_SHIFT)
diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
index 094c5d5..501c8c2 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -1527,6 +1527,16 @@ nicvf_vf_start(struct rte_eth_dev *dev, struct nicvf *nic, uint32_t rbdrsz)
/* Configure VLAN Strip */
nicvf_vlan_hw_strip(nic, dev->data->dev_conf.rxmode.hw_vlan_strip);
+ /* Based on the packet type(IPv4 or IPv6), the nicvf HW aligns L3 data
+ * to the 64bit memory address.
+ * The alignment creates a hole in mbuf(between the end of headroom and
+ * packet data start). The new revision of the HW provides an option to
+ * disable the L3 alignment feature and make mbuf layout looks
+ * more like other NICs. For better application compatibility, disabling
+ * l3 alignment feature on the hardware revisions it supports
+ */
+ nicvf_apad_config(nic, false);
+
/* Get queue ranges for this VF */
nicvf_tx_range(dev, nic, &tx_start, &tx_end);
--
2.5.5
^ permalink raw reply related
* [PATCH 0/2] net/thunderx: add 83xx SoC support
From: Jerin Jacob @ 2016-11-08 6:31 UTC (permalink / raw)
To: dev; +Cc: thomas.monjalon, bruce.richardson, Jerin Jacob
CN83xx is 24 core version of ThunderX ARMv8 SoC with integrated
octeon style packet and crypto accelerators.
The standard NIC block used in 88xx/81xx also included in 83xx.
This patchset adds support for existing standard NIC block on 83xx by
adding new HW capability flag to select the difference in runtime.
Jerin Jacob (2):
net/thunderx: disable l3 alignment pad feature
net/thunderx: add cn83xx support
doc/guides/nics/thunderx.rst | 1 +
drivers/net/thunderx/base/nicvf_hw.c | 22 ++++++++++++++++++++++
drivers/net/thunderx/base/nicvf_hw.h | 5 +++++
drivers/net/thunderx/base/nicvf_hw_defs.h | 2 ++
drivers/net/thunderx/nicvf_ethdev.c | 17 +++++++++++++++++
5 files changed, 47 insertions(+)
--
2.5.5
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox