From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C5BE4A04D5; Sat, 16 Nov 2019 02:52:12 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0D7402C30; Sat, 16 Nov 2019 02:52:12 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 2B5F62C16 for ; Sat, 16 Nov 2019 02:52:09 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2019 17:52:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,310,1569308400"; d="scan'208";a="356279204" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga004.jf.intel.com with ESMTP; 15 Nov 2019 17:52:08 -0800 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 15 Nov 2019 17:52:08 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 15 Nov 2019 17:52:08 -0800 Received: from shsmsx105.ccr.corp.intel.com ([169.254.11.225]) by shsmsx102.ccr.corp.intel.com ([169.254.2.108]) with mapi id 14.03.0439.000; Sat, 16 Nov 2019 09:52:05 +0800 From: "Zhang, Qi Z" To: "Stillwell Jr, Paul M" , "Ye, Xiaolong" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2] net/ice: add flow mark hint support Thread-Index: AQHVm2YxCqWI4hoTbUe+epSwA06fFqeL6QYAgAEaMjA= Date: Sat, 16 Nov 2019 01:52:04 +0000 Message-ID: <039ED4275CED7440929022BC67E7061153DC9E5B@SHSMSX105.ccr.corp.intel.com> References: <20191115034152.21429-1-qi.z.zhang@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTc2ZTk2ZTMtMTY5Mi00YWYzLWFhMTMtMzYzOTZjYTllNGEzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidkVDdWZYOWVTeGhJNTVNTWtcL2NiQlJhZURqeStLMUI0M3BnNUpvUmVOaDFmUXZzT2tGc2RDNzF0MlMydWhYVGQifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] net/ice: add flow mark hint support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Stillwell Jr, Paul M > Sent: Saturday, November 16, 2019 12:37 AM > To: Zhang, Qi Z ; Ye, Xiaolong > Cc: dev@dpdk.org; Zhang, Qi Z > Subject: RE: [dpdk-dev] [PATCH v2] net/ice: add flow mark hint support >=20 >=20 > > -----Original Message----- > > From: dev On Behalf Of Qi Zhang > > Sent: Thursday, November 14, 2019 7:42 PM > > To: Ye, Xiaolong > > Cc: dev@dpdk.org; Zhang, Qi Z > > Subject: [dpdk-dev] [PATCH v2] net/ice: add flow mark hint support > > > > Since not all data paths support flow mark, the driver need a hint > > from application to select the correct data path if flow mark is > > required. The patch introduce a devarg "flow-mark-support" as a > > workaround solution, since a standard way is still ongoing. > > >=20 > I understand the need for this, but this seems problematic. Once a custom= er > starts using this, then it has to be in the code forever because they are= going to > expect it to work forever. Maybe this should be marked with something tha= t > indicates it is temporary? Something like the experimental tagging that i= s done > in other parts of the code? Yes, since this is a workaround solution, claim it as an experimental looks= like a good idea. But I didn't see there is any documented standard way to claim a devarg as = experimental. Not sure if that should be part of the ABI policy or already some effort to= standardize devargs is on the way. Anyway as you can see, I have below statement in ice.rst to claim this is a= workaround solution,=20 This hint should be removed when any of below condition ready. 1) all data path support flow mark (currently vPMD does not) 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced as a stan= dard way to hint.=20 And I can add words "This is experimental" to emphasized it. =20 Regards Qi >=20 > > Signed-off-by: Qi Zhang > > --- > > > > v2: > > - fix typo > > > > doc/guides/nics/ice.rst | 10 ++++++++++ > > drivers/net/ice/ice_ethdev.c | 11 ++++++++++- > > drivers/net/ice/ice_ethdev.h | 1 + > > drivers/net/ice/ice_rxtx_vec_common.h | 5 +++++ > > 4 files changed, 26 insertions(+), 1 deletion(-) > > > > diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst index > > 1a426438d..f7016d338 100644 > > --- a/doc/guides/nics/ice.rst > > +++ b/doc/guides/nics/ice.rst > > @@ -80,6 +80,16 @@ Runtime Config Options > > > > -w 80:00.0,pipeline-mode-support=3D1 > > > > +- ``Flow Mark Support`` (default ``0``) > > + > > + This is a hint to the driver to select the data path that support > > + flow mark extraction by default. This hint should be removed when > > + any of > > below condition ready. > > + 1) all data path support flow mark (currently vPMD does not) > > + 2) a new offload like RTE_DEV_RX_OFFLOAD_FLOW_MARK be introduced > > as a standard way to hint. > > + Example:: > > + > > + -w 80:00.0,flow-mark-support=3D1 > > + > > - ``Protocol extraction for per queue`` > > > > Configure the RX queues to do protocol extraction into mbuf for > > protocol diff --git a/drivers/net/ice/ice_ethdev.c > > b/drivers/net/ice/ice_ethdev.c index abf00d404..9f2cb2f40 100644 > > --- a/drivers/net/ice/ice_ethdev.c > > +++ b/drivers/net/ice/ice_ethdev.c > > @@ -23,11 +23,13 @@ > > /* devargs */ > > #define ICE_SAFE_MODE_SUPPORT_ARG "safe-mode-support" > > #define ICE_PIPELINE_MODE_SUPPORT_ARG "pipeline-mode-support" > > +#define ICE_FLOW_MARK_SUPPORT_ARG"flow-mark-support" > > #define ICE_PROTO_XTR_ARG "proto_xtr" > > > > static const char * const ice_valid_args[] =3D { > > ICE_SAFE_MODE_SUPPORT_ARG, ICE_PIPELINE_MODE_SUPPORT_ARG, > > +ICE_FLOW_MARK_SUPPORT_ARG, > > ICE_PROTO_XTR_ARG, > > NULL > > }; > > @@ -1987,6 +1989,12 @@ static int ice_parse_devargs(struct rte_eth_dev > > *dev) > > > > ret =3D rte_kvargs_process(kvlist, > > ICE_PIPELINE_MODE_SUPPORT_ARG, > > &parse_bool, &ad- > > >devargs.pipe_mode_support); > > +if (ret) > > +goto bail; > > + > > +ret =3D rte_kvargs_process(kvlist, ICE_FLOW_MARK_SUPPORT_ARG, > > +&parse_bool, &ad- > > >devargs.flow_mark_support); > > +printf("flow_mark =3D %d\n", ad->devargs.flow_mark_support); > > > > bail: > > rte_kvargs_free(kvlist); > > @@ -4571,7 +4579,8 @@ RTE_PMD_REGISTER_KMOD_DEP(net_ice, "* > igb_uio | > > uio_pci_generic | vfio-pci"); RTE_PMD_REGISTER_PARAM_STRING(net_ice, > > ICE_PROTO_XTR_ARG > > "=3D[queue:]" > > ICE_SAFE_MODE_SUPPORT_ARG "=3D<0|1>" > > - ICE_PIPELINE_MODE_SUPPORT_ARG "=3D<0|1>"); > > + ICE_PIPELINE_MODE_SUPPORT_ARG "=3D<0|1>" > > + ICE_FLOW_MARK_SUPPORT_ARG "=3D<0|1>"); > > > > RTE_INIT(ice_init_log) > > { > > diff --git a/drivers/net/ice/ice_ethdev.h > > b/drivers/net/ice/ice_ethdev.h index 4a0d37b32..4d35339a7 100644 > > --- a/drivers/net/ice/ice_ethdev.h > > +++ b/drivers/net/ice/ice_ethdev.h > > @@ -391,6 +391,7 @@ struct ice_devargs { int safe_mode_support; > > uint8_t proto_xtr_dflt; int pipe_mode_support; > > +int flow_mark_support; > > uint8_t proto_xtr[ICE_MAX_QUEUE_NUM]; }; > > > > diff --git a/drivers/net/ice/ice_rxtx_vec_common.h > > b/drivers/net/ice/ice_rxtx_vec_common.h > > index 080ca4175..086428898 100644 > > --- a/drivers/net/ice/ice_rxtx_vec_common.h > > +++ b/drivers/net/ice/ice_rxtx_vec_common.h > > @@ -268,6 +268,11 @@ ice_rx_vec_dev_check_default(struct rte_eth_dev > > *dev) { > > int i; > > struct ice_rx_queue *rxq; > > +struct ice_adapter *ad =3D > > +ICE_DEV_PRIVATE_TO_ADAPTER(dev->data->dev_private); > > + > > +if (ad->devargs.flow_mark_support) > > +return -1; > > > > for (i =3D 0; i < dev->data->nb_rx_queues; i++) { rxq =3D > > dev->data->rx_queues[i]; > > -- > > 2.13.6 >=20