From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 1D8F01B16C for ; Tue, 9 Jan 2018 13:48:55 +0100 (CET) Received: by mail-wm0-f41.google.com with SMTP id i11so20378057wmf.4 for ; Tue, 09 Jan 2018 04:48:55 -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:content-transfer-encoding:in-reply-to :user-agent; bh=D8BR5qrPhvkZNlYJbuKJGiRvUuUyA8CJKZoUujrtvWk=; b=VbSGTW/V+UipPaPgJchxmwhNGXXeViO33bU4f4ja14xR9G4+OHaC4ykYiyDaqRBAOK psqjlOxJZB7Gc6v1/NxoUfzR2VCVuR6eVrOl19tlOaf+g4DUDz9uC5ZiHHXcPa4wjVUw +dN2EkRj04x/d6mwSDy+2ho79Zj8hedgzB44MVvWsmd7QDJVN5WuIZCKzieaGyEuAe5s O2cT+xxxnIOpMOD/M1RCHYMbSZEe8DovPuTCARCI19KJZwJ03Wp26MgEZiqfC5BWQ7Tv LfQYojyNNI9ff+mk6IM1BizVdYlDMqRhksncp+AAZ5jtE02GJHOk5HlXBkTvTqEGMguK Hpjg== 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:content-transfer-encoding :in-reply-to:user-agent; bh=D8BR5qrPhvkZNlYJbuKJGiRvUuUyA8CJKZoUujrtvWk=; b=n3gcqcGaCd0f7ysSoBumXjggIF0bElB8YaVyyeAZefdQ912HbTtsYMvc639RxRj7kQ hDbwJk2ZURsAMF4cEpVy2rK4/hEowJp9pSzwo0b0y6w8I2xnsfibeE5cunrwLstHNCWD +09r2Byq9NMXxlSh1cWe/QQi392UYMf1hFk8dZM0z1/VTakF118MpY8yo7UVnyAmCjGs SIV2UOQArl72wf53pSdHSSYsbfcAvLHXyVGAzgmVZcxf9X00n6bGKyfFq2fEGP65Hplv 5jxnfyw9ChIEX/Zu1j14dv9btcm6CCFVpEAkQVu9n44qUuVnuD2OnNVCoBc/yqR/+al9 9yXg== X-Gm-Message-State: AKGB3mIq4gGlKEKpofflaxr8MnBjXVUfTIs2E0QFTRZjpdzrHHOVy0rd CI8nz0KqEYnoSXEw0AjoZlrv X-Google-Smtp-Source: ACJfBoukkZk99mHbTSsjsnVMeOUi3ESySKvjYqi6JPQ/QextGmGq5+NBtm37d6UE5tXNo5AZfayBUA== X-Received: by 10.80.164.3 with SMTP id u3mr21372007edb.282.1515502134751; Tue, 09 Jan 2018 04:48:54 -0800 (PST) Received: from laranjeiro-vm.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id f36sm8277475edd.82.2018.01.09.04.48.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 09 Jan 2018 04:48:54 -0800 (PST) Date: Tue, 9 Jan 2018 13:48:20 +0100 From: Nelio Laranjeiro To: Anoob Joseph Cc: Adrien Mazarguil , Boris Pismenny , Sergio Gonzalez Monroy , Radu Nicolau , Aviad Yehezkel , Liran Liss , "dev@dpdk.org" , Jerin Jacob , Narayana Prasad Message-ID: <20180109124820.6t2cawqb5ot7difc@laranjeiro-vm.dev.6wind.com> References: <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> <20171221142235.GL5377@6wind.com> <6de0bb26-11dc-f7b3-cc87-dd1f3a00723c@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6de0bb26-11dc-f7b3-cc87-dd1f3a00723c@caviumnetworks.com> User-Agent: NeoMutt/20170113 (1.7.2) 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: Tue, 09 Jan 2018 12:48:55 -0000 Hi Anoob, On Fri, Jan 05, 2018 at 11:48:50AM +0530, Anoob Joseph wrote: > Hi Adrien, > > > On 12/21/2017 07:52 PM, Adrien Mazarguil wrote: > > 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. > Good suggestion. For ingress this would help. The only problem with this is > the size of ID. Since it is 32 bit, this particular mark cannot be used to > save and retrieve application pointers. If it was 64 bit, this could've > solved all the metadata problems. > > For egress, PMD would still need to do a lookup as, the mark ID would be 32 > bit and has to be matched with the same in various flows. Though this is > better than what we have right now(with flows), this may still be more > costlier than "set_pkt_metadata" method. It depends on how you implement it, it can be a simple table using it as an index, it can be a simple hash based on the tunnel informations, etc... set_pkt_metada() has two issues: 1. it is device specific [1] as described in the API. For an application it is unusable. 2. it is a function called per packet which is costly and don't give any benefit for an application which can directly store the pointer in the mbuf without calling such function. > > 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. > > Regards, [1] https://dpdk.org/browse/next/dpdk-next-crypto/tree/lib/librte_security/rte_security.h#n331 -- Nélio Laranjeiro 6WIND