DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Sexton, Rory" <rory.sexton@intel.com>
To: "Wu, Jingjing" <jingjing.wu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Marjanovic, Nemanja" <nemanja.marjanovic@intel.com>,
	"Mcnamara, John" <john.mcnamara@intel.com>
Subject: Re: [dpdk-dev] [PATCH v1] net/i40e: set no drop for traffic class
Date: Fri, 9 Dec 2016 14:02:49 +0000	[thread overview]
Message-ID: <EAC303C93824C94DB804849C22B752B30D2B20A0@IRSMSX104.ger.corp.intel.com> (raw)
In-Reply-To: <9BB6961774997848B5B42BEC655768F80E2C29D0@SHSMSX103.ccr.corp.intel.com>

Hi Jingjing,

Yes PRTDCB_TC2PFC is used to control pfc for each TC however we have noticed other advantages of using the register.
By setting the register explicitly by doing the "I40E_WRITE_REG(hw, 0x1c0980, 0xff);" it allows for packets to be temporarily stored on the NICs RX SRAM until there is space for them on SW descriptor ring versus dropping them when the SW ring becomes full. This also allows for larger burst handling. It also means SW doesn't have to be as quick to empty the DRAM based descriptor rings, allowing more processing on cores. 

I have tested using the ETH_DCB_PFC_SUPPORT flag in rte_eth_conf.dcb_capability_en and rte_eth_dcb_rx_conf.nb_tcs. 
This results in the NIC's RX SRAM not being used and if there is no space on SW descriptor ring for packet it is dropped. 
The advantages of using the PRTDCB_TC2PFC explicitly is that there will be no packet loss and descriptor rings do not need to be modified (can be left at 128 for rx and 512 for tx as default settings for apps).  Enabling via this register allows Burst handling to be within the NIC Rx Buffer and SW rings combined. 
At the moment for tests the rx and tx descriptor rings have to be increased to 2048 to eliminate packet loss.

Ideally it would be an optional setting as using it may increase the max latency.


Regards,
Rory/Nemanja

-----Original Message-----
From: Wu, Jingjing 
Sent: Monday, December 5, 2016 8:45 AM
To: Sexton, Rory <rory.sexton@intel.com>
Cc: dev@dpdk.org; Marjanovic, Nemanja <nemanja.marjanovic@intel.com>; Mcnamara, John <john.mcnamara@intel.com>
Subject: RE: [PATCH v1] net/i40e: set no drop for traffic class



-----Original Message-----
From: Sexton, Rory
Sent: Sunday, December 4, 2016 9:55 PM
To: Wu, Jingjing <jingjing.wu@intel.com>
Cc: dev@dpdk.org; Marjanovic, Nemanja <nemanja.marjanovic@intel.com>; Mcnamara, John <john.mcnamara@intel.com>; Sexton, Rory <rory.sexton@intel.com>
Subject: [PATCH v1] net/i40e: set no drop for traffic class

From: John McNamara <john.mcnamara@intel.com>

The default traffic class in i40e is set to drop versus on ixgbe it isset to no drop. This means when packets build up in the RX SRAM on the NIC, they are dropped, and they do this when the SW descriptor rings fill up.

This patch changes this behaviour and our testing shows there are no drops as a result.

Signed-off-by: Rory Sexton <rory.sexton@intel.com>
Signed-off-by: Nemanja Marjanovic <nemanja.marjanovic@intel.com>
---
 drivers/net/i40e/i40e_ethdev.c |  1 +
 drivers/net/i40e/i40e_rxtx.c   | 12 ++++++++++++
 drivers/net/i40e/i40e_rxtx.h   |  1 +
 lib/librte_ether/rte_ethdev.h  | 24 ++++++++++++++++++++++++
 4 files changed, 38 insertions(+)

diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c index 67778ba..9702acb 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -553,6 +553,7 @@ static const struct eth_dev_ops i40e_eth_dev_ops = {
 	.get_eeprom                   = i40e_get_eeprom,
 	.mac_addr_set                 = i40e_set_default_mac_addr,
 	.mtu_set                      = i40e_dev_mtu_set,
+	.set_no_drop		      = i40e_set_no_drop,
 };
 
 /* store statistics names and its offset in stats structure */ diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c index 7ae7d9f..02aeff4 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -783,6 +783,18 @@ i40e_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
 	return nb_rx;
 }
 
+uint32_t
+i40e_set_no_drop(struct rte_eth_dev *dev, uint16_t rx_queue_id) {
+	struct i40e_rx_queue *rxq = dev->data->rx_queues[rx_queue_id];
+	struct i40e_hw *hw = I40E_VSI_TO_HW(rxq->vsi);
+
+	/* Set No Drop Traffic Class. */
+	I40E_WRITE_REG(hw, 0x1c0980, 0xff);
+
+	return 1;
+}

0x1c0980 is the register (PRTDCB_TC2PFC) which is used to control pfc for each TC.
We already have ETH_DCB_PFC_SUPPORT flag in rte_eth_conf.dcb_capability_en to Control if PFC is enabled. And rte_eth_dcb_rx_conf.nb_tcs identified number of TCs It supports.
"I40E_WRITE_REG(hw, 0x1c0980, 0xff);" can be achieved by enabling DCB and PFC For all TCs.


Why do we need such a new API?


Thanks
Jingjing

--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


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.

  reply	other threads:[~2016-12-09 14:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-04 13:54 Rory Sexton
2016-12-05  8:44 ` Wu, Jingjing
2016-12-09 14:02   ` Sexton, Rory [this message]
2016-12-26  8:45     ` Wu, Jingjing
2017-01-16 15:52       ` [dpdk-dev] [PATCH v2] " rory.sexton
2017-01-17 15:09         ` Wu, Jingjing
2017-01-19 10:38           ` Sexton, Rory
2017-02-07 15:25             ` Wu, Jingjing
2017-02-09 15:34               ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EAC303C93824C94DB804849C22B752B30D2B20A0@IRSMSX104.ger.corp.intel.com \
    --to=rory.sexton@intel.com \
    --cc=dev@dpdk.org \
    --cc=jingjing.wu@intel.com \
    --cc=john.mcnamara@intel.com \
    --cc=nemanja.marjanovic@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).