From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f68.google.com (mail-pa0-f68.google.com [209.85.220.68]) by dpdk.org (Postfix) with ESMTP id 825DC58C5 for ; Sat, 23 Jul 2016 23:10:47 +0200 (CEST) Received: by mail-pa0-f68.google.com with SMTP id hh10so8935102pac.1 for ; Sat, 23 Jul 2016 14:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Dnc7Ha8N9oiWggEsM31MfWQOH+DbA0Dpxj3ilpw/MMI=; b=DogPsT0vrEYf0aIk6VzMIHEvElgVW1IB/Dqd/iUiHtDymHqY2zW0X/hyvkDHDbqNrh +phbQqex0v8UqHDIUGMFAXcb0e8zhxMpTPK6Br7ugl4BR+fblht2DkGCp8lqaS6M/3zt MuPeycie0s7U1KEkA/sfSRrAOtVAvk3q3zM5dvZvkDPsKSFwDou3rqx6M8p7BfUmPmOe 7z4KzE7cSB1Gmsnd7Q6f0PuM0aVRP/lI3J1b10puuskAbRrmBw99tX3k+Mu3/yQhZTTw xzvnjLFN/qEt6DPOU91rkpOHt3r2fYaPcgpOuWKmOH8z/ly6SJ6DN7SxPJeTXGDjmXWa zpUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Dnc7Ha8N9oiWggEsM31MfWQOH+DbA0Dpxj3ilpw/MMI=; b=OD/Bq7XIfT0U1UpZaX9Anm48g1hLoG3lJHijys3DKnrYwYmdx/Nf5GBV6AfC4yEtU+ JnaijQ913tZN01ilxLHc60chzPeRW3V0EhThSDpk0hjDEhMlyzCum04c0PU6zo8qOCmm U6679plIEMiJU+sMcIP0lkscLoye8qQzy0bqUJcKanxArI1J2Nuc8zcwQ1+jcDTMZrO+ Gs1XFGCePWa6fPczkuyiYOg7Ai1uYa+F7vF63tf+H2dY6Cdb/I1k/xakPBS8Hls1SZvx 3EE4pJGzg9qvdRGHOL4InX9EOuf09SJQAz5XrcEiBUCyk0PKgD0FmTUYfDnnmP+FX3kq ZzCw== X-Gm-Message-State: AEkoout/KZLCvxOIoinX6CQtuzrSt1tLxUaIN1/KWMZ6L8rIGoyLL1YloOG5jNKsf2juKg== X-Received: by 10.67.22.137 with SMTP id hs9mr17404558pad.50.1469308246624; Sat, 23 Jul 2016 14:10:46 -0700 (PDT) Received: from [192.168.1.6] ([72.168.145.98]) by smtp.googlemail.com with ESMTPSA id tm1sm29165923pac.23.2016.07.23.14.10.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jul 2016 14:10:45 -0700 (PDT) To: Jerin Jacob , 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 , Pablo de Lara , Olga Shern References: <20160705181646.GO7621@6wind.com> <20160711104141.GA10172@localhost.localdomain> <20160721192023.GU7621@6wind.com> From: John Fastabend Message-ID: <5793DD3E.3080605@gmail.com> Date: Sat, 23 Jul 2016 14:10:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160721192023.GU7621@6wind.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Sat, 23 Jul 2016 21:10:47 -0000 On 16-07-21 12:20 PM, Adrien Mazarguil wrote: > Hi Jerin, > > Sorry, looks like I missed your reply. Please see below. > Hi Adrian, Sorry for a bit delay but a few comments that may be worth considering. To start with completely agree on the general problem statement and the nice summary of all the current models. Also good start on this. > > Considering that allowed pattern/actions combinations cannot be known in > advance and would result in an unpractically large number of capabilities to > expose, a method is provided to validate a given rule from the current > device configuration state without actually adding it (akin to a "dry run" > mode). Rather than have a query/validate process why did we jump over having an intermediate representation of the capabilities? Here you state it is unpractical but we know how to represent parse graphs and the drivers could report their supported parse graph via a single query to a middle layer. This will actually reduce the msg chatter imagine many applications at init time or in boundary cases where a large set of applications come online at once and start banging on the interface all at once seems less than ideal. Worse in my opinion it requires all drivers to write mostly duplicating validation code where a common layer could easily do this if every driver reported a common data structure representing its parse graph instead. The nice fallout of this initial effort upfront is the driver no longer needs to do error handling/checking/etc and can assume all rules are correct and valid. It makes driver code much simpler to support. And IMO at least by doing this we get some other nice benefits described below. Another related question is about performance. > Creation > ~~~~~~~~ > > Creating a flow rule is similar to validating one, except the rule is > actually created. > > :: > > struct rte_flow * > rte_flow_create(uint8_t port_id, > const struct rte_flow_pattern *pattern, > const struct rte_flow_actions *actions); I gather this implies that each driver must parse the pattern/action block and map this onto the hardware. How many rules per second can this support? I've run into systems that expect a level of service somewhere around 50k cmds per second. So bulking will help at the message level but it seems like a lot of overhead to unpack the pattern/action section. One strategy I've used in other systems that worked relatively well is if the query for the parse graph above returns a key for each node in the graph then a single lookup can map the key to a node. Its unambiguous and then these operations simply become a table lookup. So to be a bit more concrete this changes the pattern structure in rte_flow_create() into a tuple where the key is known by the initial parse graph query. If you reserve a set of well-defined key values for well known protocols like ethernet, ip, etc. then the query model also works but the middle layer catches errors in this case and again the driver only gets known good flows. So something like this, struct rte_flow_pattern { uint32_t priority; uint32_t key; uint32_t value_length; u8 *value; } Also if we have multiple tables what do you think about adding a table_id to the signature. Probably not needed in the first generation but is likely useful for hardware with multiple tables so that it would be, rte_flow_create(uint8_t port_id, uint8_t table_id, ...); Finally one other problem we've had which would be great to address if we are doing a rewrite of the API is adding new protocols to already deployed DPDK stacks. This is mostly a Linux distribution problem where you can't easily update DPDK. In the prototype header linked in this document it seems to add new headers requires adding a new enum in the rte_flow_item_type but there is at least an attempt at a catch all here, > /** > * Matches a string of a given length at a given offset (in bytes), > * or anywhere in the payload of the current protocol layer > * (including L2 header if used as the first item in the stack). > * > * See struct rte_flow_item_raw. > */ > RTE_FLOW_ITEM_TYPE_RAW, Actually this is a nice implementation because it works after the previous item in the stack correct? So you can put it after "known" variable length headers like IP. The limitation is it can't get past undefined variable length headers. However if you use the above parse graph reporting from the driver mechanism and the driver always reports its largest supported graph then we don't have this issue where a new hardware sku/ucode/etc added support for new headers but we have no way to deploy it to existing software users without recompiling and redeploying. I looked at the git repo but I only saw the header definition I guess the implementation is TBD after there is enough agreement on the interface? Thanks, John