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 A2259A0562 for ; Tue, 31 Mar 2020 11:05:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 798DD1C02D; Tue, 31 Mar 2020 11:05:54 +0200 (CEST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2061.outbound.protection.outlook.com [40.107.20.61]) by dpdk.org (Postfix) with ESMTP id EB4D32C6D; Tue, 31 Mar 2020 11:05:50 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MHqo3q7GQ6wMTXSFiO1bqPcYDY6Cu0y6CMSdm1VYqv4eM4enyQx8fqFhEuNl2Lj5vI2SBfZhbiznbiB6U5/rLTztqe0B2gzEbwaW4r20IQMm4zXItuCRLhIWf7f3MGfKONZr7QkiqVaz7aZrmLpedXPi6PyjlzJMWPU+wwnb1qop4lUZ0ZpGQP8bBcyAZhW8HTuAPYi0Nky/m7O4JBtaHi0RNflBaWhpVPo4fRIkyXBTc/jTuxJID7P9zt+u3SrGZPNYEVIbQ+HTZe1WxwhaWCHRjkDktzY0RXvMDiL0HZGxUbdZYVI60eKkcDzzJ9EReGJHzlr1KTcSUfgBx8c2Gg== 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=bBlpQQ/9oBQoI8/+K+AvS4fjp+EmgvK7NTKR1Dmlm+c=; b=dBZJVfgdPWXPWYMJyytzojrgy/wqVMpIo/4SSvBEBOGS+LERqFi0y618THTB7sJNLYTeQXn7HYfecuLLB3dxBvhhWe1LCOZRRv9v0xJF0gD9nr2eUx+Jf3V8RWCoKKiA4ZA1t06mSNcfXQXvSbI9qi3HdpWdVNdRrNNiUMsfQZqhL5Rzbo5XyaKY66P/UYUYQy5yb/yEgEtA9W6wg2KNvT/WKeFfgfmzd7650Lya0lczfDGPPIJPTAEkvgNgGd3/jBmuf/FPMwy/YQIBaXtfv6cp08K/T589FJjGXEiAB7rGVFaG7EVsx85Pkgj95NBDUL4M7tN6BdH6ENFVnmGtnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bBlpQQ/9oBQoI8/+K+AvS4fjp+EmgvK7NTKR1Dmlm+c=; b=aJosT7ysion1eKS/RDnAlstVF9p9u/Il8QbF0mdA0bGrdrW8AQJlatECaOgkZWS5DTffSRacy8JcXEc6I7hhJR1JyyJ+xpY89CFgtjlAhvJfgSn+D4KgBaz+xKUaY1ef05KKysaX9QUOSYyf0jnVplLcCwgcIWzG2UzTOCn/0kw= Received: from AM6PR05MB5176.eurprd05.prod.outlook.com (20.177.196.158) by AM6PR05MB6039.eurprd05.prod.outlook.com (20.179.2.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Tue, 31 Mar 2020 09:05:48 +0000 Received: from AM6PR05MB5176.eurprd05.prod.outlook.com ([fe80::f5cd:b10f:5f1b:4b22]) by AM6PR05MB5176.eurprd05.prod.outlook.com ([fe80::f5cd:b10f:5f1b:4b22%7]) with mapi id 15.20.2856.019; Tue, 31 Mar 2020 09:05:48 +0000 From: Ori Kam To: "Zhang, Xiao" , "Zhao1, Wei" , "dev@dpdk.org" CC: "Wang, Ying A" , "Zhang, Qi Z" , "stable@dpdk.org" Thread-Topic: app/testpmd: fix PPPOES flow API Thread-Index: AQHWBBGaeM8mPPPhN06u+6qAGH787KhfHGRwgAAuDYCAABH+kIAAHq0AgAALNhCAAOHZAIAAW3SAgAAUf4CAAABTEIAAXMIAgAEOjQCAABy8gIAABJzA Date: Tue, 31 Mar 2020 09:05:48 +0000 Message-ID: References: <20200327081926.6154-1-xiao.zhang@intel.com> <2966f158164c411e897b3ab741787eea@intel.com> <2723defc86e04f0aaeb42a14183b4b5f@intel.com> <17e9c85bd1ee4ce190fbd4d1be26105e@intel.com> <704bf77207994d6182d5c4df625004e9@intel.com> <99365860d10049a6ad751b1a286933ac@intel.com> In-Reply-To: <99365860d10049a6ad751b1a286933ac@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=orika@mellanox.com; x-originating-ip: [185.175.35.255] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 72b6f140-23fe-42d4-2682-08d7d552b494 x-ms-traffictypediagnostic: AM6PR05MB6039: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR05MB5176.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(346002)(396003)(376002)(136003)(39860400002)(7696005)(66476007)(66556008)(64756008)(66446008)(66946007)(30864003)(76116006)(5660300002)(6506007)(86362001)(52536014)(478600001)(2906002)(81166006)(9686003)(8676002)(33656002)(26005)(81156014)(54906003)(186003)(45080400002)(55016002)(4326008)(71200400001)(110136005)(966005)(8936002)(316002)(21314003); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jlllCZnw7aSoJaxvp+Ih3ZRV3wiZoh8iXQ1mfLeGMuYvRKyfnI05QONytpqMq8by5f94VevzP2wZHiDWoAOlPXS58mhYHNCDdVc/ht6cQjWolVpJdgGVhfjrg1YVfGHBUTT7B/fPbLaM1g3IkNHRc1JKDlxRAwY8fiENV4OVUQgrqXwv5POQR4DF1KGNIAqrU8WXwnWjZd3EMC39B8mbMS5BzOF8fPNaIpYEGQ0vT1/i5/q1TF93XiDOno+zwNs/ERnvPxTNaYaFtgJP4Aeur+hP/ssc4Mc6au7xaYfq0fZCPCbDL6XmeLJl/qT90w13U53gC4rj6E1wNmqD3EntbloWDCLKdagEQ/Hz0yMEJ8wQHtpQuospY92mknODwTqpPDDMi4QvmR9iHQeQT7Wf2gbHDcOT/fytfhq5Ee1aJonHqX4ddOlOV8B7K/jhocp0zVYS904+8MAJyWMMHx+rsH3iTUFX6zjhwM82TWYQu76wgy7fYZA8ydP2fW6IxnQfYG87FdXR42wwsTr9KHltGQ== x-ms-exchange-antispam-messagedata: +8Q69AZXpz3YIBZCJKUWwsMdjzMD3PqWOQEoETwmsIAxYJXI4fTAHAo7c6DUhKfwcKlBOv0IxHmEhrzfM0TzKPQd9nBMzx4AKvotk/l0F5EJu4Je2uMpcWqe3Uv1OUcqV8gTW3Gh/X8G0skw/9OdkA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 72b6f140-23fe-42d4-2682-08d7d552b494 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2020 09:05:48.8378 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: o+Z0m3lp4iOXwRfHObu3j6pQptvgmN3AUC2T3ROC1lZVJW121VPfLHx0TfImww857qy4I6TcelAKkMXJ6TIJmw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR05MB6039 Subject: Re: [dpdk-stable] app/testpmd: fix PPPOES flow API X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" > -----Original Message----- > From: Zhang, Xiao > Subject: RE: app/testpmd: fix PPPOES flow API >=20 >=20 >=20 > > -----Original Message----- > > From: Ori Kam > > Subject: RE: app/testpmd: fix PPPOES flow API > > > > > > > > > -----Original Message----- > > > From: Zhang, Xiao > > > > > > Hi Ori, > > > > > > > -----Original Message----- > > > > From: Ori Kam > > > > > > > > Hi Xiao, > > > > > > > > > -----Original Message----- > > > > > From: Zhao1, Wei > > > > > > > > > > Hi, Ori > > > > > > > > > > > -----Original Message----- > > > > > > From: Ori Kam > > > > > > > > > > > > Hi Xiao > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Zhang, Xiao > > > > > > > > > > > > > > Hi Ori, > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Ori Kam > > > > > > > > > > > > > > > > Hi Xiao, > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Zhang, Xiao > > > > > > > > > > > > > > > > > > Hi Ori, > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Ori Kam > > > > > > > > > > > > > > > > > > > > Hi Xiao, > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Zhang, Xiao > > > > > > > > > > > Sent: Sunday, March 29, 2020 12:06 PM > > > > > > > > > > > To: Ori Kam ; dev@dpdk.org > > > > > > > > > > > Cc: Wang, Ying A ; Zhang, Qi Z > > > > > > > > > > > ; Zhao1, Wei > > > > > > > > > > > ; stable@dpdk.org > > > > > > > > > > > Subject: RE: app/testpmd: fix PPPOES flow API > > > > > > > > > > > > > > > > > > > > > > Hi Ori, > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Ori Kam > > > > > > > > > > > > > > > > > > > > > > > > Hi Xiao, > > > > > > > > > > > > > > > > > > > > > > > > Is the proto_id part of the basic header or not? > > > > > > > > > > > > > > > > > > > > > > Proto_id is part of PPPOE session header, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Where is the porto_id located? Inside the payload? > > > > > > > > > > > > > > > > > > Yes, my previous explanation was not clear. The protocol > > > > > > > > > ID is in the beginning of the payload in PPP Session Stag= e > > > > > > > > > according to > > > > RFC2516. > > > > > > > > > > > > > > > > > > 1 > > > > > > 2 3 > > > > > > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > > > > > > > > > 4 5 > > > > > > > > > 6 7 > > > > > > > > > 8 9 > > > > > > > > > 0 1 > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= - > > > > > > > > > +-+-+- > > > + > > > > > > > > > | VER | TYPE | CODE | > > > > > > SESSION_ID | > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+- > + > > > > > > > > > | LENGTH | > > > > > > payload ~ > > > > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + > > > > > > > > > > > > > > > > > > > > > > > > > Yes this is what I thought, does proto_id must be the first > > > > > > > > part of the > > > > > > payload? > > > > > > > > > > > > > > It must be the first part of the payload for PPP Session > > > > > > > Stage, not all PPPOE packets. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From the spec it looks like a different header. > > > > > > > > > > > > > > > > > > > > > > > > If it is part of the original header then all > > > > > > > > > > > > documentations and rte_structs > > > > > > > > > > > should > > > > > > > > > > > > be changed, to reflect this. > > > > > > > > > > > > > > > > > > > > > > > > It will be very helpful if the patch message would > > > > > > > > > > > > explain the bug and why it > > > > > > > > > > > was > > > > > > > > > > > > changed. > > > > > > > > > > > > > > > > > > > > > > Okay, will add more message. The next value of the > > > > > > > > > ITEM_PPPOE_PROTO_ID > > > > > > > > > > > should be unsigned value but not item list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also please see inline other comment. > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > Ori > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: Xiao Zhang > > > > > > > > > > > > > Sent: Friday, March 27, 2020 11:19 AM > > > > > > > > > > > > > To: dev@dpdk.org > > > > > > > > > > > > > Cc: Ori Kam ; > > > > > > > > > > > > > ying.a.wang@intel.com; qi.z.zhang@intel.com; > > > > > > > > > > > > > wei.zhao1@intel.com; Xiao Zhang > > > > > > > > > > > > > ; stable@dpdk.org > > > > > > > > > > > > > Subject: app/testpmd: fix PPPOES flow API > > > > > > > > > > > > > > > > > > > > > > > > > > The command line to create RTE flow for specific > > > > > > > > > > > > > proto_id of PPPOES is not correct. This patch is > > > > > > > > > > > > > to fix this > > > issue. > > > > > > > > > > > > > > > > > > > > > > > > > > Fixes: 226c6e60c35b ("ethdev: add PPPoE to flow > > > > > > > > > > > > > API") > > > > > > > > > > > > > Cc: stable@dpdk.org > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Xiao Zhang > > > > > > > > > > > > > --- > > > > > > > > > > > > > app/test-pmd/cmdline_flow.c | 13 +++---------- > > > > > > > > > > > > > 1 file changed, 3 insertions(+), 10 deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/app/test-pmd/cmdline_flow.c > > > > > > > > > > > > > b/app/test-pmd/cmdline_flow.c index > > > > > > > > > > > > > a78154502..c25a2598d > > > > > > > > > > > > > 100644 > > > > > > > > > > > > > --- a/app/test-pmd/cmdline_flow.c > > > > > > > > > > > > > +++ b/app/test-pmd/cmdline_flow.c > > > > > > > > > > > > > @@ -768,7 +768,6 @@ static const enum index > > > > > > > > > > > > > next_item[] > > > =3D { > > > > > > > > > > > > > ITEM_GTP_PSC, > > > > > > > > > > > > > ITEM_PPPOES, > > > > > > > > > > > > > ITEM_PPPOED, > > > > > > > > > > > > > - ITEM_PPPOE_PROTO_ID, > > > > > > > > > > > > > ITEM_HIGIG2, > > > > > > > > > > > > > ITEM_TAG, > > > > > > > > > > > > > ITEM_L2TPV3OIP, > > > > > > > > > > > > > @@ -1030,11 +1029,6 @@ static const enum index > > > > > > > > > > > > > item_pppoed[] =3D { > > > > > > > > > > > > > > > > > > > > > > > > > > static const enum index item_pppoes[] =3D { > > > > > > > > > > > > > ITEM_PPPOE_SEID, > > > > > > > > > > > > > - ITEM_NEXT, > > > > > > > > > > > > > - ZERO, > > > > > > > > > > > > > -}; > > > > > > > > > > > > > - > > > > > > > > > > > > > -static const enum index item_pppoe_proto_id[] = =3D { > > > > > > > > > > > > > ITEM_PPPOE_PROTO_ID, > > > > > > > > > > > > > ITEM_NEXT, > > > > > > > > > > > > > ZERO, > > > > > > > > > > > > > @@ -2643,10 +2637,9 @@ static const struct token > > > > > > > > > > > > > token_list[] > > > > > =3D > > > > > > { > > > > > > > > > > > > > [ITEM_PPPOE_PROTO_ID] =3D { > > > > > > > > > > > > > .name =3D "proto_id", > > > > > > > > > > > > > .help =3D "match PPPoE session protocol > > > > identifier", > > > > > > > > > > > > > - .priv =3D PRIV_ITEM(PPPOE_PROTO_ID, > > > > > > > > > > > > > - sizeof(struct > > > > > > > > > rte_flow_item_pppoe_proto_id)), > > > > > > > > > > > > > - .next =3D NEXT(item_pppoe_proto_id), > > > > > > > > > > > > > - .call =3D parse_vc, > > > > > > > > > > > > > + .next =3D NEXT(item_pppoes, > > > > NEXT_ENTRY(UNSIGNED), > > > > > > > > > > > > > item_param), > > > > > > > > > > > > > + .args =3D ARGS(ARGS_ENTRY_HTON > > > > > > > > > > > > > + (struct > > > > rte_flow_item_pppoe_proto_id, > > > > > > > > > proto_id)), > > > > > > > > > > > > > > > > > > > > > > > > Where is the memory for this proto_id is defined? > > > > > > > > > > > > > > > > > > > > > > Do you mean this? > > > > > > > > > > > lib/librte_ethdev/rte_flow.h > > > > > > > > > > > 1360 struct rte_flow_item_pppoe_proto_id { > > > > > > > > > > > 1361 rte_be16_t proto_id; /**< PPP protocol i= dentifier. > */ > > > > > > > > > > > 1362 }; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes. Why don't you use this one? > > > > > > > > > > > > > > > > > > I think I was using this, am I using it incorrectly? > > > > > > > > > > > > > > > > > > + .args =3D ARGS(ARGS_ENTRY_HTON > > > > > > > > > + (struct rte_flow_item_pppoe_proto_id, > > > > > proto_id)), > > > > > > > > > > > > > > > > > > > > > > > > > Yes but there is no space to save this data since you delet= ed the > priv. > > > > > > > > I think you are trying to implement something like > > > > > > > > RTE_FLOW_ITEM_TYPE_IPV6_EXT. > > > > > > > > > > > > > > > > And I don't understand what was the problem with the > > > > > > > > previous > > > > > > > implementation. > > > > > > > > > > > > > > I deleted the priv because it changed to a subcommand in > > > > > > > pppoes, the command line will be like this: > > > > > > > testpmd> flow create 0 ingress pattern eth dst is > > > > > > > testpmd> 00:11:22:33:44:55 / pppoes > > > > > > > proto_id is 21 > > > > > > > > > > > > > > > > > > > The issue is that the pppoe struct doesn't have definition to t= he > proto_id. > > > > > > If you wish a possible solution will be to add it to the pppoe > > > > > > struct, I'm not > > > > > sure > > > > > > if this is the correct approach since this field is not a must. > > > > > > > > > > > > Like I said there are examples on how to work with extended > > > > > > headers, which I think are more correct, buy may be the problem > > > > > > is that the pppoe struct is > > > > > not > > > > > > aligned and this result in an issue when adding the last bytes. > > > > > > > > > > > > > > > There is a defination of RTE_FLOW_ITEM_TYPE_PPPOE_PROTO_ID, do > you > > > > > mean make use of that? > > > > > That is the reason for use extended header for this? > > > > > But that seems as you say, has some bug. > > > > > > > > > > > > > I understand there is a bug, the question how to solve it. > > > > I suggested two approaches. Add the proto_id to the pppoe struct, > > > > but this means that we will add a new member that is not part of th= e > > > > original > > > definition. > > > > Maybe the issue is in the PMD and it needs to understand that the > > > > proto_id should be located in a different offset. > > > > In any case it doesn't look like the current fix the right one. > > > > > > From my understanding, you mean there are two approaches. One is > > > adding proto_id to pppoe struct. But you don't prefer this one since > > > proto_id is not a must. I am not clear about the other one. > > > > > > > The solution should be just like the pdu_type which is part of the gtp_= psc. > > You can find also my comments on this, in the ML. > > I think it is exactly the same case. > > Example line for pdu type: flow create 0 ingress pattern gtp_psc pdu_t = is xxx > The > > thread > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fpatch= es.d > pdk.org%2Fpatch%2F67198%2F&data=3D02%7C01%7Corika%40mellanox.co > m%7Cb393253da4f84b2e909908d7d54b817b%7Ca652971c7d2e4d9ba6a4d149 > 256f461b%7C0%7C0%7C637212392573440621&sdata=3DQBGaw8RypOoikbb > veKhbgv4PxZbOJ7p7pNESV6D%2FBT0%3D&reserved=3D0 >=20 > Yes, so the line for should be: > flow create 0 ingress pattern pppoes proto_id is xxx . >=20 > But since we already have pppoes line for command pppoes seid is xxx, we > need use another word instead of pppoes for proto_id, right? If yes, do y= ou > have any suggestion? >=20 I think it should be something like this: Flow create 0 ingress pattern pppoe_proto_id proto_id is xxx Since the pppoe_proto_id has only one field maybe we can go with the follow= ing approach: Flow create 0 ingress pattern pppoe_proto_id is xxx > > > > > > > And also how do you suggest the command line be for proto_id? > > > "proto_id is 0x0021" or "pppoes proto_id is 0x0021"? If the former > > > just like what it was, I think it maybe a little confused. If the > > > latter (as proto_id is part of pppoes), do we still need to put proto= _id in > > rte_flow_item_pppoe? > > > > > > Thanks, > > > Xiao > > > > > > > > > > > > > > > > > > > > > > > > > The previous implementation would be infinite loop for > > > > > > > proto_id command and can not specific the value for proto_id. > > > > > > > testpmd> flow create 0 ingress pattern eth dst is > > > > > > > testpmd> 00:11:22:33:44:55 / proto_id > > > > > > > proto_id [TOKEN]: match PPPoE session protocol identifier / > [TOKEN]: > > > > > > > specify next pattern item > > > > > > > testpmd> flow create 0 ingress pattern eth dst is > > > > > > > testpmd> 00:11:22:33:44:55 / proto_id > > > > > > > proto_id > > > > > > > proto_id [TOKEN]: match PPPoE session protocol identifier / > [TOKEN]: > > > > > > > specify next pattern item > > > > > > > testpmd> flow create 0 ingress pattern eth dst is > > > > > > > testpmd> 00:11:22:33:44:55 / proto_id > > > > > > > proto_id proto_id > > > > > > > proto_id [TOKEN]: match PPPoE session protocol identifier / > [TOKEN]: > > > > > > > specify next pattern item > > > > > > > testpmd> flow create 0 ingress pattern eth dst is > > > > > > > testpmd> 00:11:22:33:44:55 / proto_id > > > > > > > proto_id proto_id > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > }, > > > > > > > > > > > > > [ITEM_HIGIG2] =3D { > > > > > > > > > > > > > .name =3D "higig2", > > > > > > > > > > > > > -- > > > > > > > > > > > > > 2.17.1