From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 4C6861B3AF for ; Thu, 12 Oct 2017 18:14:32 +0200 (CEST) Received: by mail-wm0-f43.google.com with SMTP id b189so14497827wmd.4 for ; Thu, 12 Oct 2017 09:14:32 -0700 (PDT) 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=7zTVMDTYTNAfBDonAwiUUypylgIkhnDEsO5rxZwyCVA=; b=DgyE0oX2RaVQIJeWbXcV158Nj1yjSm4m852fzholnTGZsVNPCpIxDWEnMa06FSZur/ hQwZGdCsEiW8wjeAFTM1XQWFAqvLkwJYPR7wGcwrsrmt6HCaITDVLsjvFQkU19n5wioh vc0QN+i6wMQkQ+uIRtGiQ+5QB6Z2AunFb77EWxnR1qU1X4xbP0Gk2KjwRlub1KXDyUii AcmbuewIDpznX+niQHspxHXRZFIX+zEb9rGfDodP+we2n5lL4PcmTr9oyAHgJ3aKMzA+ M8YME1Btwa8qvJ69jKjiiNXdLLvKu51r1NClQL+q/jALgRCPg3IZSyYgx4/CzOwKxVWY tyVQ== 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=7zTVMDTYTNAfBDonAwiUUypylgIkhnDEsO5rxZwyCVA=; b=VcfFPwe0k1kjItGXf1vLCB4eBSg/xIZsU6fwSjP/9WrqoIzrxJoU0U3W2XMtXxgloR IRd+BKN4mfP9RsHflOFxUixugXCy7iWpK2ddDPPXiOeND1WxjTY8NQenRTdqfNoIS1wS /JWezobmC77O8ukCWY/1gf/7NRDNOFpNUowvBWRtZSYbwx8eaW7aHrOQDC4j+FSmtewe apRZGFEV/C9OZMuWctxsf1Fj2h7wyeqHBRgIzXF/H0Z1YqnHbPZHhMe8x4HVdKn653um VuP9CTLlm5DV+Mzwf1oNp8mtOUIIEBUH22dTSc9uq1kTUkWQWbxFFXDGZvQBX5JuUe8D i+fA== X-Gm-Message-State: AMCzsaUI8ZovwhdQnuYU5F9Qj8eseA4PoQeuT1YgSuMN6GzbDkKo4CLC SlCKw8tWuzeA3DCTGSENRB8cUw== X-Google-Smtp-Source: AOwi7QD9xgtlKZIor0TnoXLC9vifjz0TVZ8EjQ78kmuZabjfn1jp6utMFVwerjntlv+qX2Njz3/pTA== X-Received: by 10.223.162.199 with SMTP id t7mr2484314wra.163.1507824872651; Thu, 12 Oct 2017 09:14:32 -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 u52sm28691626wrb.23.2017.10.12.09.14.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Oct 2017 09:14:31 -0700 (PDT) Date: Thu, 12 Oct 2017 18:14:20 +0200 From: Adrien Mazarguil To: "Rybalchenko, Kirill" Cc: Thomas Monjalon , "dev@dpdk.org" , "Chilikin, Andrey" , "Xing, Beilei" , "Wu, Jingjing" , "Yigit, Ferruh" Message-ID: <20171012161420.GW13551@6wind.com> References: <1507666412-15320-1-git-send-email-kirill.rybalchenko@intel.com> <1507667338-15742-1-git-send-email-kirill.rybalchenko@intel.com> <1507667338-15742-2-git-send-email-kirill.rybalchenko@intel.com> <8389257.54itpyZSoc@xps> <696B43C21188DF4F9C9091AAE4789B824E2A26F5@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <696B43C21188DF4F9C9091AAE4789B824E2A26F5@IRSMSX108.ger.corp.intel.com> Subject: Re: [dpdk-dev] [PATCH v5 1/4] ethdev: add support for raw flow type for flow director 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, 12 Oct 2017 16:14:33 -0000 Hi Kirill, On Thu, Oct 12, 2017 at 11:41:50AM +0000, Rybalchenko, Kirill wrote: > Hi Thomas, > > The reason this feature is needed is to be able to program custom flow types using a template packet rather than building up a C struct to define the protocol. This means that users don't have to work on the DPDK internals to support new flow types that they may be using, but can instead add them dynamically as part of their application. There are also several customers who are looking for this feature as part of the 17.11 LTS release. > > This patchset has been out since August and these comments are very late, with the first objections last week, which we tried to answer. This short notice doesn't allow us a reasonable amount of time to take them into account. > > However, to address your primary concern, we can implement this using a i40e private API, so that we are not tying users to FDIR APIs and thus not blocking the removal of the APIs in time. > > Ideally we would like to use rte_flow but it is based around the idea of describing packet headers which is significantly different from the proposed method using template packets. Longer term it may be possible to support this in rte_flow, we could propose this for discussion in the next release, and if there is community interest/agreement we can add it. > > We will rework this, in the short term, as a private API, as suggested above, and then propose an rte_flow API in the longer term. Let us know if you have any concerns about this. I am not trying to push for its integration through rte_flow at this stage and I don't mind the chosen PMD-specific approach, I'm just curious about the reasons that made it hard to implement as a RTE_FLOW_ITEM_RAW thing? (e.g. a rule with a pattern that only contains one or several such items) Please have a look at the rte_flow_item_raw structure in rte_flow.h, tell me what's missing in there and I'll take it into account during the next overhaul. Thanks in advance for your feedback. -- Adrien Mazarguil 6WIND