From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id C3EFE2BD8 for ; Mon, 8 Apr 2019 16:21:21 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id w10so16659585wrm.4 for ; Mon, 08 Apr 2019 07:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=s8KWKqv5cBSg/RPb6JayiWB4adwOSJDFB50jYJP6U+E=; b=bAJkwtFTtqhepo/jhj74n+gUTKFazHB6S63OQzRixiCZf1E34iSxZ+XCxijlP2C1ct 4eAT7df9tTgHPFE6itmbqZhRX7HZhiR47lvvAdW7toPru0IvLG+6D5pB/zNEh1kxfYDj zgX25XWRNkfWhjrdB9Lf05SYFkSiLdnjoWozqwWAu1qxXES6OK4m9e1dsblwVlCQXvf8 ltj9HjErRgA1JEMflbqLoAS4+dUS+Ay6Aym/mjbJMmolhXQykZxTsE0ssZ93J4Pwa8fH Cw+3YnaRNtVOhLY0OolJvXaYHM4nv3VoKM2I6L+M5hk5uKZSp3k1OXu2CQMmpbkLlhav ZApA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=s8KWKqv5cBSg/RPb6JayiWB4adwOSJDFB50jYJP6U+E=; b=tpXQxdH+I1gnYfauPp+K6EEPwHdp/W+BmsRQ/aBdIovoyYK5+p9OglxkXa1QxjLYI+ MGAhrtePhcL4WV9iubwX9G49qCX5Uq+g3sX7+2fODSuGLiT9wzhLYNrASlge7rcesD0W haCc8ZCg72utJ68lX8O1BVcX4OlbG+Yu2Q4OyXL9McpvEGltiWK8BvAyjO5RIZ2+U0y8 F6R0saXa8rAqPklSy+m2PF0zg8S/6Uz3Yjma0PCDctW3TLXQx20NBjB8utZx4Nm2SBqp POm/ueURC2NcY4Ex81HxCetZh6bIy9GO1ZSvQ5gYRbqebKeepePWrF9p+3HwOmRLIAFF YGlQ== X-Gm-Message-State: APjAAAVBJPISq/zaZ6L4nSdvNfMmT22BkWMJ1TFgh8By75FxNBYZ+yaV GLKLJcL/7qDN9G+NWl1A7e5jRA== X-Google-Smtp-Source: APXvYqzX6j/dWrVXjnuxRfGtVWgBCJE0RzCr3mzBYXDs/dzc2OhDnzYN1iV66ndB1DoBFrdyx6Mfyg== X-Received: by 2002:adf:ee91:: with SMTP id b17mr17637315wro.234.1554733281550; Mon, 08 Apr 2019 07:21:21 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 7sm103027829wrc.81.2019.04.08.07.21.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 07:21:20 -0700 (PDT) Date: Mon, 8 Apr 2019 16:21:18 +0200 From: Adrien Mazarguil To: Andrew Rybchenko Cc: Dekel Peled , Ori Kam , "wenzhuo.lu@intel.com" , "jingjing.wu@intel.com" , "bernard.iremonger@intel.com" , Yongseok Koh , Shahaf Shuler , "dev@dpdk.org" Message-ID: <20190408142118.GW4889@6wind.com> References: <1553177917-43297-1-git-send-email-dekelp@mellanox.com> <1554218001-62012-2-git-send-email-dekelp@mellanox.com> <20190403091432.GP4889@6wind.com> <20190403124921.GR4889@6wind.com> <20190404132556.GS4889@6wind.com> <66c690e9-8261-78b9-3287-50b444869bb5@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66c690e9-8261-78b9-3287-50b444869bb5@solarflare.com> Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: add actions to modify TCP header fields 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: Mon, 08 Apr 2019 14:21:21 -0000 Hi Andrew, *Dekel* (I swear I'm not doing it on purpose, hopefully I won't make that stupid mistake again :) On Mon, Apr 08, 2019 at 04:53:54PM +0300, Andrew Rybchenko wrote: > On 4/8/19 4:36 PM, Dekel Peled wrote: > > Regarding Andrew's suggestion: "Shouldn't these action be RTE_FLOW_ACTION_TYPE_MOD_TCP_{ACK,SEQ} with singed 32-bit integer parameter (negative to decrement, positive to increment)?" > > I will leave the actions as is, the action names indicate the operation they perform. > > I think it is an overkill to have two actions for the purpose: DEC (value) > == INC ((uint32_t)-value) > If it is really important to have DEC and INC, please, make it clear from > actions documentation why. The main reason in my opinion is that a signed value may not be able to represent an increment large enough for an unsigned value of the same bit width. This can be worked around by using a type larger than the underlying data field (e.g. i64 for u32), but it will look confusing and is not an option for the largest unsigned type we support (u64). Another problem is what endian increment/decrement actions should use. There are no dedicated endian types for signed values at the moment, and I'm not sure we should define any. This could be addressed by defining a third "SET" action to overwrite the current value (even if unused) as this action will use the same type as the two others and that of the underlying data (including endianness) for consistency. -- Adrien Mazarguil 6WIND From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 5F6E5A0096 for ; Mon, 8 Apr 2019 16:21:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 070A72C24; Mon, 8 Apr 2019 16:21:24 +0200 (CEST) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id C3EFE2BD8 for ; Mon, 8 Apr 2019 16:21:21 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id w10so16659585wrm.4 for ; Mon, 08 Apr 2019 07:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=s8KWKqv5cBSg/RPb6JayiWB4adwOSJDFB50jYJP6U+E=; b=bAJkwtFTtqhepo/jhj74n+gUTKFazHB6S63OQzRixiCZf1E34iSxZ+XCxijlP2C1ct 4eAT7df9tTgHPFE6itmbqZhRX7HZhiR47lvvAdW7toPru0IvLG+6D5pB/zNEh1kxfYDj zgX25XWRNkfWhjrdB9Lf05SYFkSiLdnjoWozqwWAu1qxXES6OK4m9e1dsblwVlCQXvf8 ltj9HjErRgA1JEMflbqLoAS4+dUS+Ay6Aym/mjbJMmolhXQykZxTsE0ssZ93J4Pwa8fH Cw+3YnaRNtVOhLY0OolJvXaYHM4nv3VoKM2I6L+M5hk5uKZSp3k1OXu2CQMmpbkLlhav ZApA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=s8KWKqv5cBSg/RPb6JayiWB4adwOSJDFB50jYJP6U+E=; b=tpXQxdH+I1gnYfauPp+K6EEPwHdp/W+BmsRQ/aBdIovoyYK5+p9OglxkXa1QxjLYI+ MGAhrtePhcL4WV9iubwX9G49qCX5Uq+g3sX7+2fODSuGLiT9wzhLYNrASlge7rcesD0W haCc8ZCg72utJ68lX8O1BVcX4OlbG+Yu2Q4OyXL9McpvEGltiWK8BvAyjO5RIZ2+U0y8 F6R0saXa8rAqPklSy+m2PF0zg8S/6Uz3Yjma0PCDctW3TLXQx20NBjB8utZx4Nm2SBqp POm/ueURC2NcY4Ex81HxCetZh6bIy9GO1ZSvQ5gYRbqebKeepePWrF9p+3HwOmRLIAFF YGlQ== X-Gm-Message-State: APjAAAVBJPISq/zaZ6L4nSdvNfMmT22BkWMJ1TFgh8By75FxNBYZ+yaV GLKLJcL/7qDN9G+NWl1A7e5jRA== X-Google-Smtp-Source: APXvYqzX6j/dWrVXjnuxRfGtVWgBCJE0RzCr3mzBYXDs/dzc2OhDnzYN1iV66ndB1DoBFrdyx6Mfyg== X-Received: by 2002:adf:ee91:: with SMTP id b17mr17637315wro.234.1554733281550; Mon, 08 Apr 2019 07:21:21 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 7sm103027829wrc.81.2019.04.08.07.21.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 07:21:20 -0700 (PDT) Date: Mon, 8 Apr 2019 16:21:18 +0200 From: Adrien Mazarguil To: Andrew Rybchenko Cc: Dekel Peled , Ori Kam , "wenzhuo.lu@intel.com" , "jingjing.wu@intel.com" , "bernard.iremonger@intel.com" , Yongseok Koh , Shahaf Shuler , "dev@dpdk.org" Message-ID: <20190408142118.GW4889@6wind.com> References: <1553177917-43297-1-git-send-email-dekelp@mellanox.com> <1554218001-62012-2-git-send-email-dekelp@mellanox.com> <20190403091432.GP4889@6wind.com> <20190403124921.GR4889@6wind.com> <20190404132556.GS4889@6wind.com> <66c690e9-8261-78b9-3287-50b444869bb5@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <66c690e9-8261-78b9-3287-50b444869bb5@solarflare.com> Subject: Re: [dpdk-dev] [PATCH v2 1/3] ethdev: add actions to modify TCP header fields 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" Message-ID: <20190408142118.jvryN6_VQDqQYACvTD7CJOn3VNFsjthOGDuhL-yCmAc@z> Hi Andrew, *Dekel* (I swear I'm not doing it on purpose, hopefully I won't make that stupid mistake again :) On Mon, Apr 08, 2019 at 04:53:54PM +0300, Andrew Rybchenko wrote: > On 4/8/19 4:36 PM, Dekel Peled wrote: > > Regarding Andrew's suggestion: "Shouldn't these action be RTE_FLOW_ACTION_TYPE_MOD_TCP_{ACK,SEQ} with singed 32-bit integer parameter (negative to decrement, positive to increment)?" > > I will leave the actions as is, the action names indicate the operation they perform. > > I think it is an overkill to have two actions for the purpose: DEC (value) > == INC ((uint32_t)-value) > If it is really important to have DEC and INC, please, make it clear from > actions documentation why. The main reason in my opinion is that a signed value may not be able to represent an increment large enough for an unsigned value of the same bit width. This can be worked around by using a type larger than the underlying data field (e.g. i64 for u32), but it will look confusing and is not an option for the largest unsigned type we support (u64). Another problem is what endian increment/decrement actions should use. There are no dedicated endian types for signed values at the moment, and I'm not sure we should define any. This could be addressed by defining a third "SET" action to overwrite the current value (even if unused) as this action will use the same type as the two others and that of the underlying data (including endianness) for consistency. -- Adrien Mazarguil 6WIND