From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 393DE160 for ; Sun, 14 Oct 2018 09:35:52 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id C064B40005C; Sun, 14 Oct 2018 07:35:50 +0000 (UTC) Received: from [192.168.1.192] (188.242.181.57) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 14 Oct 2018 00:35:40 -0700 To: Jack Min , Adrien Mazarguil , John McNamara , "Marko Kovacevic" , Thomas Monjalon , Ferruh Yigit CC: "dev@dpdk.org" References: <20181011132641.1000-1-jackmin@mellanox.com> <20181013032348.26380-1-jackmin@mellanox.com> <20181013032348.26380-2-jackmin@mellanox.com> From: Andrew Rybchenko Message-ID: Date: Sun, 14 Oct 2018 10:35:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181013032348.26380-2-jackmin@mellanox.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [188.242.181.57] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ocex03.SolarFlarecom.com (10.20.40.36) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24152.005 X-TM-AS-Result: No-7.199000-4.000000-10 X-TMASE-MatchedRID: vEvJ7Rh1lGh6DVqDv3PkvSa1MaKuob8Pt3aeg7g/usDfc2Xd6VJ+yssM 7AnHhwCPq0j6/BL6F+53aWU5jdY62EmlG3KNrFcFFyqkfsPWu1AflbDua3yEDsLFbEAzpZqnoNI Vs1K85yeDWfNv+ApTBEQJ+oqduk9rYOQAOJ+OS211fPeXvwXdiTiAbW+oEE34SnWuwqfQPkb6hy ODqRDK2VY5pMpW3EXR1CglkkPN8i92Tfe2Aes63UKcYi5Qw/RVmX+W7bzPOQEFZUFNc+OC7QUzj +gqhStRgKBawol2greUXobAVGL7/NSq6q0CYrH3MgcjIsJOvt7j5lyuq8IOQU8JUNCT267v4a8t jcE0lxy4Kr5OftAPfyQlTOA/gNlWWjobr6A1qESeAiCmPx4NwLTrdaH1ZWqC1B0Hk1Q1KyLUZxE AlFPo846HM5rqDwqtwoGdtv27IpuCO2zN1IMAXoVEJznxOYQgGCfwNw7DDDAWLYYB57t4PLhqLS OsMxt35crDteyIhol9/Ly/6m/XiegJPvrzz4+c4vn0zMfSmjYrbLOj1GuP3A+hgLflG6KEo9Qju F9BKnl4IFxQIbVomJRMZUCEHkRt X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--7.199000-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24152.005 X-MDID: 1539502551-eM-FkrRYL7CN Subject: Re: [dpdk-dev] [PATCH v5 1/3] ethdev: add generic TTL rewrite actions 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: , X-List-Received-Date: Sun, 14 Oct 2018 07:35:52 -0000 On 13.10.2018 06:24, Jack Min wrote: > rewrite TTL by decrease or just set it directly > it's not necessary to check if the final result > is zero or not > > This is slightly different from the one defined > by openflow and more generic > > Signed-off-by: Xiaoyu Min > Acked-by: Yongseok Koh > --- [...] > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h > index 68bbf57d0..f102e6939 100644 > --- a/lib/librte_ethdev/rte_flow.h > +++ b/lib/librte_ethdev/rte_flow.h > @@ -1579,6 +1579,26 @@ enum rte_flow_action_type { > * No associated configuration structure. > */ > RTE_FLOW_ACTION_TYPE_MAC_SWAP, > + > + /** > + * Decrease TTL value directly > + * > + * If flow pattern doesn't define a valid RTE_FLOW_ITEM_TYPE_IPV4, or > + * RTE_FLOW_ITEM_TYPE_IPV6, the PMD should return a > + * RTE_FLOW_ERROR_TYPE_ACTION error. > + */ > + RTE_FLOW_ACTION_TYPE_DEC_TTL, > + > + /** > + * Set TTL value > + * > + * If flow pattern doesn't define a valid RTE_FLOW_ITEM_TYPE_IPV4, or > + * RTE_FLOW_ITEM_TYPE_IPV6, the PMD should return a > + * RTE_FLOW_ERROR_TYPE_ACTION error. > + * > + * See struct rte_flow_action_set_ttl > + */ > + RTE_FLOW_ACTION_TYPE_SET_TTL, > }; > > /** As I understand it is one more case where the following note from Adrien is applicable [1]: Another problem is that you must not require actions to rely on specific pattern content: [...] * * Decapsulate outer most tunnel from matched flow. * * The flow pattern must have a valid tunnel header */ RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP, For maximum flexibility, all actions should be usable on their own on empty pattern. On the other hand, you can document undefined behavior when performing some action on traffic that doesn't contain something. Reason is that invalid traffic may have already been removed by other flow rules (or whatever happens) before such a rule is reached; it's a user's responsibility to provide such guarantee. When parsing an action, a PMD is not supposed to look at the pattern. Action list should contain all the needed info, otherwise it means the API is badly defined. I'm aware the above makes it tough to implement something like RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP as defined in this series, but that's unfortunately why I think it must not be defined like that. [1] https://mails.dpdk.org/archives/dev/2018-October/115267.html