From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 7FD431B289 for ; Thu, 21 Dec 2017 15:22:48 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id g75so16380710wme.0 for ; Thu, 21 Dec 2017 06:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=HPIou0yOH9CIe1aOEHwGF7n2wNUnajHnsbP7/bk0Ov0=; b=S9GwU386jof5k18p6QXxzbj2YS4dBO2UfjVxy6c96b8FomsBlN38qL87kZhtfbnUWD WYWQyomqC3VXIPXPFxR1vNfnZmiT3p2NBlMPZ6D4OVPFJ78GjV2ZJ0RadL0zucCsReU+ qCgvzivAvUzXw466k7c86KsHuQfJwMRpYooJuysBI3sGkQarUaWUrzj1ZjU0SY8RgZzU clyr8m4Br91u4Sw/tVvkQTbzzoiLT0JUWPCLu0OK/iU6xmqhr1DVyUKDv95Ehg12QBk2 ryXCMdvv5eeeAEl50jVz4rIBDKj9oMqrPoK/8U2Tc9LszLLa4B39GrxSluGll4FYBWPw y8Ww== 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=HPIou0yOH9CIe1aOEHwGF7n2wNUnajHnsbP7/bk0Ov0=; b=Q1CbkTzZmFW5XkLdasoBbtaV2gJDD4pipOphfXFH1qkW7BrX6AKo5SVcOs1oqkR9ih tEAnV/MV+Y9XO1Ad7MYqQfxlme5PuqTmOJXXCgMbNLgNvHKNXeKnfdkpbfV96E1nxgqb 9aptrH9NlO5E0dPKP/jRhoE80VSKBF3XnuSthVDyykG2kXU6nmOQ9GYdMJvk5rWwz72v 9svxHcg/OjVE/BefTWqinFDKMt18QAglO1RiI1aW9Fgfmw34Vh4kdE56YfXu2SL2fi26 lRYST/0gxcdsAnZk0cm75rjekUu/fqs3pVFViLTThC1fyvqsk68riFRBwEhpWpHZQhRH di9A== X-Gm-Message-State: AKGB3mJrNcn0njvrm/NoQAzJU+qkY356KUyZzS64sP55ivOo/71vr1GK qv/mein6HNErH/dliTxxdSRarQ== X-Google-Smtp-Source: ACJfBoseE6woYZ9bLRA8op3jbVdmJFcX52bhLY2LtCtcRIW3dOH4QgDxa+i0+hylLJkdNT5WQQOjcA== X-Received: by 10.28.10.5 with SMTP id 5mr8983183wmk.74.1513866167920; Thu, 21 Dec 2017 06:22:47 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 201sm5242237wmm.38.2017.12.21.06.22.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Dec 2017 06:22:46 -0800 (PST) Date: Thu, 21 Dec 2017 15:22:35 +0100 From: Adrien Mazarguil To: Boris Pismenny Cc: Anoob Joseph , =?utf-8?B?TsOpbGlv?= Laranjeiro , Sergio Gonzalez Monroy , Radu Nicolau , Aviad Yehezkel , Liran Liss , "dev@dpdk.org" Message-ID: <20171221142235.GL5377@6wind.com> References: <20171212143800.ggdtdfnbknttr45g@laranjeiro-vm.dev.6wind.com> <047cadcf-13dc-5368-4ad5-a27ff25c42f8@caviumnetworks.com> <20171213100237.uvpbg2qewhxqgaln@laranjeiro-vm.dev.6wind.com> <817bec1f-4bff-ebdc-07b4-f8f24ec2084a@caviumnetworks.com> <20171213125353.2zyllxk7pwkncm76@laranjeiro-vm.dev.6wind.com> <577d100a-d021-1219-89e3-721e02b77b90@caviumnetworks.com> <20171213144710.tyqvcvpkrymzqriv@laranjeiro-vm.dev.6wind.com> <3a91e865-ca96-09d4-b842-7e5d0a5ad6e1@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a91e865-ca96-09d4-b842-7e5d0a5ad6e1@mellanox.com> Subject: Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow 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: Thu, 21 Dec 2017 14:22:48 -0000 On Thu, Dec 21, 2017 at 12:12:29PM +0200, Boris Pismenny wrote: > On 12/21/2017 10:06 AM, Anoob Joseph wrote: > > I can see the benefits of using rte_flow in both rx & tx, but this > > unnecessarily introduces hardware requirements for supporting inline. > > Rte_flow would do two operations: > > 1) Pattern matching > > 2) Perform some operation with the above matched packets > > > > Issue is with pattern matching, not about performing the operations > > specified. If we need rte_flow in the tx, the PMD should support pattern > > matching in software or hardware. Since the application will have to do > > a lookup in it's space to determine the SA, the secondary lookup in the > > PMD may not be necessary. But making rte_flow mandatory would make tx > > side pattern matching mandatory, which may not be supported on all > > hardware (with inline crypto/protocol). Also the pattern matching > > hardware module should be able to submit to inline performing module for > > this to work. > > > > May be the right approach is to decouple pattern matching from actions > > to be performed for the flow. In other words, add a new API to allow > > application to submit a packet to a flow. In such case, application > > could do the lookup and submit packet to a flow. The packet submitted > > could be validated to see if it is matching the flow properties. If it > > is matching, then the actions specified for the flow would be performed. > > Adding such an API will allow rte_flow to be used with hardware which > > doesn't have packet filtering features. > > > > The flow could have a "pattern item" which would say whether application > > can submit packets to the flow. Submit would be allowed only for those > > flows. flow_validate would give PMD the option to accept or reject such > > a model. This may need some thought before we can start implementing, > > like, whether we should support "submit" for flows which doesn't have > > terminating action. > > > > Any thoughts? > > I think that your suggested API is more or less the intended use of rte_flow > egress actions with rte_security. > > Would it be wrong to say that you could use rte_flow without doing pattern > matching in HW or in the PMD in the data-path? > Suppose that your HW doesn't support pattern matching on tx. But, you do > support IPsec inline crypto on tx according to user provided pointers that > you set in the set_pkt_metadata callback. The user will call rte_create_flow > with some pattern, in response you check that the driver's set_pkt_metadata > could handle such patterns and actions on tx. If yes, then return success, > otherwise return false. The successful creation of the flow will indicate to > the user that packets with this format will be offloaded. Packets with other > formats will not get offload and set_pkt_metadata for such packets shouldn't > be called! > > When using rte_flow with IPsec, it is used not to indicate that HW must do > this pattern matching. But rather to indicate that software will send > packets that match a pattern with proper metadata and expect an action to be > applied. Software cannot expect this action to be applied unless the packet > matches the pattern and the proper metadata is provided. For example, > packets with IPv6 extension headers should not go through IPsec inline > crypto offload if the pattern is IPv6/ESP because the next IP protocol must > be ESP. I think there's already a way to satisfy everyone regarding context requirements on TX without the huge penalty of SW parsing in case HW doesn't support matching on egress. While seldom used at the moment, rte_flow patterns can match packet meta-data (see meta pattern items); for instance RTE_FLOW_ITEM_TYPE_PORT matches a physical port of the underlying device. This works both with ingress and egress. For ingress, RTE_FLOW_ACTION_TYPE_MARK can be used to add meta data to selected packets. While for egress such an action doesn't make much sense at the moment, the converse meta pattern item (RTE_FLOW_ITEM_TYPE_MARK) could be useful to let PMD know what needs to be done with packets submitted by the application and containing a given mark. That way, PMDs that do not support egress packet matching wouldn't need to lie and would reject rules such as: flow create X egress pattern ip / udp / end actions whatever / end But would accept: flow create X egress pattern mark is 42 / end actions whatever / end PMDs could also support combinations (remember the position of meta items within a pattern is not significant) to only perform whatever for UDPv4 packets marked with 42. Non-marked packets would go through unmodified: flow create X egress pattern ip / udp / mark is 42 / end actions whatever / end This is just to point out how leveraging meta pattern items on egress is one possibility using MARK as an example. -- Adrien Mazarguil 6WIND