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 E59E0A04DC; Mon, 26 Oct 2020 12:29:49 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5318E2BAA; Mon, 26 Oct 2020 12:29:47 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 72E8E2BA2 for ; Mon, 26 Oct 2020 12:29:44 +0100 (CET) IronPort-SDR: aHhDc60Ku2TO76GZbB6El58/lCEc+O8M5wnwjO8CzOai00Ev9nRcXzbtJ+3o3+5QERxU+Le+Sa lShEDWWZT7tA== X-IronPort-AV: E=McAfee;i="6000,8403,9785"; a="147194207" X-IronPort-AV: E=Sophos;i="5.77,419,1596524400"; d="scan'208";a="147194207" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Oct 2020 04:29:43 -0700 IronPort-SDR: rDFMgAMVvKp/LCSCDVCpTd6np27JseyYjjQjmneFmNDDUd7Mrap9oXTcNgbM/yWDCqkOaobxIk 4D/n3Lv8Z+Bw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,419,1596524400"; d="scan'208";a="360954819" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga007.jf.intel.com with ESMTP; 26 Oct 2020 04:29:43 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 26 Oct 2020 04:29:42 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 26 Oct 2020 04:29:42 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Mon, 26 Oct 2020 04:29:42 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.49) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Mon, 26 Oct 2020 04:29:41 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QsWeppWhBaWDWHI0HXXB/MgkgfS6/8gs+JoXYj2KiNweIaA8h0AFmITCQUmykIEn1vHF2QpZsAu77G9CHlx4tVPVwHNc2Yb11AhnGs/EJTUIoyNhDkVobAcqbmOgt9abtO0xBK0Um4n+RYgyL1sbrcLkxD3rupFD29ncoxAb4+h91O/7HYZznT7nSWSH11lDnThoYTAR2y78skLOJi9VFymEjQq5b+f6bwKIAfLUOz2s+iT/o+UywpoAakH2338KRoGq+8+OCjWdDLrRVbgFxzy1wPO/kr2PHqwqsoHpeYWolaCYr1qcTaUe79Q+uaViXona/i5Jhe8wCdW+s/ezuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+ztbhymfMuDmlk5oRaabpKtgRBC0vRLv1YSqAFRWNZ8=; b=Z5Z7du4zD9I0EHdFU9YXhrJmFmGodUyD2erkLBiptcTqvGrWAJd/CbSIDgvxQYBegvlFYxTRCpzuS+/hiZyK/BK9eYitmf38VrvUza5wkbyos2CPlY4CSHLwUNG5RVmOUvTHXfAuyrR46MjPyfjKjIgGlruVHXjYPbAATcqDyJ+G/nElOCcAorFJdM48t9+r/d879bg9sRISOTLcX/t/Sc80v/bXovaFZpaRAHsHg6omUlz3C5RB4ivYmenhJkqvOQv11Tw2ei+bQ6LC2/bNlbbLFVyn41YjkMwxUT9xtcj7eyWj14JUwOLuTdd8+nsNUUL3BDytOWBe65ZRMprtwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+ztbhymfMuDmlk5oRaabpKtgRBC0vRLv1YSqAFRWNZ8=; b=qEeMkGR3WQ1K0KDTUgzwinfsO6h+/frCSjptraGRzxW5VPFIHxBWUTm2mEPGoAtfvqnIO7yZz0/ZC8QYRIK3uXYspIDN/jtih0Zc7cUCNQBGA3nKJq8GDMfXeLa8tOw255xncRqyt3mBRrcYmpMohqmY+7ZxuolrgC29kH1PYxk= Received: from BN8PR11MB3795.namprd11.prod.outlook.com (2603:10b6:408:82::31) by BN6PR1101MB2114.namprd11.prod.outlook.com (2603:10b6:405:57::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Mon, 26 Oct 2020 11:29:38 +0000 Received: from BN8PR11MB3795.namprd11.prod.outlook.com ([fe80::e4a8:91ab:e032:b8ae]) by BN8PR11MB3795.namprd11.prod.outlook.com ([fe80::e4a8:91ab:e032:b8ae%5]) with mapi id 15.20.3477.029; Mon, 26 Oct 2020 11:29:38 +0000 From: "Wang, Haiyue" To: Olivier Matz CC: "dev@dpdk.org" , "Yigit, Ferruh" , "Guo, Jia" , "Zhang, Qi Z" , "Chen, Zhaoyan" , "Yang, Qiming" , Ray Kinsella , Neil Horman Thread-Topic: [dpdk-dev] [PATCH v1] net/ice: refactor dynamic mbuf in data extraction Thread-Index: AQHWqqA6qEQNCQS6gEmMMcgs+FcEqamprn+AgAAOSbA= Date: Mon, 26 Oct 2020 11:29:37 +0000 Message-ID: References: <20201025071352.221953-1-haiyue.wang@intel.com> <20201026102215.GK1898@platinum> In-Reply-To: <20201026102215.GK1898@platinum> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.147.209] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b662d16-886c-4ff6-9822-08d879a26c39 x-ms-traffictypediagnostic: BN6PR1101MB2114: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZjLqb2Dd9HIlBTXAXiMNOuHYRI7OAf5rnDAmo9GlnfZM3+ILjwtBcrRcrkC8vem/UFZToSX6hrqq8dLa49oWI760kr2lq8UZWTxrACIXxt7uLSD+ZZfFwiwmRGaOtODID15ZVABm2cYQAifwRB0LhAi+MHfGx+u+rIYamUG5xjFjeW7wDobvv/wdaTvp+L4fUkna7kge0yhEiGTxaAtB80cv7W3MpPTziMlpOHFlIK14PyzCBwBfglBsGRZNLWXodYC+DP/l7+tdfEJOZ94NDP6jpwtRO0oh5Y1eKw2pAygw5HSxcXjM7vbBbvIvc7giddjx3N/2FmyS88eWlVRe1+k5qXqawO0GaOTkulzjhI1SfUbno58/l4ByGY+6JPUzsm/DQ2kKY4S34NZmPyao+A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3795.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(396003)(346002)(376002)(366004)(66476007)(86362001)(66946007)(6916009)(8936002)(966005)(4326008)(33656002)(7696005)(26005)(53546011)(6506007)(8676002)(186003)(54906003)(83380400001)(55016002)(66446008)(2906002)(66556008)(76116006)(9686003)(478600001)(316002)(64756008)(52536014)(71200400001)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: OSKvWT3gqKlTw6QKcWsEa1E+Uwtf/Tr98W7Q7eeJHw+06BNITE8AkdbqSyf9ok4QyKwc1BtxfWTVpdpGBE0iMQep4+Kf0YxsbBkawWNC+GTgY6xaYv/Dml5a8wK0k/OlZvjTDyA6KD3xgUVDUBnzges9rtBgr6QA2kOcJhJI9Z4mguu1ZnGsIrsafgjLeg+RJDFPK6Lrg0D1DwmDmV/ym/Va7lf9BuVMe8EuwhecDNGdCiebeAGw1+uHyb52FrOycsgAWvtSmMTwm6DRBDCcwf59ZbKk3k81wHfdJHYnwlEE1HMRTBydLkGUbiV8PADjBt6+QJkREaJAmfLLpXLGDuJZYAMjzeJhC67WG5ILGjJhEn/ySAc9JkgAk2R++OHo4sGT1B6z1Web2kqQxqcqJPXdoM6rjUcDw3j+uX37g5iFz9m9Lly7HddVErVwbl3+yzkncZC1phrWj0Bxfx8/B4DokO8KbahTmIOWwVeJpMKW0Fy5egXQxxHOm28mFpEXmy9G+Vihi+gHmjaDov441xmq4M5Q4ujFQHGECNHc0/myicvJA7Llsw4NXiFGmNMd80C2U8iS0w+SqithRDK0jhrRb+D4z+RlXbnPDX9WXK0E1iDIQYQDI2Dfvs7F2DtILX+hzF6iy7E1Sfu8aO6R5A== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR11MB3795.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b662d16-886c-4ff6-9822-08d879a26c39 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2020 11:29:37.8023 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: l/Ihy08N316jSq2gg9Z6WFHTga05NUMdXdl7ad88aLEyhtC3YEBMReoo09ytwAtx9++a66+y5niuBufEBSSP7g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2114 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v1] net/ice: refactor dynamic mbuf in data extraction 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" Hi Olivier, > -----Original Message----- > From: Olivier Matz > Sent: Monday, October 26, 2020 18:22 > To: Wang, Haiyue > Cc: dev@dpdk.org; Yigit, Ferruh ; Guo, Jia ; Zhang, Qi Z > ; Chen, Zhaoyan ; Yang, Qim= ing ; > Ray Kinsella ; Neil Horman > Subject: Re: [dpdk-dev] [PATCH v1] net/ice: refactor dynamic mbuf in data= extraction >=20 > Hi Haiyue, >=20 > On Sun, Oct 25, 2020 at 03:13:52PM +0800, Haiyue Wang wrote: > > Current dynamic mbuf design is that the driver will register the needed > > field and flags at the device probing time, this will make iavf PMD use > > different names to register the dynamic mbuf field and flags, but both > > of them use the exactly same protocol extraction metadata. > > > > This will run out of the limited dynamic mbuf resource, meanwhile, the > > application has to handle the dynamic mbuf separately. > > > > For making things simple and consistent, refactor dynamic mbuf in data > > extraction handling: the PMD just lookups the same name at the queue > > setup time after the application registers it. > > > > In other words, make the dynamic mbuf string name as API, not the data > > object which is defined in each PMD. >=20 > In case the dynamic mbuf field is shared by several PMDs, it seems to > be indeed a better solution. >=20 > Currently, the "union rte_pmd_proto_xtr_metadata" is still defined in > rte_pmd_ice.h. Will it be the same for iavf, and will it be factorized > somewhere? However I don't know where could be a good place. >=20 > There is already lib/librte_mbuf/rte_mbuf_dyn.h which is the place to > centralize the name and description of dynamic fields/flags used in > libraries. But I think neither structure definitions nor PMD-specific > flags should go there too. I'd prefer to have them in > drivers/net/, but I'm not sure it is possible. May be new 'lib/librte_mbuf/rte_mbuf_dyn_pmd.h' for all PMDs specific ? So that the application knows exactly how many *dynamic* things. Also, a new API to query the dynamic information + dev_ops may be introduced in next release cycle, then 'rte_pmd_mlx5_get_dyn_flag_names' can be removed. And the application will be clean. Currently, we use " #define __INTEL_RX_FLEX_DESC_METADATA__ " to fix the duplicated definition, but the application have to include the two header files like "rte_pmd_ice.h" / "rte_pmd_iavf.h" >=20 > Also, it is difficult from the patch to see the impact it has on an > application that was using these metadata. Should we have an example > of use? >=20 Thanks your link in previous mail: http://inbox.dpdk.org/dev/20191030165626.w3flq5wdpitpsv2v@platinum/ Original patch uses: Solution 1, provide static inline helpers to access to= the dyn fields/flags Now now: Solution 2, without global variable export and helpers: the applic= ation calls rte_mbuf_dynfield_register(&rte_pmd_ice_proto_xtr_metadata_param) to = get the offset, and store it privately. https://patchwork.dpdk.org/patch/82165/ In v3 patch, I kept the metadata format, and rename it to be more generic: 'union rte_pmd_proto_xtr_metadata', but no dump function as the original de= sign. > Thanks, > Olivier >=20 >=20 > > Signed-off-by: Haiyue Wang > > --- > > 2.29.0 > >