From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id AD57AC320 for ; Tue, 16 Jun 2015 14:07:27 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 16 Jun 2015 05:07:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,626,1427785200"; d="scan'208";a="711896671" Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80]) by orsmga001.jf.intel.com with ESMTP; 16 Jun 2015 05:07:24 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 16 Jun 2015 20:07:21 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.246]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.46]) with mapi id 14.03.0224.002; Tue, 16 Jun 2015 20:07:20 +0800 From: "Qiu, Michael" To: "Chen, Jing D" , "dev@dpdk.org" Thread-Topic: [PATCH 3/6] fm10k: Fix data integrity issue with multi-segment frame Thread-Index: AQHQmeb/8qE4H84CX0C+XqoeAzgDTg== Date: Tue, 16 Jun 2015 12:07:19 +0000 Message-ID: <533710CFB86FA344BFBF2D6802E602860469C48C@SHSMSX101.ccr.corp.intel.com> References: <1432887044-24777-1-git-send-email-jing.d.chen@intel.com> <1432887044-24777-4-git-send-email-jing.d.chen@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "He, Shaopeng" Subject: Re: [dpdk-dev] [PATCH 3/6] fm10k: Fix data integrity issue with multi-segment frame X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 12:07:28 -0000 Tested-by: Michael Qiu =0A= =0A= - OS: Fedora20 3.11.10-301=0A= - GCC: gcc version 4.8.3 2014911=0A= - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz=0A= - NIC: Ethernet controller: Intel Corporation Device 15a4 (rev 01)=0A= - Default x86_64-native-linuxapp-gcc configuration=0A= =0A= - Total 5 cases, 5 passed, 0 failed=0A= =0A= - Case: Normal frames with no jumbo frame support=0A= - Case: Jumbo frames with no jumbo frame support=0A= - Case: Normal frames with jumbo frame support=0A= - Case: Jumbo frames with jumbo frame support=0A= - Case: Frames bigger than jumbo frames, wwith jumbo frame support=0A= =0A= =0A= On 5/29/2015 4:11 PM, Chen, Jing D wrote:=0A= > From: "Chen Jing D(Mark)" =0A= >=0A= > In TX side, bit FM10K_TXD_FLAG_LAST in TX descriptor only is set=0A= > in the last descriptor for multi-segment packets. But current=0A= > implementation didn't set all the fields of TX descriptor, which=0A= > will cause descriptors processed now to re-use fields set in last=0A= > scroll. If FM10K_TXD_FLAG_LAST bit was set in the last round and=0A= > it happened this is not the last descriptor of a multi-segnment=0A= > packet, HW will send out the incomplete packet out and leads to=0A= > data intergrity issue.=0A= >=0A= > Signed-off-by: Chen Jing D(Mark) =0A= > ---=0A= > drivers/net/fm10k/fm10k_rxtx.c | 15 +++++++++++++--=0A= > 1 files changed, 13 insertions(+), 2 deletions(-)=0A= >=0A= > diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxt= x.c=0A= > index 56df6cd..f5d1ad0 100644=0A= > --- a/drivers/net/fm10k/fm10k_rxtx.c=0A= > +++ b/drivers/net/fm10k/fm10k_rxtx.c=0A= > @@ -402,9 +402,9 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queue = *q, struct rte_mbuf *mb)=0A= > q->nb_used =3D q->nb_used + mb->nb_segs;=0A= > }=0A= > =0A= > - q->hw_ring[last_id].flags =3D flags;=0A= > q->nb_free -=3D mb->nb_segs;=0A= > =0A= > + q->hw_ring[q->next_free].flags =3D 0;=0A= > /* set checksum flags on first descriptor of packet. SCTP checksum=0A= > * offload is not supported, but we do not explicitly check for this=0A= > * case in favor of greatly simplified processing. */=0A= > @@ -415,16 +415,27 @@ static inline void tx_xmit_pkt(struct fm10k_tx_queu= e *q, struct rte_mbuf *mb)=0A= > if (mb->ol_flags & PKT_TX_VLAN_PKT)=0A= > q->hw_ring[q->next_free].vlan =3D mb->vlan_tci;=0A= > =0A= > + q->sw_ring[q->next_free] =3D mb;=0A= > + q->hw_ring[q->next_free].buffer_addr =3D=0A= > + rte_cpu_to_le_64(MBUF_DMA_ADDR(mb));=0A= > + q->hw_ring[q->next_free].buflen =3D=0A= > + rte_cpu_to_le_16(rte_pktmbuf_data_len(mb));=0A= > + if (++q->next_free =3D=3D q->nb_desc)=0A= > + q->next_free =3D 0;=0A= > +=0A= > /* fill up the rings */=0A= > - for (; mb !=3D NULL; mb =3D mb->next) {=0A= > + for (mb =3D mb->next; mb !=3D NULL; mb =3D mb->next) {=0A= > q->sw_ring[q->next_free] =3D mb;=0A= > q->hw_ring[q->next_free].buffer_addr =3D=0A= > rte_cpu_to_le_64(MBUF_DMA_ADDR(mb));=0A= > q->hw_ring[q->next_free].buflen =3D=0A= > rte_cpu_to_le_16(rte_pktmbuf_data_len(mb));=0A= > + q->hw_ring[q->next_free].flags =3D 0;=0A= > if (++q->next_free =3D=3D q->nb_desc)=0A= > q->next_free =3D 0;=0A= > }=0A= > +=0A= > + q->hw_ring[last_id].flags =3D flags;=0A= > }=0A= > =0A= > uint16_t=0A= =0A=