From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 1531D6CA2 for ; Fri, 8 Jul 2016 15:25:49 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id n127so12930204wme.1 for ; Fri, 08 Jul 2016 06:25:49 -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:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=as1ZoHH9itwIOJ2A1m48NlxH6/W+ZqIEjNKQMZ2IitM=; b=yMpdiDGzXjeyDiLU0HtUTRaZgFHV5A46gPnA3vuzTL7DG17rHKw9KMLZNW872qPyXe Bep1jhRskvIIWl5eVq8tiQGdt1qaBuLTqdhHWh66tPFw0SvR8+TcJp2VvAhP+ACQZzTK 4LelJGRpZw3+eblxAdBQkGTOqHTquJyrpp44XXGPTUdoN8prgcjRuHcZk7jnpguIizaH vPBw+WYWAUk1NSqFJapmn4CvaFCnYB0M5JC8iLBobtBP4RQvL+VMbV9cojZAvloVegr1 Y14SnNtElRp0uk0kkHluDFGQYyydf9ZpaKZj8znngCwGFJLZyPYUqN86XmZcLYTqRnel /VpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=as1ZoHH9itwIOJ2A1m48NlxH6/W+ZqIEjNKQMZ2IitM=; b=ZZ+Iw+0swJuiQbBXmkPrQEJY4EgQoUGE4DVJw5Q6P2MYY/ikjQLF1AkqjuJo1pulCB yS5JOiIHa2gww+OB6iRfMinRifuig9uGdYCT3WmIQ5vupIliiE0qkknboICEhpszoTLN b8j9aD1LrT1560uXQG8vsGOTnX1aD/0LzSv/SKqR4+CyCTeq7AeeQgRJbd7kxngwFfaN g6FVZOTteTiNgTuJw/DdXTE/H/Gu2kU9rL4KT/ioUKUv2MZMx0wdfgX/5PQmGgyfFMmO BWqvlVIP8fNDcqNu7aB8OupZF3XuYQQB1TX87pxqVaXPAg/plFz9biNnaUUQnYcsC3vj RhFg== X-Gm-Message-State: ALyK8tJBgI/bCcRXGy0on+g29KO4pUJdYYN3QR5ekTgiWemIBn/2v8rdVYAnLBzzLr+fHieV X-Received: by 10.194.236.195 with SMTP id uw3mr6195812wjc.149.1467984348863; Fri, 08 Jul 2016 06:25:48 -0700 (PDT) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id f189sm3035386wmf.19.2016.07.08.06.25.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jul 2016 06:25:48 -0700 (PDT) Date: Fri, 8 Jul 2016 15:25:44 +0200 From: Adrien Mazarguil To: "Liang, Cunming" Cc: dev@dpdk.org, Thomas Monjalon , Helin Zhang , Jingjing Wu , Rasesh Mody , Ajit Khaparde , Rahul Lakkireddy , Wenzhuo Lu , Jan Medala , John Daley , Jing Chen , Konstantin Ananyev , Matej Vido , Alejandro Lucero , Sony Chacko , Jerin Jacob , Pablo de Lara , Olga Shern Message-ID: <20160708132544.GE7621@6wind.com> Mail-Followup-To: "Liang, Cunming" , dev@dpdk.org, Thomas Monjalon , Helin Zhang , Jingjing Wu , Rasesh Mody , Ajit Khaparde , Rahul Lakkireddy , Wenzhuo Lu , Jan Medala , John Daley , Jing Chen , Konstantin Ananyev , Matej Vido , Alejandro Lucero , Sony Chacko , Jerin Jacob , Pablo de Lara , Olga Shern References: <20160705181646.GO7621@6wind.com> <577F8A60.2000409@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <577F8A60.2000409@intel.com> Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 13:25:49 -0000 Hi Cunming, I agree with Bruce, I'll start snipping non relevant parts considering the size of this message. Please see below. On Fri, Jul 08, 2016 at 07:11:28PM +0800, Liang, Cunming wrote: [...] > >Meta item types > >~~~~~~~~~~~~~~~ > > > >These do not match packet data but affect how the pattern is processed, most > >of them do not need a specification structure. This particularity allows > >them to be specified anywhere without affecting other item types. > [LC] For the meta item(END, VOID, INVERT) and some data matching type like > ANY and RAW, > it's all PMD responsible to understand the key character and to parse the > header graph? We haven't started on the PMD side of things yet (the public API described here does not discuss it), but I think PMDs will see the pattern as-is, untranslated (to answer your question, yes, it will be the case for END, VOID, INVERT, ANY and RAW like all others). However I intend to add private helper functions as needed in librte_ether (or anywhere else in EAL) that PMDs can call to ease parsing and validation of flow rules, otherwise most of them will end up implementing redundant functions. [...] > >When several actions are combined in a flow rule, they should all have > >different types (e.g. dropping a packet twice is not possible). However > >considering the VOID type is an exception to this rule, the defined behavior > >is for PMDs to only take into account the last action of a given type found > >in the list. PMDs still perform error checking on the entire list. > > > >*Note that PASSTHRU is the only action able to override a terminating rule.* > [LC] I'm wondering how to address the meta data carried by mbuf, there's no > mentioned here. > For packets hit one specific flow, usually there's something for CPU to > identify the flow. > FDIR and RSS as an example, has id or key in mbuf. In addition, some meta > may pointed by userdata in mbuf. > Any view on it ? Yes, this is defined as the ID action. It is described in 4.1.6.4 (ID) and there is an example how a FDIR rule would be converted to use it in 5.7 (FDIR to most item types → QUEUE, DROP, PASSTHRU). It is basically described as a flow rule with two actions: queue redirection and packet tagging. Does it answer your question? -- Adrien Mazarguil 6WIND