From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from stargate3.asicdesigners.com (unknown [12.32.117.8]) by dpdk.org (Postfix) with ESMTP id 7116147D1 for ; Thu, 21 Jul 2016 10:16:34 +0200 (CEST) Received: from localhost (scalar.blr.asicdesigners.com [10.193.185.94]) by stargate3.asicdesigners.com (8.13.8/8.13.8) with ESMTP id u6L8EJiu030181; Thu, 21 Jul 2016 01:14:33 -0700 Date: Thu, 21 Jul 2016 13:43:37 +0530 From: Rahul Lakkireddy To: dev@dpdk.org, Thomas Monjalon , Helin Zhang , Jingjing Wu , Rasesh Mody , Ajit Khaparde , Wenzhuo Lu , Jan Medala , John Daley , Jing Chen , Konstantin Ananyev , Matej Vido , Alejandro Lucero , Sony Chacko , Jerin Jacob , Pablo de Lara , Olga Shern Cc: Kumar Sanghvi , Nirranjan Kirubaharan , Indranil Choudhury Message-ID: <20160721081335.GA15856@chelsio.com> References: <20160705181646.GO7621@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160705181646.GO7621@6wind.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Thu, 21 Jul 2016 08:16:43 -0000 Hi Adrien, The proposal looks very good. It satisfies most of the features supported by Chelsio NICs. We are looking for suggestions on exposing more additional features supported by Chelsio NICs via this API. Chelsio NICs have two regions in which filters can be placed - Maskfull and Maskless regions. As their names imply, maskfull region can accept masks to match a range of values; whereas, maskless region don't accept any masks and hence perform a more strict exact-matches. Filters without masks can also be placed in maskfull region. By default, maskless region have higher priority over the maskfull region. However, the priority between the two regions is configurable. Please suggest on how we can let the apps configure in which region filters must be placed and set the corresponding priority accordingly via this API. More comments below. On Tuesday, July 07/05/16, 2016 at 20:16:46 +0200, Adrien Mazarguil wrote: > Hi All, > [...] > > ``ETH`` > ^^^^^^^ > > Matches an Ethernet header. > > - ``dst``: destination MAC. > - ``src``: source MAC. > - ``type``: EtherType. > - ``tags``: number of 802.1Q/ad tags defined. > - ``tag[]``: 802.1Q/ad tag definitions, innermost first. For each one: > > - ``tpid``: Tag protocol identifier. > - ``tci``: Tag control information. > > ``IPV4`` > ^^^^^^^^ > > Matches an IPv4 header. > > - ``src``: source IP address. > - ``dst``: destination IP address. > - ``tos``: ToS/DSCP field. > - ``ttl``: TTL field. > - ``proto``: protocol number for the next layer. > > ``IPV6`` > ^^^^^^^^ > > Matches an IPv6 header. > > - ``src``: source IP address. > - ``dst``: destination IP address. > - ``tc``: traffic class field. > - ``nh``: Next header field (protocol). > - ``hop_limit``: hop limit field (TTL). > > ``ICMP`` > ^^^^^^^^ > > Matches an ICMP header. > > - TBD. > > ``UDP`` > ^^^^^^^ > > Matches a UDP header. > > - ``sport``: source port. > - ``dport``: destination port. > - ``length``: UDP length. > - ``checksum``: UDP checksum. > > .. raw:: pdf > > PageBreak > > ``TCP`` > ^^^^^^^ > > Matches a TCP header. > > - ``sport``: source port. > - ``dport``: destination port. > - All other TCP fields and bits. > > ``VXLAN`` > ^^^^^^^^^ > > Matches a VXLAN header. > > - TBD. > In addition to above matches, Chelsio NICs have some additional features: - Match based on unicast DST-MAC, multicast DST-MAC, broadcast DST-MAC. Also, there is a match criteria available called 'promisc' - which matches packets that are not destined for the interface, but had been received by the hardware due to interface being in promiscuous mode. - Match FCoE packets. - Match IP Fragmented packets. - Match range of physical ports on the NIC in a single rule via masks. For ex: match all UDP packets coming on ports 3 and 4 out of 4 ports available on the NIC. - Match range of Physical Functions (PFs) on the NIC in a single rule via masks. For ex: match all traffic coming on several PFs. Please suggest on how we can expose the above features to DPDK apps via this API. [...] > > Actions > ~~~~~~~ > > Each possible action is represented by a type. Some have associated > configuration structures. Several actions combined in a list can be affected > to a flow rule. That list is not ordered. > > At least one action must be defined in a filter rule in order to do > something with matched packets. > > - Actions are defined with ``struct rte_flow_action``. > - A list of actions is defined with ``struct rte_flow_actions``. > > They fall in three categories: > > - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent > processing matched packets by subsequent flow rules, unless overridden > with PASSTHRU. > > - Non terminating actions (PASSTHRU, DUP) that leave matched packets up for > additional processing by subsequent flow rules. > > - Other non terminating meta actions that do not affect the fate of packets > (END, VOID, ID, COUNT). > > 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.* > Chelsio NICs can support an action 'switch' which can re-direct matched packets from one port to another port in hardware. In addition, it can also optionally: 1. Perform header rewrites (src-mac/dst-mac rewrite, src-mac/dst-mac swap, vlan add/remove/rewrite). 2. Perform NAT'ing in hardware (4-tuple rewrite). before sending it out on the wire [1]. To meet the above requirements, we'd need a way to pass sub-actions to action 'switch' and a way to pass extra info (such as new src-mac/dst-mac, new vlan, new 4-tuple for NAT) to rewrite corresponding fields. We're looking for suggestions on how we can achieve action 'switch' in this new API. >>From our understanding of this API, we could just expand rte_flow_action_type with an additional action type RTE_FLOW_ACTION_TYPE_SWITCH and define several sub-actions such as: enum rte_flow_action_switch_type { RTE_FLOW_ACTION_SWITCH_TYPE_NONE, RTE_FLOW_ACTION_SWITCH_TYPE_MAC_REWRITE, RTE_FLOW_ACTION_SWITCH_TYPE_MAC_SWAP, RTE_FLOW_ACTION_SWITCH_TYPE_VLAN_INSERT, RTE_FLOW_ACTION_SWITCH_TYPE_VLAN_DELETE, RTE_FLOW_ACTION_SWITCH_TYPE_VLAN_REWRITE, RTE_FLOW_ACTION_SWITCH_TYPE_NAT_REWRITE, }; and then define an rte_flow_action_switch as follows: struct rte_flow_action_switch { enum rte_flow_action_switch_type type; /* sub actions to perform */ uint16_t port; /* Destination physical port to switch packet */ enum rte_flow_item_type type; /* Fields to rewrite */ const void *switch_spec; /* Holds info to rewrite matched flows */ }; Does the above approach sound right with respect to this new API? [...] > > ``COUNT`` > ^^^^^^^^^ > > Enables hits counter for this rule. > > This counter can be retrieved and reset through ``rte_flow_query()``, see > ``struct rte_flow_query_count``. > > - Counters can be retrieved with ``rte_flow_query()``. > - No configurable property. > > +---------------+ > | COUNT | > +===============+ > | no properties | > +---------------+ > > Query structure to retrieve and reset the flow rule hits counter: > > +------------------------------------------------+ > | COUNT query | > +===========+=====+==============================+ > | ``reset`` | in | reset counter after query | > +-----------+-----+------------------------------+ > | ``hits`` | out | number of hits for this flow | > +-----------+-----+------------------------------+ > Chelsio NICs can also count the number of bytes that hit the rule. So, need a counter "bytes". [...] [1] http://www.dpdk.org/ml/archives/dev/2016-February/032605.html Thanks, Rahul