From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shreyansh Jain Subject: Re: [PATCH 36/38] net/dpaa: add support for checksum offload Date: Tue, 4 Jul 2017 20:18:32 +0530 Message-ID: <57009209-0372-6c70-937d-826cee0efd1b@nxp.com> References: <1497591668-3320-1-git-send-email-shreyansh.jain@nxp.com> <1497591668-3320-37-git-send-email-shreyansh.jain@nxp.com> <93a8a45b-01d1-608d-f3df-92551df6e476@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: , To: Ferruh Yigit Return-path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0073.outbound.protection.outlook.com [104.47.33.73]) by dpdk.org (Postfix) with ESMTP id 1B4095699 for ; Tue, 4 Jul 2017 16:39:28 +0200 (CEST) In-Reply-To: <93a8a45b-01d1-608d-f3df-92551df6e476@intel.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hello Ferruh, On Wednesday 28 June 2017 09:20 PM, Ferruh Yigit wrote: > On 6/16/2017 6:41 AM, Shreyansh Jain wrote: >> Signed-off-by: Hemant Agrawal >> Signed-off-by: Shreyansh Jain > > <...> > >> @@ -363,6 +439,18 @@ dpaa_eth_queue_tx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs) >> } >> rte_pktmbuf_free(mbuf); >> } >> + if (mbuf->ol_flags & DPAA_TX_CKSUM_OFFLOAD_MASK) { >> + if (mbuf->data_off < DEFAULT_TX_ICEOF + >> + sizeof(struct dpaa_eth_parse_results_t)) { >> + PMD_DRV_LOG(DEBUG, "Checksum offload Err: " >> + "Not enough Headroom " >> + "space for correct Checksum offload." >> + "So Calculating checksum in Software."); >> + dpaa_checksum(mbuf); >> + } else >> + dpaa_checksum_offload(mbuf, &fd_arr[loop], >> + mbuf->buf_addr); >> + } > > There is a tx_pkt_prepare() dev_ops. > Does it make sense to move this calculations to that function? I did have a look at this before sending the v2. In case of DPAA driver, it is not possible to segregate the preparation phase from transmission phase. Further, there are still applications which don't call the prep function - in those cases, the I/O wouldn't happen. And, making an internal call to prep (on basis of some (!prep) checks), is performance impact. > >> } else { >> PMD_DRV_LOG(DEBUG, "Number of Segments not supported"); >> /* Set frames_to_send & nb_bufs so that > > <...> > - Shreyansh