From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from stargate3.asicdesigners.com (stargate.chelsio.com [12.32.117.8]) by dpdk.org (Postfix) with ESMTP id A2B65F72 for ; Thu, 14 Jan 2016 14:18:00 +0100 (CET) Received: from localhost (scalar.blr.asicdesigners.com [10.193.185.94]) by stargate3.asicdesigners.com (8.13.8/8.13.8) with ESMTP id u0EDHuCh018404; Thu, 14 Jan 2016 05:17:57 -0800 Date: Thu, 14 Jan 2016 18:47:30 +0530 From: Rahul Lakkireddy To: "Wu, Jingjing" Message-ID: <20160114131728.GA2434@scalar.blr.asicdesigners.com> References: <9BB6961774997848B5B42BEC655768F8D74B6B@SHSMSX104.ccr.corp.intel.com> <20160113084920.GA6469@scalar.blr.asicdesigners.com> <9BB6961774997848B5B42BEC655768F8D80272@SHSMSX104.ccr.corp.intel.com> <9BB6961774997848B5B42BEC655768F8D85DED@SHSMSX104.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BB6961774997848B5B42BEC655768F8D85DED@SHSMSX104.ccr.corp.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Cc: "'dev@dpdk.org'" , Felix Marti , Nirranjan Kirubaharan , Kumar A S Subject: Re: [dpdk-dev] [RFC v2 1/2] ethdev: add packet filter flow and new behavior switch to fdir 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, 14 Jan 2016 13:18:01 -0000 Hi Jingjing, On Thursday, January 01/14/16, 2016 at 00:48:17 -0800, Wu, Jingjing wrote: > Hi, Rahul > > Just another thought, please consider about it: > > Add a new flow type like > > #define RTE_ETH_FLOW_IPV6_UDP_EX 17 > +#define RTE_ETH_FLOW_RAW_PKT 18 > > Then add a new item in rte_eth_fdir_flow > union rte_eth_fdir_flow { > struct rte_eth_l2_flow l2_flow; > struct rte_eth_udpv4_flow udp4_flow; > struct rte_eth_tcpv4_flow tcp4_flow; > struct rte_eth_sctpv4_flow sctp4_flow; > struct rte_eth_ipv4_flow ip4_flow; > struct rte_eth_udpv6_flow udp6_flow; > struct rte_eth_tcpv6_flow tcp6_flow; > struct rte_eth_sctpv6_flow sctp6_flow; > struct rte_eth_ipv6_flow ipv6_flow; > struct rte_eth_mac_vlan_flow mac_vlan_flow; > struct rte_eth_tunnel_flow tunnel_flow; > + uint8_t raw_pkt[80]; > }; > > Then add mask item in rte_eth_fdir_input: > > struct rte_eth_fdir_input { > uint16_t flow_type; > union rte_eth_fdir_flow flow; > + union rte_eth_fdir_flow flow_mask; > /**< Flow fields to match, dependent on flow_type */ > struct rte_eth_fdir_flow_ext flow_ext; > /**< Additional fields to match */ > }; > > Then the filter can be added just in a format of raw packet, it looks generic, and even other NIC can use this too. > > Thanks > Jingjing This approach seems generic enough to allow any vendor specific data to be passed in filter as well. However, 80 seems to be too low for multiple flow types that can be combined in the same filter rule. I think size of 256 seems reasonable. Could the same thing be done for action arguments as well? Can we add the same generic info to rte_eth_fdir_action too? struct rte_eth_fdir_action { uint16_t rx_queue; enum rte_eth_fdir_behavior behavior; enum rte_eth_fdir_status report_status; uint8_t flex_off; + uint8_t behavior_arg[256]; }; This way, we can pass vendor specific action arguments too. What do you think? Also, now if we take this approach then, I am wondering, that all vendors would need to document their own vendor-specific format of taking filter match and filter action arguments, right? And probably, even come up with their own example application showing how to apply filters via dpdk on their card? Thanks, Rahul