From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) by dpdk.org (Postfix) with ESMTP id 027C2BD34 for ; Mon, 16 Apr 2018 15:31:13 +0200 (CEST) Received: by mail-wr0-f169.google.com with SMTP id q13so22627064wre.3 for ; Mon, 16 Apr 2018 06:31:13 -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=JZO5e9FkNooYZ9DRLcoBm2dOsrdTROe8KxEsNOzalIs=; b=IOxokhsHx+H70+vtiZVmk1oqDjBmu/IpmlIY5ACVsMtdfH4URMKzERcb88ZtcUox1j HAHYq+rjJNGEmcIV1LVX9izaNxcN/afdDAWDBtauJQp3UHBuyYd9YgNTuHptGcNcUt3O W2C6DaCU0zVt9H0tVrVjuMz8Sg1Kdx0ToT1xC1DrtkwESkVo1e81GVSyNbs/jhBAmV6b 0MlqsP0kgi5PhzW0zyY/5+7ix6BKG7d6TeUL2mP+MbOQ5/CsNPtfSHTVSjM2cXkexjVp GjT9j/R/k8sftEdz5iJUAOTmnV66mIAFRNSOevMbRLcLfv9MoPtYtzCuL0vrUP6rfkxS sBhA== 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=JZO5e9FkNooYZ9DRLcoBm2dOsrdTROe8KxEsNOzalIs=; b=pSpRvSW1oPNHK+xkRGajQI4I9B5brl2sg96W8Cr6Pc1wrkzk8v7J+/+WAspOjoK53a gZqXyNhWuv+izOoyWBd7jKTA3AdpCMC1Yd/V46Pz2r6LaBjY0lRuIyKf4guhQkSMDaoP EkAA+/bS37p96rLTbXcBShMM6vlZbETJlRTEmm8mKhY21c4lEgUlAvN6tXGA33ws8JlV ycWCsjiG2xnOPa7M1fF8iw01c9WZXFKwjyFRU52oYv3bhvzIkEcp/phOIQ8IHm0I8hM3 rUki0zuayZUlCVjhUaY2JoUcfaioUjQn6Y8zVsnRZJnXhcxZmRJZ6oXTVBN5y+/8OYOc lnmQ== X-Gm-Message-State: ALQs6tB0siKaciRVnSA8JVExbJqGeASLoJ+T7G1stpkgSLNuSFqsn7AW VmUPulFvnqdmn2gl/GO9+SXICcjZ X-Google-Smtp-Source: AIpwx4/nbc5vighP+g7mXzmp5WOhquhe+fPd0sf6F8ilJrUNqaj3rsd4zSf6+bkYljcZSeudU1ZBaw== X-Received: by 10.223.161.79 with SMTP id r15mr10002372wrr.271.1523885473730; Mon, 16 Apr 2018 06:31:13 -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 p187sm7075058wme.8.2018.04.16.06.31.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 06:31:13 -0700 (PDT) Date: Mon, 16 Apr 2018 15:30:59 +0200 From: Adrien Mazarguil To: "Zhang, Qi Z" Cc: "dev@dpdk.org" , "Doherty, Declan" , "Chandran, Sugesh" , "Glynn, Michael J" , "Liu, Yu Y" , "Ananyev, Konstantin" , "Richardson, Bruce" Message-ID: <20180416133059.GY4957@6wind.com> References: <1522279780-34842-1-git-send-email-qi.z.zhang@intel.com> <1522617562-25940-1-git-send-email-qi.z.zhang@intel.com> <1522617562-25940-5-git-send-email-qi.z.zhang@intel.com> <20180412070343.GO4957@6wind.com> <039ED4275CED7440929022BC67E70611531903F5@SHSMSX103.ccr.corp.intel.com> <20180412102255.GQ4957@6wind.com> <039ED4275CED7440929022BC67E7061153191023@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <039ED4275CED7440929022BC67E7061153191023@SHSMSX103.ccr.corp.intel.com> Subject: Re: [dpdk-dev] [PATCH v2 4/4] ether: add packet modification aciton in flow API 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, 16 Apr 2018 13:31:14 -0000 On Fri, Apr 13, 2018 at 01:47:15PM +0000, Zhang, Qi Z wrote: > > -----Original Message----- > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > Sent: Thursday, April 12, 2018 6:23 PM > > To: Zhang, Qi Z > > Cc: dev@dpdk.org; Doherty, Declan ; Chandran, > > Sugesh ; Glynn, Michael J > > ; Liu, Yu Y ; Ananyev, > > Konstantin ; Richardson, Bruce > > > > Subject: Re: [PATCH v2 4/4] ether: add packet modification aciton in flow API > > > > On Thu, Apr 12, 2018 at 08:50:14AM +0000, Zhang, Qi Z wrote: > > > Hi Adrien > > > > > > > -----Original Message----- > > > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > > > Sent: Thursday, April 12, 2018 3:04 PM > > > > To: Zhang, Qi Z > > > > Cc: dev@dpdk.org; Doherty, Declan ; > > > > Chandran, Sugesh ; Glynn, Michael J > > > > ; Liu, Yu Y ; > > > > Ananyev, Konstantin ; Richardson, > > > > Bruce > > > > Subject: Re: [PATCH v2 4/4] ether: add packet modification aciton in > > > > flow API > > > > > > > > On Sun, Apr 01, 2018 at 05:19:22PM -0400, Qi Zhang wrote: > > > > > Add new actions that be used to modify packet content with generic > > > > > semantic: > > > > > > > > > > RTE_FLOW_ACTION_TYPE_FIELD_UPDATE: > > > > > - update specific field of packet > > > > > RTE_FLWO_ACTION_TYPE_FIELD_INCREMENT: > > > > > - increament specific field of packet > > > > > RTE_FLWO_ACTION_TYPE_FIELD_DECREMENT: > > > > > - decreament specific field of packet > > > > > RTE_FLWO_ACTION_TYPE_FIELD_COPY: > > > > > - copy data from one field to another in packet. > > > > > > > > > > All action use struct rte_flow_item parameter to match the pattern > > > > > that going to be modified, if no pattern match, the action just be > > > > > skipped. > > > > What happens when this action is attempted on non-matching traffic > > > > must be documented here as well. Refer to discussion re "ethdev: Add > > > > tunnel encap/decap actions" [3]. To be on the safe side, it must be > > > > documented as resulting in undefined behavior. > > > > > > so what is "undefined behavior" you means? > > > The rule is: > > > If a packet matched pattern in action, it will be modified, otherwise > > > the action just take no effect is this idea acceptable? > > > > Not really, what happens will depend on the underlying device. It's better to > > document it as undefined because you can't predict the result. Some devices > > will cause packets to be lost, others will let them through unchanged, others > > will crash the system after formatting the hard drive, no one knows. > > OK, basically I think "undefined behavior" is not friendly to application, we should avoid. > But you are right, we need to consider device with different behavior for " modification on non-matched pattern" > I'm thinking why driver can't avoid non-matched pattern modification if the device does not support? > For example, driver can reject a flow ETH/IPV4 with TCP action, but may accept ETH/IPV4/TCP with TCP action base on > its capability. Drivers are free to accept an action or not depending on what is guaranteed to be matched on the pattern side. It's fine as long as the resulting flow rule works exactly as documented. Consistency is much more important to applications than offloads proper. Depending on device capabilities and the importance given to offload specific use cases by vendors, PMD support may range from a basic 1:1 translation attempt between rte_flow and device format, to an all out processing effort resulting in multiple device flow rules and whatnot to satisfy the request by any means necessary (see mlx5 RSS support on empty patterns in case you're curious). Whichever approach you choose (basic or complex), my recommendation is simply to make sure the PMD reports an error whenever a flow rule is ambiguous and could result in unexpected behavior if applied as is to the device. The error message should also be helpful. A message such as "unable to apply flow rule" is pretty useless, while "this action is not supported when X pattern item is not present" actually gives useful information. "Undefined behavior" is for application writers. It means that if a PMD happens to accept the rule in question, what happens isn't covered by documentation. Ideally a PMD shouldn't accept it in the first place though. -- Adrien Mazarguil 6WIND