From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 30859A0544; Mon, 10 Oct 2022 11:39:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 15D3040146; Mon, 10 Oct 2022 11:39:36 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 340C040041 for ; Mon, 10 Oct 2022 11:39:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1665394774; x=1696930774; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ESupOmHF7sIIqMH3RkCqvO5dFe0zzvLibyfkBGFTLgY=; b=iqflixVQpsmKP+J0ZyYqc4rZeDxGA3AUHh58rQq2iAyubh1mSCsAQL3/ Ft2iIcwG+Ec5PIeGrkahe3eNHD9ZDG4HxGFszgK2yWIVprY1Y5S49Wo0T 8x7WvB08ilJpaeyrWHX0LAsemQLf8os2RmykJ4CjZkhlWy5uPzuOdiZzM y6q7iL5F9dVxbksPkrtcCSlzMlj247MjDLJhVYA1BQYw08YHgNq80RO5u 54pxubkS43bDqbga9XNrUlKv33QLN8wDFay6V2GvGTpvhl/Ob1/Trkd7R K7pAb7tSd5pDP7G4IlMHSaSMCcqNWE/Xddi8A4YiPKc3By+Pe14MB001j g==; X-IronPort-AV: E=McAfee;i="6500,9779,10495"; a="368322610" X-IronPort-AV: E=Sophos;i="5.95,173,1661842800"; d="scan'208";a="368322610" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2022 02:39:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10495"; a="620962784" X-IronPort-AV: E=Sophos;i="5.95,173,1661842800"; d="scan'208";a="620962784" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga007.jf.intel.com with ESMTP; 10 Oct 2022 02:39:33 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 10 Oct 2022 02:39:32 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 10 Oct 2022 02:39:32 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) 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.2375.31 via Frontend Transport; Mon, 10 Oct 2022 02:39:32 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.177) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.31; Mon, 10 Oct 2022 02:39:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GjZc91mi+6wwfEZK8KrAj8xcOA5IXP4tD79lQwpbh+Ve16Ll2u447afX/fAu6CIw4UdIHMgX0ol9gD/Q0HzYVwJTKs1pGvixG5DpjrUlF2Rs3t785MWG6wvzZWWUrwR46O368VDA+kEUTFwgkTq6FCFwfmiAs76kMlGPRyzzkEISmc0nBu+ahQ3/VWVBAYUcOfyhHi2X4rgrxU4oVeogVnvif9ejR50EwYbXHA4zCcAIxh/1xd5Kt/jlyfkbUDranSm9QVpLovhwWRFVuu0XtcdCdmMWsHU1fbomLTYIvpT5PiceGeuiZ868x0Pp89md36iHwt8IvrFwsViXWVIJvA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Vwwes6c0GyiGUKVbwYyCMiwYZlr/mTtrjK1wEcJFSf0=; b=LYz4CtQPML4uGc8HRf6+xpXArKebYRGsmB374EuX9qY1gaPxK6ZQEs9ENOELFLYpo/lq2Ms8EWvfLPn4+oNEJ5llxO5cvMNXT42NLLMkpDGoiVOxfDiyk5JXQ9XEjk2vOThOCOfTYusT8UGPKwRIpda3Wgplh1CRHa9nrQT+JIiJtto6aa/mJSm2K4m+3R3x7IflaTb7oYw3+7TQX1k6aaNtkZ2m2W0EA+2DRkwG8jAjd92QXYNS5lXL9tAAyEqJKYKlniySdpTgj2RxQaKs1q+EaDC27uEsky050gAXiTDIAD0m7aH5QNsq3FADVdJuvMDl0/fFzMifhxI0foCy5w== 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 Received: from CH0PR11MB5523.namprd11.prod.outlook.com (2603:10b6:610:d6::15) by DM4PR11MB6432.namprd11.prod.outlook.com (2603:10b6:8:ba::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.20; Mon, 10 Oct 2022 09:39:30 +0000 Received: from CH0PR11MB5523.namprd11.prod.outlook.com ([fe80::e34:3121:2b72:3034]) by CH0PR11MB5523.namprd11.prod.outlook.com ([fe80::e34:3121:2b72:3034%6]) with mapi id 15.20.5709.015; Mon, 10 Oct 2022 09:39:30 +0000 From: "Li, Xiaoyun" To: "Guo, Junfeng" , Ferruh Yigit , "Zhang, Qi Z" , "Wu, Jingjing" CC: "ferruh.yigit@xilinx.com" , "dev@dpdk.org" , "awogbemila@google.com" , "Richardson, Bruce" , "Lin, Xueqin" Subject: RE: [PATCH v4 7/9] net/gve: add support for Rx/Tx Thread-Topic: [PATCH v4 7/9] net/gve: add support for Rx/Tx Thread-Index: AQHY0kOG7v9SNPB2rk6hjKsr2Vibka4BeiuAgARgdYCAAYpWAA== Date: Mon, 10 Oct 2022 09:39:30 +0000 Message-ID: References: <20220923093829.3019525-2-junfeng.guo@intel.com> <20220927073255.1803892-1-junfeng.guo@intel.com> <20220927073255.1803892-8-junfeng.guo@intel.com> <3e2e6a34-168f-b939-2dc3-6af319d3471a@amd.com> In-Reply-To: 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.6.500.17 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CH0PR11MB5523:EE_|DM4PR11MB6432:EE_ x-ms-office365-filtering-correlation-id: a6727b6e-bb86-4828-9058-08daaaa354ce x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /gVPGwbl4JNujl58RSF66i3X5Mbv5u3wXaPxC6y5gXjGB2Xv6DIKRQGmaTAtso+uLlZGfsEtz1Tk3WYjDhGhma/hVSQY9BKHPKRjxjhpWdg2YjmA5da6mmzzu34Ye1QjuEO2/lB4w6CKKI+GhZ9sYM5rtE3TNxuElp++LwWkHdPKZ89dt7L0YD4avkamwMnJFKSuGVK8jmGDxigXwy82wnqYTAPBTAh0m7m5S5Z2MDjXTRZjhXildVbsheX+mrN6wFKZqdQ//gcZhdhdSISNeeVwY4izo5CRnuNv4Plgwe691hh7dc/TaEVJnqbPL199bb+rPGVNpvGFlb1tLVVnRGJlGaCbM82P5SMjwdpbv9keXWDpaJwvKCkn6xb5nIkkhxO8yEa/4AdIOYYRReUl78ZwGQAHWvIbsRDjNLgpGYebU/0vEfL263u24613cvSMta1zOyagsM0f2DIOGBk/fBtGd9mAvWGE1pxcEwg9c1CDObzLlZ1IYwpS6239p6u+j2vIJAzMxGb47sX3cW7s6vvwuKgPMUPCvk/fWRvyVXFBsOluSk0BI2zMYFKKdj5uzFr5OntxNWUOFWRyPrW+fbW/cHcA/K1d1+IFJ95Ib1LbJhWqwzPFsJBdEpqP4Sn+OSl9DwMEY+Q+qDiI3J4hiAI/Uu/KNq3vZyWzVZ3JkuEydaHcYuA47Kt9y5FkZ5YE9s/EIyRFRsbaEzew9KyQ27GERLRBiZ2BOYfXCuul3rtLYRRx/3Mi0YNEtP30y1fYJ6fKooeoeT0dqaw+l5tTPENlw3koB2bYcHKuqZ/wEAc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR11MB5523.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(39860400002)(396003)(376002)(366004)(346002)(136003)(451199015)(38070700005)(76116006)(66946007)(122000001)(8676002)(66556008)(66476007)(66446008)(64756008)(4326008)(53546011)(7696005)(6636002)(55016003)(9686003)(316002)(71200400001)(6506007)(41300700001)(107886003)(83380400001)(478600001)(33656002)(186003)(54906003)(2906002)(26005)(966005)(110136005)(8936002)(52536014)(5660300002)(38100700002)(86362001)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?57Aqm7C5KESaH1sfwdp/tqVwNtPlVm6mT8Ney4uk1ck2tDjIhJ4gWoUPDMGM?= =?us-ascii?Q?1YRhSnF8jGwsW5hCDy9tWJDG3o+BzfmKAxay21KhGAK0hPCAoLr3qJV++QWr?= =?us-ascii?Q?3ZH3cCIjKYUowOIsaVHH8EPWLRUk7SQij9Ssl9K+dDQ44rApwJCxT6keqtnM?= =?us-ascii?Q?0fDyYlPQLnK3ynrNLqLV0dWETIaCN0eEAlLZbkM2AzMJ160IrZ20qDip/S4j?= =?us-ascii?Q?p8ZIro02T2OyJyLlsflLxR6mAfrGrsS9iJTNyGUSmV2xnEJ0E2eeqoLq9Mp8?= =?us-ascii?Q?mwgWgn9w2721X5JTbMad2ch9RdxbL0o+/0T0IPdQNoH0n25Gy7M39Oa8saqM?= =?us-ascii?Q?7BRacsFc4W0/tnVX95/Cer0fK12Jq6sZBh/a9G03MEpoz5O4Csdd/Bz5thie?= =?us-ascii?Q?MjX0cQlkrJsvsTiCrL5oeEGj28GRwkdAxO7ulo7jVwita6NSJljYpZAN9Rzz?= =?us-ascii?Q?CkOMEs6/ArhOdgv8QhmPGupt6Vaw5tSTyWI6zc1PRf4TD/UO5RSQQ6sSoX6t?= =?us-ascii?Q?FRRnIJK+nj9EQr7WWrhxfrjdC4iEu8J6JIJg684QzkahxuArhPSNC1dXKQh2?= =?us-ascii?Q?+ZUhya0CCjg3Xk6NzriQvfHw6R4pD3za59cqt/6AQUW4gZEboXHSMFen0YBB?= =?us-ascii?Q?2u79TjE14skGnhLOAGdaZLL9a2rCyPDzSq7PdAGCScpJUw8RUAZnpmyMtKEx?= =?us-ascii?Q?IpJr/Hj/CCM6lTOSGUkiePWo81g3yy3J/WmdCEh7AOmPbkrR9XIyG9e6ojwo?= =?us-ascii?Q?bRG9L79lL3tFVtnX4PB4j41aAykDmBXbaOjl1978II3WD/EdDB2rks5xn3S/?= =?us-ascii?Q?iIEzNpTpT17g9+KvwIB0vbb1fRstFm5LYPIrYcWwFI4aKtcW11+DyYAGTfwX?= =?us-ascii?Q?vUfPgyodB9fEmvqO2Qu0qPK1HnKLZUdVjpMwI+wtEOLChohFmqHxEanNVlRI?= =?us-ascii?Q?7g3nhuBBDTu/wXZFkZGONXZuNKIA2RMdh9TD19LeHsocynDq+GG3asoHcovr?= =?us-ascii?Q?cYz3ew95ljQPVegcF3m0bBaaTfc2IN7DOV/vlJ4dyuuXAvTsUPlIKCajJDVO?= =?us-ascii?Q?TzQCYz9O8ATx64dx/mPwijW/4pD7yzaZCzowHP3XR7m2TbAgfALvrHDDgnQa?= =?us-ascii?Q?CInlxUWjsooqUl4h00aaqdau0CWY6v+l33cnsrtVls37OfO3JmkeCYX6c/LG?= =?us-ascii?Q?fHmdqM0IZ5B/nksQb6Jyf5hbTXmkGkdceV0RGgFuysmRvN0dByiLwOiPd/S+?= =?us-ascii?Q?y0lDftFHYZ91O5nNjOj2rWqGy4J7l4zleDH6UgQCk1LSD+IK0GagQgTGb/jD?= =?us-ascii?Q?wYvkpPNart9reOuozKwxuCgCeAWTzYluMY8j+rkzcDjjVPuP10HMQOfc6DYY?= =?us-ascii?Q?nVTjOBM8ApeE0JolyINIMoqfIgwhRqbKm38a+nTzSTzVbJDIFviayqWl504t?= =?us-ascii?Q?BcCxrX4GX95OD/2p+faen85s+K5j7ywm/ouX6Gt3HbfapdxPh4szMuvtWhos?= =?us-ascii?Q?KUCP2kWlNxKXuQxXOnxWFbU25+MHq+7ZPIyrlh/YIHlg5TAlJKtAFDly7y1y?= =?us-ascii?Q?+XS/XD02nK/f2Ps2QjVIMNrws58LJ9twxUfINyNv?= 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: CH0PR11MB5523.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6727b6e-bb86-4828-9058-08daaaa354ce X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2022 09:39:30.4936 (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: NsivOJ8jQOLTO3TDXR6osYuvICW6u2eAIIh3v2oSJaqlDzUu+88HHVIxA8mTtUAyUk4VxDRlTP+hK6M+OeOyyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6432 X-OriginatorOrg: intel.com X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi > -----Original Message----- > From: Guo, Junfeng > Sent: Sunday, October 9, 2022 10:15 > To: Ferruh Yigit ; Zhang, Qi Z > ; Wu, Jingjing > Cc: ferruh.yigit@xilinx.com; dev@dpdk.org; Li, Xiaoyun > ; awogbemila@google.com; Richardson, Bruce > ; Lin, Xueqin > Subject: RE: [PATCH v4 7/9] net/gve: add support for Rx/Tx >=20 >=20 >=20 > > -----Original Message----- > > From: Ferruh Yigit > > Sent: Thursday, October 6, 2022 22:25 > > To: Guo, Junfeng ; Zhang, Qi Z > > ; Wu, Jingjing > > Cc: ferruh.yigit@xilinx.com; dev@dpdk.org; Li, Xiaoyun > > ; awogbemila@google.com; Richardson, Bruce > > ; Lin, Xueqin > > Subject: Re: [PATCH v4 7/9] net/gve: add support for Rx/Tx > > > > On 9/27/2022 8:32 AM, Junfeng Guo wrote: > > > > > > > > Add Rx/Tx of GQI_QPL queue format and GQI_RDA queue format. > > > > > > Signed-off-by: Xiaoyun Li > > > Signed-off-by: Junfeng Guo > > > > <...> > > > > > --- a/drivers/net/gve/gve_ethdev.c > > > +++ b/drivers/net/gve/gve_ethdev.c > > > @@ -583,6 +583,11 @@ gve_dev_init(struct rte_eth_dev *eth_dev) > > > if (err) > > > return err; > > > > > > + if (gve_is_gqi(priv)) { > > > + eth_dev->rx_pkt_burst =3D gve_rx_burst; > > > + eth_dev->tx_pkt_burst =3D gve_tx_burst; > > > + } > > > + > > > > What do you think to add a log here for 'else' case, to inform user > > why datapath is not working? >=20 > Agreed, make sense! > Currently only one queue mode (i.e., qpl mode) is supported on the GCP en= v. > Will add a log to inform this in the else case. Thanks! This explanation is not correct. Only QPL mode is supported in GCP now. Thi= s is env limitation but not related to the else code here. gve_is_gqi() includes two modes GQI_QPL and GQI_RDA. And both of these data= path is supported in rxtx. GQI means its queue model is single queue model (txq for tx and rxq for rx)= . And there're 2 ways for this queue model QPL and RDA. QPL needs to copy packets from/to several reserved pages negotiated with ba= ckend. RDA is just like normal device and uses PA in descs. The datapath not supported is DQO_RDA which uses different hardware so diff= erent queue model (split/double queue model). Tx will use txq and tx_comple= tion_q and Rx will use rxq and rx_completion_q. This is not implemented in the datapath for now and will be implemented in = the future. So if you want to add comment here. Please say "DQO_RDA is not implemented = and will be added in the future". Don't say it's not available in GCP env w= hich is not the reason. >=20 > > > > <...> > > > > > +uint16_t > > > +gve_rx_burst(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t > > nb_pkts) > > > +{ > > > + volatile struct gve_rx_desc *rxr, *rxd; > > > + struct gve_rx_queue *rxq =3D rx_queue; > > > + uint16_t rx_id =3D rxq->rx_tail; > > > + struct rte_mbuf *rxe; > > > + uint16_t nb_rx, len; > > > + uint64_t addr; > > > + > > > + rxr =3D rxq->rx_desc_ring; > > > + > > > + for (nb_rx =3D 0; nb_rx < nb_pkts; nb_rx++) { > > > + rxd =3D &rxr[rx_id]; > > > + if (GVE_SEQNO(rxd->flags_seq) !=3D rxq->expected_seqn= o) > > > + break; > > > + > > > + if (rxd->flags_seq & GVE_RXF_ERR) > > > + continue; > > > + > > > + len =3D rte_be_to_cpu_16(rxd->len) - GVE_RX_PAD; > > > + rxe =3D rxq->sw_ring[rx_id]; > > > + rxe->data_off =3D RTE_PKTMBUF_HEADROOM; > > > + if (rxq->is_gqi_qpl) { > > > + addr =3D (uint64_t)(rxq->qpl->mz->addr) + > > > + rx_id * PAGE_SIZE > > + GVE_RX_PAD; > > > + rte_memcpy((void *)((size_t)rxe->buf_addr + > > > + rxe- > > >data_off), > > > + (void *)(size_t)addr, len); > > > > Why a 'memcpy' is needed? Can't it DMA to mbuf data buffer? When queue model is gpi_qpl (this is negotiated and gotten using adminq wit= h backend), the device needs to register a block of memory (called page lis= t). And tx needs to copy the packets to this memory and rx will get packets= from this area. Backend will be responsible for getting(tx)/giving(rx) packets from this me= mory to the device/line (We don't really know how backend does this). Please refer to https://www.kernel.org/doc/html/v5.4/networking/device_driv= ers/google/gve.html. There's a bit more explanation about this queue format= . >=20 > Well, only qpl (queue page list) mode supported on the GCP env now. > So the DMA may not be used in current case. And yes, it's because GCP doesn't support GQI_RDA for now so GQI_QPL has to= be implemented. But even if GCP env supports RDA in the future, unless the= y completely remove QPL support, QPL is still needed. Because queue format/model is getting from backend through gve_adminq_descr= ibe_device(). You may just get the QPI version. The device can't really con= trol which queue format to get. >=20 > > > > > + } > > > + rxe->nb_segs =3D 1; > > > + rxe->next =3D NULL; > > > + rxe->pkt_len =3D len; > > > + rxe->data_len =3D len; > > > + rxe->port =3D rxq->port_id; > > > + rxe->packet_type =3D 0; > > > + rxe->ol_flags =3D 0; > > > + > > > > As far as I can see 'sw_ring[]' filled using 'rte_pktmbuf_alloc_bulk()' > > API, which should reset mbuf fields to default values, so some of the > > assignment above can be redundant. >=20 > Yes, some fields are already assigned at 'rte_pktmbuf_reset()'. > Will remove the redundant ones in the coming version. Thanks! >=20 > > > > > + if (rxd->flags_seq & GVE_RXF_TCP) > > > + rxe->packet_type |=3D RTE_PTYPE_L4_TCP; > > > + if (rxd->flags_seq & GVE_RXF_UDP) > > > + rxe->packet_type |=3D RTE_PTYPE_L4_UDP; > > > + if (rxd->flags_seq & GVE_RXF_IPV4) > > > + rxe->packet_type |=3D RTE_PTYPE_L3_IPV4; > > > + if (rxd->flags_seq & GVE_RXF_IPV6) > > > + rxe->packet_type |=3D RTE_PTYPE_L3_IPV6; > > > + > > > > If you are setting packet_type, it is better to implement > > 'dev_supported_ptypes_get()' dev_ops too, to announce host which > > packet type parsin supporting. (+ dev_ptypes_set() dev_ops) And later > > driver can announce "Packet type parsing" feature in .ini file. >=20 > Well, on current GCP env, the APIs for supported ptypes get/set have not > been exposed even in the base code. The only one in the base code is for > the dqo mode (gve_adminq_get_ptype_map_dqo). But this also cannot be > used on current GCP env. We can only implement this once they are > supported and exposed at GCP. Thanks! You're mixing the concept again. GCP env only supports QPL is not an excuse= . The packet type is supported even in QPL. It's just very limited to L4_TCP/= UDP and L3_IPV4/6. Ptypes_get is possible and it'll be RTE_PTYPE_L3_IPV4/6 = and RTE_PTYPE_L4_UDP/TCP. For DQO mode you mentioned, it'll be more flexible and have more support. I= 'm not sure what's your plan but it can be implemented whenever based on th= e plan not GCP env availability. The base code is there. It's just you may = not be able to timely verify and debug it. Ptype_set is not supported since the hardware doesn't support it (There's n= o such adminq).