From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Mody, Rasesh" <Rasesh.Mody@cavium.com>
Subject: Re: [PATCH v2 61/61] net/qede: add LRO/TSO offloads
	support
Date: Sat, 25 Mar 2017 06:28:02 +0000
Message-ID: <BLUPR0701MB15729D59DFCC36F5706F70799F310@BLUPR0701MB1572.namprd07.prod.outlook.com>
References: <162b5be7-d8a5-0e89-a32f-b1a992aef2a3@intel.com>
 <1489820786-14226-62-git-send-email-rasesh.mody@cavium.com>
 <fbf28517-2dcc-b8e0-5233-3eea9f1afd38@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: Harish Patil <harish.patil@qlogic.com>, Dept-Eng DPDK Dev
 <Dept-EngDPDKDev@cavium.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM03-CO1-obe.outbound.protection.outlook.com
 (mail-co1nam03on0056.outbound.protection.outlook.com [104.47.40.56])
 by dpdk.org (Postfix) with ESMTP id 449CDF8AA
 for <dev@dpdk.org>; Sat, 25 Mar 2017 07:28:04 +0100 (CET)
In-Reply-To: <fbf28517-2dcc-b8e0-5233-3eea9f1afd38@intel.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
> Sent: Friday, March 24, 2017 4:59 AM
>=20
> On 3/18/2017 7:06 AM, Rasesh Mody wrote:
> > From: Harish Patil <harish.patil@qlogic.com>
> >
> > This patch includes slowpath configuration and fastpath changes to
> > support LRO and TSO. A bit of revamping is needed in order to make use
> > of existing packet classification schemes in Rx fastpath and for SG
> > element processing in Tx.
> >
> > Signed-off-by: Harish Patil <harish.patil@qlogic.com>
>=20
> This patch is giving following checkpatch errors [1], I can see the reaso=
n of
> the multiline dereference is to fit into 80 column line limit, and those =
lines are
> not easy to escape from line limit.
>=20
> But eventually if we get a checkpatch warning, I prefer it to be from lon=
g line,
> multiline dereference makes code harder to read.
>=20
> What do you think?

Will try to address this more efficiently.
=20
>=20
>=20
> [1]
> WARNING:MULTILINE_DEREFERENCE: Avoid multiple line dereference -
> prefer 'cqe_start_tpa->len_on_first_bd'
> #450: FILE: drivers/net/qede/qede_rxtx.c:1045:
> +                                   rte_le_to_cpu_16(cqe_start_tpa->
> +                                                    len_on_first_bd),
>=20
> WARNING:MULTILINE_DEREFERENCE: Avoid multiple line dereference -
> prefer 'cqe_start_tpa->ext_bd_len_list[0]'
> #453: FILE: drivers/net/qede/qede_rxtx.c:1048:
> +                                   rte_le_to_cpu_16(cqe_start_tpa->
> +
> + ext_bd_len_list[0]),
>=20
> WARNING:MULTILINE_DEREFERENCE: Avoid multiple line dereference -
> prefer 'rxq->tpa_info[cqe->fast_path_tpa_end.tpa_agg_index].mbuf'
> #465: FILE: drivers/net/qede/qede_rxtx.c:1060:
> +                       rx_mb =3D rxq->
> +
> + tpa_info[cqe->fast_path_tpa_end.tpa_agg_index].mbuf;
>=20
> WARNING:MULTILINE_DEREFERENCE: Avoid multiple line dereference -
> prefer 'cqe_start_tpa->pars_flags.flags'
> #512: FILE: drivers/net/qede/qede_rxtx.c:1087:
> +                       parse_flag =3D rte_le_to_cpu_16(cqe_start_tpa->
> +
> + pars_flags.flags);
>=20
> WARNING:MULTILINE_DEREFERENCE: Avoid multiple line dereference -
> prefer 'cqe_start_tpa->tunnel_pars_flags.flags'
> #541: FILE: drivers/net/qede/qede_rxtx.c:1108:
> +                                       tunn_parse_flag =3D
> + cqe_start_tpa->
> +
> tunnel_pars_flags.flags;
>=20
> WARNING:MULTILINE_DEREFERENCE: Avoid multiple line dereference -
> prefer 'fp_cqe->tunnel_pars_flags.flags'
> #544: FILE: drivers/net/qede/qede_rxtx.c:1111:
> +                                       tunn_parse_flag =3D fp_cqe->
> +
> tunnel_pars_flags.flags;
>=20
>=20
> <...>