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 21151A04AF; Mon, 4 May 2020 12:05:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 078221D501; Mon, 4 May 2020 12:05:21 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 129821D453 for ; Mon, 4 May 2020 12:05:19 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 044A0bOO006101; Mon, 4 May 2020 03:05:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : mime-version; s=pfpt0818; bh=EyUZ/iIZQ47uvhBMMKhOrb20R7iAM0p7Hrrmea0zoLw=; b=vLkKJ8TBPj+fuJW5qhoCJ9uYuEZg3F08m2qPWGbC9IAgZAkbmHCHnfjrZPIYA/ziLhIZ fpYhFZe0WtoonwsbvN/EoSM3Rwlwrvf5qoFFXWFE4uaXnic5+yExHIjpvhDQTDK4MwLj URb7j2juSL+ozje3uYKKkDCzrYU6sB9wFIpVdw3e6SpH20/UMx6X+Jzfa9x5IV3b92Ci Ywekjz1+ULzZUWTMipGFriGXWdD61WAQfzcCospFXU5/A/zxlaaB2Xgc8SiwxFUhNjHX SOJTLkM9f230yXG5bsTmgYlfHO1ZuQddKL+wLi9ka45twQsPHd1q3Z64cscCavTKTyPt oQ== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0b-0016f401.pphosted.com with ESMTP id 30srykk7mk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 04 May 2020 03:05:18 -0700 Received: from DC5-EXCH02.marvell.com (10.69.176.39) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 May 2020 03:05:16 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by DC5-EXCH02.marvell.com (10.69.176.39) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 May 2020 03:05:15 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.169) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 4 May 2020 03:05:15 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W9rbDgINGXQ7nPmH/1Wxay1wHXnS9nZyTBMkZV3lWM+6xcnlgUIMkqDbQn17D4//uYWcYAnzRSdlpgS6yR3bqnFddeNLzYhbL87dFokLfnK42SWjRSY0SFFavgvsDJ0uW/JbbYpqsP/tG/Jjz0gSFZAJmmWR0doM4He9/qjEWWx9ij1tfSQNpS8EMmGzK7nV+hP7sVS9qC49kDM9ToIQNMroEhq09HaRu8GfHjxFbJkAWBgnd/gi/8hfNqlTUDzbvgX5Ty3uIx2Ec5i78kskwyN1fPDA7MQaYEFAKZME0dfMjstAnkTB6nVylat5l6AoKOF69RAEVxNajPJTe8dz9w== 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=EyUZ/iIZQ47uvhBMMKhOrb20R7iAM0p7Hrrmea0zoLw=; b=CKPO1Sfn6APDtx6YleCRz3SYy3gC7Fzud5kfAogXu0Ew1DYS+H364NRQ7wOZKhRw9oLoCjmPgqnaOxq+H3q+A0Xe0y7+zuYGZuWsQx1q6puHij2uYeDEg1aamEU9ndoT3QIvzUQj59VyFYCsm1q2pKjHDlX3lWXhXA9YUG4sIvuStYqsMcWxGYj97mB2IpbBy1QbefGHKpvGhcvCCC2yhpbZunej6TLIAFKpQSSxJZtao1bIQ100SZO7ezPxbASEeBUKBPHGfxWqQiC1v9wgeZJ9dR0QWWq0EXOWk/a25C/jG0ejIKNf+I+Z6QBGOLV+W5jcmCj0s98wdUkcx8w50A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EyUZ/iIZQ47uvhBMMKhOrb20R7iAM0p7Hrrmea0zoLw=; b=ow6VIiA017bPQ3oQu4uTFTevzvqSUTHggrJU85A4Fc90g6U5dkstgYivfX/RO7BUICK2/t7u6CZ/0PmM5SduVmKOrZ3w2GGcD4iKe1oRta5NqOKIipW1e6mqxbQyQ5307OMf0ZpI5QzyZUdTJKWqvfaf1jFvieSCT2MUt23GChA= Authentication-Results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=marvell.com; Received: from BYAPR18MB2917.namprd18.prod.outlook.com (2603:10b6:a03:105::19) by BYAPR18MB2422.namprd18.prod.outlook.com (2603:10b6:a03:139::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.27; Mon, 4 May 2020 10:05:11 +0000 Received: from BYAPR18MB2917.namprd18.prod.outlook.com ([fe80::a1ec:e959:77df:cd58]) by BYAPR18MB2917.namprd18.prod.outlook.com ([fe80::a1ec:e959:77df:cd58%5]) with mapi id 15.20.2958.030; Mon, 4 May 2020 10:05:11 +0000 Date: Mon, 4 May 2020 15:34:57 +0530 From: Nithin Dabilpuram To: Olivier Matz CC: Jerin Jacob , Nithin Dabilpuram , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , "Ori Kam" , Cristian Dumitrescu , Anatoly Burakov , John McNamara , Marko Kovacevic , dpdk-dev , Jerin Jacob , Krzysztof Kanas Message-ID: <20200504100457.GB6153@outlook.office365.com> References: <20200417072254.11455-1-nithind1988@gmail.com> <20200504080634.GB6327@platinum> <20200504082706.GA6153@outlook.office365.com> <20200504091640.GC6327@platinum> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200504091640.GC6327@platinum> User-Agent: Mutt/1.12.2 (34cd43c) (2019-09-21) X-ClientProxiedBy: PN1PR0101CA0012.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c00:e::22) To BYAPR18MB2917.namprd18.prod.outlook.com (2603:10b6:a03:105::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from outlook.office365.com (115.113.156.2) by PN1PR0101CA0012.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c00:e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19 via Frontend Transport; Mon, 4 May 2020 10:05:06 +0000 X-Originating-IP: [115.113.156.2] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c607ed08-b0c5-427e-9355-08d7f012a19d X-MS-TrafficTypeDiagnostic: BYAPR18MB2422: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 03932714EB X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KwxEcaPqhwL14bsE0iJ2oNt+c0pPSMONQXUw5ZySJ6zgRz8fmVDsGwl+zcF5BrtEwZrUDTX2mpJq1gbVZCUhUOYvsPvuShejsPjGAjP9rRFa7th7rvO1q8jCXKnv07DScSg8BWe7lEjPwkSaExT6Y36Z8RpSfITqaXw0jvEwIHbK/ocnIrrvxBuN+YpgYUHG68mIr4ZncDN1Fiwb5NXyJaru16RGfpI8b8nGTiRX/HPvP6/3tNTCjImIazzSHXv8NoLAjCCMv7J2dqy4zMlyrFQI/ZnLsRqjEQChtDjNLoo/Idru4B4Av6wxedct63NnfPn2Xz2iaCER1RnxBEqglv8ZdnRrsHm41bVYXusTDjsZqJN1Tnl+x3QH3PGHCksdENRuw46iSsyT1ZrvUmMPqnpQFN5tHNZ9xe2lWPNyQr1qthOfYIxsqF7zwy5/lkX1fLDCgPzHy6buEeBPbCzZJA1IW9qJpValjwK647Vrm+pCS4/d7CRIiCzQiYx6VHyoFtLqiR5FF7rQoYs8kj0I1Q== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2917.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(6916009)(6666004)(30864003)(5660300002)(8936002)(7416002)(33656002)(4326008)(498600001)(8676002)(966005)(55016002)(1076003)(53546011)(6506007)(66946007)(956004)(55236004)(2906002)(86362001)(7696005)(52116002)(54906003)(9686003)(66476007)(26005)(107886003)(186003)(16526019)(66556008); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: gLuk8M8qwq94PMRnkeEoCi+sVfWt/p9rVaiH9RCqk6PD/9L4/27idiVxdVuPfVNVvcEJsXUz7jbK1gxPF6UTDbjZ8PMgUGLxh/gAWFj+kiXO5Kulz+LtpQQZ3DbuRPnAwk6oJeVDmPCG+8ZNVWbuzPrAueYJYzpzL5etGv7RQ0o3KJ9824O5JPJ2C5EJtdGCI1iSmhvdpisWhnYkwywrZiubl8/XpSsPTQX+LFxV+h0ZyfVOdzeBtupzOji2KCjARRWK8JR8jFbQkLS9VdgMsyDhSMa30hbcB4sCJEENH3tlXjVSgVfv7vFgIY4dadTM+OLpZekW+VwJtlmdIsZDE26T4IxuyAIkDaaVf1NI8V49NcN1k+v0lrULmPIJ5bpFLHpk5cvHlPnKiwpVRulzqMgonHA2KWdLXoOuSfv4qz1NuAjqr745cbwjgey2BtItrpVg+cKGXBO4I2KMRGM4IrWIpihjdmbNItb1a7lar3qmVhnRTDmjbxHxPUbE05wDlip8T68brsKZBIkqNPKPEp0Xs80/KIkk9i0gbXFkSd8ZPl7Wh8Wwp44FT1lreoj5SHyHdh9Oi6h/tFxULg0g85cSzNKzt4ODA5/u/qDt9B1YOUakQyOoDwvowgL6Y59tsyKH8XldEds4DpeuoCmjY4XzQVUDd+ULuMZgvpNypsVd/vexx6gYFO6d+RH6S9cJUuNOAFlTKQt1ZnuMAqWY5ELfNQQa3De7F08Io/i+B6a2mPayr1/Nqi8iddEIsd4DecWoDn8o+GdYCf+Dg/brDg1Kz2tSYWGys9UmpnTOYgA= X-MS-Exchange-CrossTenant-Network-Message-Id: c607ed08-b0c5-427e-9355-08d7f012a19d X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 May 2020 10:05:11.3647 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: HqbumZFbntU7iaN2K0ozoR/I1PR2Hlws1vrsGGt8liDB2wgG0rWf6i+58L+ubSQY/AFM6VZUjjfKZlP0///fzg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2422 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-05-04_05:2020-05-04, 2020-05-04 signatures=0 Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 1/3] mbuf: add Tx offloads for packet marking 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" On Mon, May 04, 2020 at 11:16:40AM +0200, Olivier Matz wrote: > On Mon, May 04, 2020 at 01:57:06PM +0530, Nithin Dabilpuram wrote: > > Hi Olivier, > > > > On Mon, May 04, 2020 at 10:06:34AM +0200, Olivier Matz wrote: > > > External Email > > > > > > ---------------------------------------------------------------------- > > > Hi, > > > > > > On Fri, May 01, 2020 at 04:48:21PM +0530, Jerin Jacob wrote: > > > > On Fri, Apr 17, 2020 at 12:53 PM Nithin Dabilpuram > > > > wrote: > > > > > > > > > > From: Nithin Dabilpuram > > > > > > > > > > Introduce PKT_TX_MARK_IP_DSCP, PKT_TX_MARK_IP_ECN > > > > > and PKT_TX_MARK_VLAN_DEI Tx offload flags to support > > > > > packet marking. > > > > > > > > > > When packet marking feature in Traffic manager is enabled, > > > > > application has to the use the three new flags to indicate > > > > > to PMD on whether packet marking needs to be enabled on the > > > > > specific mbuf or not. By setting the three flags, it is > > > > > assumed by PMD that application has already verified the > > > > > applicability of marking on that specific packet and > > > > > PMD need not perform further checks as per RFC. > > > > > > > > > > Signed-off-by: Krzysztof Kanas > > > > > Signed-off-by: Nithin Dabilpuram > > > > > > > > None of the ethdev TM driver implementations has supported packet > > > > marking support. > > > > rte_tm and rte_mbuf maintainers(Christian, Oliver), Could you review this patch? > > > > > > As you know, the number of mbuf flags is limited (only 18 bits are > > > remaining), so I think we should use them with care, i.e. for features > > > that are generic enough. > > > > I agree, but I believe this is one of the basic flags needed like other > > Tx checksum offload flags (like PKT_TX_IP_CKSUM, PKT_TX_IPV4, etc) which > > are needed to identify on which packets HW should/can apply packet marking. > > PKT_TX_IP_CKSUM tells the hardware to offload the checksum > calculation. This is pretty straightforward and there is no other > dependency than the offload feature advertised by the PMD. > > I'm sorry, I have not a lot of experience with rte_tm.h, so it's > difficult for me to have a global view of what is done for instance when > PKT_TX_MARK_VLAN_DEI is set, and what happens when it is not set. > > Can you confirm that my understanding below is correct? (or correct me > where I'm wrong) > > Before your patch: > - the application enables the port and traffic manager on it > - the application calls rte_tm_mark_vlan_dei() to select which traffic > class must be marked > - when a packet is transmitted, the traffic class is determined by the > hardware, and if the hardware recognizes a VLAN packet, the VLAN DEI > bit is set depending on traffic class > > The problem is for packets that cannot be recognized by the hardware, > correct? Yes. Octeontx2 HW always depends on application knowledge instead of walking through all the layers of packet data in Tx to identify what packet it is and where the l2, l3, l4 headers start for performance reasons. I believe there are other hardware too that have the same expectation and hence we have a need for PKT_TX_IPv4, PKT_TX_IPv6 kind of flags. Hence we want to make use of mbuf:tx_offload field and PKT_TX_* flags for identifying the packet and knowing what are its l2,l3,l4 offsets. > > So your patch is a way to force the hardware to recognize mark set the > VLAN DEI on packets that are not recognized as VLAN packets? > > How the is traffic class of the packet determined? Packet is coloured based on Single Rate[1] or Dual Rate[2] Shaping result and packet color determines traffic class. The exact behavior of packet color to traffic class mapping is mentioned in TM spec based on few other RFC's. [1] https://tools.ietf.org/html/rfc2697 [2] https://tools.ietf.org/html/rfc2698 > > > > > From what I understand, this feature is bound to octeontx2, so using a > > > mbuf dynamic flag would make more sense here. There are some examples in > > > dpdk repository, just grep for "dynflag". > > > > This is not octeontx2 specific flag but any "packet marking feature" enabled > > PMD would need these flags to identify on which packets marking needs to be > > done. This is the first PMD that supports packet marking feature and > > hence it was not exposed earlier. > > > > For example to mark VLAN DEI, PMD cannot always assume that there is preexisting > > VLAN header from Byte 12 as there is no gaurantee that ethernet header > > always starts at Byte 0 (Custom headers before ethernet hdr). > > > > > > > > Also, I think that the feature availability should be advertised through > > > an ethdev offload, so an application can know at initialization time > > > that these flags can be used. > > > > Feature availablity is already part of TM spec in rte_tm.h > > struct rte_tm_capabilities:mark_vlan_dei_supported > > struct rte_tm_capabilities:mark_ip_ecn_[sctp|tcp]_supported > > struct rte_tm_capabilities:mark_ip_dscp_supported > > Does this mean that any driver advertising this existing feature flag > has to support the new mbuf flags too? Shouldn't we have a specific > feature for it? Yes, I thought PMD's need to support both. I'm fine adding specific feature flag for the offload flags alone if you insist or if there are other PMD's which don't need the offload flags for packet marking. I was not able to find out about other PMD's as none of the existing PMD's support packet marking. > > Please also see few comments below. > > > > > > --- > > > > > doc/guides/nics/features.rst | 14 ++++++++++++++ > > > > > lib/librte_mbuf/rte_mbuf.c | 6 ++++++ > > > > > lib/librte_mbuf/rte_mbuf_core.h | 36 ++++++++++++++++++++++++++++++++++-- > > > > > 3 files changed, 54 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst > > > > > index edd21c4..bc978fb 100644 > > > > > --- a/doc/guides/nics/features.rst > > > > > +++ b/doc/guides/nics/features.rst > > > > > @@ -913,6 +913,20 @@ Supports to get Rx/Tx packet burst mode information. > > > > > * **[implements] eth_dev_ops**: ``rx_burst_mode_get``, ``tx_burst_mode_get``. > > > > > * **[related] API**: ``rte_eth_rx_burst_mode_get()``, ``rte_eth_tx_burst_mode_get()``. > > > > > > > > > > +.. _nic_features_traffic_manager_packet_marking_offload: > > > > > + > > > > > +Traffic Manager Packet marking offload > > > > > +-------------------------------------- > > > > > + > > > > > +Supports enabling a packet marking offload specific mbuf. > > > > > + > > > > > +* **[uses] mbuf**: ``mbuf.ol_flags:PKT_TX_MARK_IP_DSCP``, > > > > > + ``mbuf.ol_flags:PKT_TX_MARK_IP_ECN``, ``mbuf.ol_flags:PKT_TX_MARK_VLAN_DEI``, > > > > > + ``mbuf.ol_flags:PKT_TX_IPV4``, ``mbuf.ol_flags:PKT_TX_IPV6``. > > > > > +* **[uses] mbuf**: ``mbuf.l2_len``. > > > > > +* **[related] API**: ``rte_tm_mark_ip_dscp()``, ``rte_tm_mark_ip_ecn()``, > > > > > + ``rte_tm_mark_vlan_dei()``. > > > > > + > > > > > .. _nic_features_other: > > > > > > > > > > Other dev ops not represented by a Feature > > > > > diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c > > > > > index cd5794d..5c6896d 100644 > > > > > --- a/lib/librte_mbuf/rte_mbuf.c > > > > > +++ b/lib/librte_mbuf/rte_mbuf.c > > > > > @@ -880,6 +880,9 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask) > > > > > case PKT_TX_SEC_OFFLOAD: return "PKT_TX_SEC_OFFLOAD"; > > > > > case PKT_TX_UDP_SEG: return "PKT_TX_UDP_SEG"; > > > > > case PKT_TX_OUTER_UDP_CKSUM: return "PKT_TX_OUTER_UDP_CKSUM"; > > > > > + case PKT_TX_MARK_VLAN_DEI: return "PKT_TX_MARK_VLAN_DEI"; > > > > > + case PKT_TX_MARK_IP_DSCP: return "PKT_TX_MARK_IP_DSCP"; > > > > > + case PKT_TX_MARK_IP_ECN: return "PKT_TX_MARK_IP_ECN"; > > > > > default: return NULL; > > > > > } > > > > > } > > > > > @@ -916,6 +919,9 @@ rte_get_tx_ol_flag_list(uint64_t mask, char *buf, size_t buflen) > > > > > { PKT_TX_SEC_OFFLOAD, PKT_TX_SEC_OFFLOAD, NULL }, > > > > > { PKT_TX_UDP_SEG, PKT_TX_UDP_SEG, NULL }, > > > > > { PKT_TX_OUTER_UDP_CKSUM, PKT_TX_OUTER_UDP_CKSUM, NULL }, > > > > > + { PKT_TX_MARK_VLAN_DEI, PKT_TX_MARK_VLAN_DEI, NULL }, > > > > > + { PKT_TX_MARK_IP_DSCP, PKT_TX_MARK_IP_DSCP, NULL }, > > > > > + { PKT_TX_MARK_IP_ECN, PKT_TX_MARK_IP_ECN, NULL }, > > > > > }; > > > > > const char *name; > > > > > unsigned int i; > > > > > diff --git a/lib/librte_mbuf/rte_mbuf_core.h b/lib/librte_mbuf/rte_mbuf_core.h > > > > > index b9a59c8..d9f1290 100644 > > > > > --- a/lib/librte_mbuf/rte_mbuf_core.h > > > > > +++ b/lib/librte_mbuf/rte_mbuf_core.h > > > > > @@ -187,11 +187,40 @@ extern "C" { > > > > > /* add new RX flags here, don't forget to update PKT_FIRST_FREE */ > > > > > > > > > > #define PKT_FIRST_FREE (1ULL << 23) > > > > > -#define PKT_LAST_FREE (1ULL << 40) > > > > > +#define PKT_LAST_FREE (1ULL << 37) > > > > > > > > > > /* add new TX flags here, don't forget to update PKT_LAST_FREE */ > > > > > > > > > > /** > > > > > + * Packet marking offload flags. These flags indicated what kind > > > > > + * of packet marking needs to be applied on a given mbuf when > > > > > + * appropriate Traffic Manager configuration is in place. > > > > > + * When user set's these flags on a mbuf, below assumptions are made > > > > > + * 1) When PKT_TX_MARK_VLAN_DEI is set, > > > > > + * a) PMD assumes pkt to be a 802.1q packet. > > What does that imply? I meant by setting the flag, a packet has VLAN header adhering to IEEE 802.1Q spec. > > > > > > + * b) Application should also set mbuf.l2_len where 802.1Q header is > > > > > + * at (mbuf.l2_len - 6) offset. > > Why mbuf.l2_len - 6 ? L2 header when VLAN header is preset will be {custom header 'X' Bytes}:{Ethernet SRC+DST (12B)}:{VLAN Header (4B)}:{Ether Type (2B)} l2_len = X + 12 + 4 + 2 So, VLAN header starts at (l2_len - 6) bytes. > > > > > > + * 2) When PKT_TX_MARK_IP_DSCP is set, > > > > > + * a) Application should also set either PKT_TX_IPV4 or PKT_TX_IPV6 > > > > > + * to indicate whether if it is IPv4 packet or IPv6 packet > > > > > + * for DSCP marking. It should also set PKT_TX_IP_CKSUM if it is > > > > > + * IPv4 pkt. > > > > > + * b) Application should also set mbuf.l2_len that indicates > > > > > + * start offset of L3 header. > > > > > + * 3) When PKT_TX_MARK_IP_ECN is set, > > > > > + * a) Application should also set either PKT_TX_IPV4 or PKT_TX_IPV6. > > > > > + * It should also set PKT_TX_IP_CKSUM if it is IPv4 pkt. > > > > > + * b) PMD will assume pkt L4 protocol is either TCP or SCTP and > > > > > + * ECN is set to 2'b01 or 2'b10 as per RFC 3168 and hence HW > > > > > + * can mark the packet for a configured color. > > > > > + * c) Application should also set mbuf.l2_len that indicates > > > > > + * start offset of L3 header. > > > > > + */ > > > > > +#define PKT_TX_MARK_VLAN_DEI (1ULL << 38) > > > > > +#define PKT_TX_MARK_IP_DSCP (1ULL << 39) > > > > > +#define PKT_TX_MARK_IP_ECN (1ULL << 40) > > We should have one comment per define. Ack, will fix in V2. > > > > > > > + > > > > > +/** > > > > > * Outer UDP checksum offload flag. This flag is used for enabling > > > > > * outer UDP checksum in PMD. To use outer UDP checksum, the user needs to > > > > > * 1) Enable the following in mbuf, > > > > > @@ -384,7 +413,10 @@ extern "C" { > > > > > PKT_TX_MACSEC | \ > > > > > PKT_TX_SEC_OFFLOAD | \ > > > > > PKT_TX_UDP_SEG | \ > > > > > - PKT_TX_OUTER_UDP_CKSUM) > > > > > + PKT_TX_OUTER_UDP_CKSUM | \ > > > > > + PKT_TX_MARK_VLAN_DEI | \ > > > > > + PKT_TX_MARK_IP_DSCP | \ > > > > > + PKT_TX_MARK_IP_ECN) > > > > > > > > > > /** > > > > > * Mbuf having an external buffer attached. shinfo in mbuf must be filled. > > > > > -- > > > > > 2.8.4 > > > > >